What Is DKIM Record? a Clear Guide for 2026

Do not index

DKIM is a DNS TXT record published at a selector-based hostname that holds the public key mailbox providers use to verify the cryptographic signature on outgoing mail. In practice, that means a valid DKIM record helps protect inbox placement, but DKIM was enabled on only 28.1% of Alexa Top 1 Million domains, and 2.9% of those deployments were misconfigured in one large measurement study, so a lot of teams are still shipping mail with weak or broken authentication (RFC 6376).

Your newsletter looks fine, your transactional mail is on schedule, and then replies drop. The hidden problem is often a stale selector, a broken DNS record, or a signature that passes on paper but doesn't help enough with deliverability because mailbox providers look at more than one signal.

Table of Contents

What a DKIM Record Is and Why Inbox Placement Depends on It Why mailbox providers care How DKIM Signing and Verification Actually Work The sender side The receiver side DKIM Record Syntax, Tags, and Selectors Explained with Examples The tags that matter most How selectors solve the multi-sender problem Key Lengths, Multiple Selectors, and Safe Rotation Choosing the right key size Why multiple selectors are safer A safer rotation pattern Common DKIM Misconfigurations That Hurt Deliverability The failures that show up most often Why a DKIM pass still doesn't guarantee the inbox How to Check, Diagnose, and Fix DKIM Issues A practical diagnostic workflow How to fix the three most common failures DKIM Questions You Might Still Have

What a DKIM Record Is and Why Inbox Placement Depends on It

A sender can run a polished campaign, watch the copy perform well in testing, and still see mail drift into spam because the authentication layer is missing or stale. That's the painful part, the team usually sees the symptom first, like lower open rates, fewer replies, or broken onboarding flows, and only later discovers that the DKIM record wasn't being checked the way they assumed it was.

A DKIM record is the DNS TXT record that publishes the public key for a signed mail stream. It lives at a selector-based hostname such as selector._domainkey.yourdomain.com, which is why teams doing a DKIM record lookup need the selector, not just the domain.

Why mailbox providers care

Mailbox providers use DKIM to check whether a message was authorized by the domain that signed it and whether the message changed after signing. That matters because a signed message gives Gmail, Outlook, Yahoo, and similar providers another reason to trust the sender, and trust is a major input into inbox placement and domain reputation.

DKIM also helps reduce spoofing risk. When a bad actor tries to impersonate a brand, a correct signature can help providers tell the difference between a legitimate sender and a forged one, which protects both customers and the sender's reputation.

The business angle is simple. If a login alert, receipt, or password reset doesn't reach the inbox, the user experience breaks immediately. If a cold email can't build trust with mailbox providers, the campaign burns list cost, SDR time, and follow-up effort without producing the expected return.

For readers mapping DKIM into the rest of their email stack, how email fits your GTM strategy is a useful companion view because inbox placement sits directly inside growth execution, not beside it. For a broader protocol overview, the email security guide at mailX's protocol summary adds helpful context without turning DKIM into a standalone topic.

How DKIM Signing and Verification Actually Work

A DKIM-enabled message follows a simple story. The sending server prepares the message, signs parts of it with a private key, and adds that signature to the email header. The receiving server later checks the signature against the public key stored in DNS, and if the values match, the message is treated as authentic.

The sender side

The sending system takes selected headers and the body, creates a hash, and signs that hash with the private DKIM key. That signature is inserted into the message as a DKIM-Signature header, so the receiver has enough information to find the matching public key and test the result.

This is why DKIM is more than a label. It's a cryptographic proof that the holder of the private key signed the message, which makes it harder for someone to alter the content without breaking the signature.

The receiver side

When the mailbox provider receives the email, it performs a DNS lookup for the public key at selector._domainkey.signingdomain. Then it re-hashes the same message parts and compares the result with the signature attached to the message.

If the values match, the message passes DKIM. If they don't, the signature fails. If the DNS record is missing, broken, or malformed, the result is often a permerror, which means the provider couldn't complete the verification cleanly.

That outcome matters for inbox placement because mailbox providers don't read authentication in isolation. A clean DKIM pass helps, but the final decision still depends on broader signals like domain reputation, alignment, and sending behavior. A failure can hurt trust fast, while a permerror can make troubleshooting messy because the problem isn't always inside the message itself.

DKIM Record Syntax, Tags, and Selectors Explained with Examples

A DKIM record is usually a TXT record under the selector hostname, and the structure is compact but exacting. The common pattern is selector._domainkey.example.com, with tags inside the TXT value that tell receivers how to interpret the key.

The tags that matter most

v=DKIM1 marks the version.k=rsa identifies the key type in most common deployments.p= contains the base64-encoded public key that receivers use to verify the signature.

Optional tags appear in some setups too. t=y can signal testing mode, s= can scope use to subdomains, and h= can indicate allowed hash algorithms. The exact mix varies by platform, but the record always has to be syntactically clean, or receivers may reject it outright.

A simple example looks like this:

Hostname: selector1._domainkey.example.com

TXT value: v=DKIM1; k=rsa; p=MIGfMA0...IDAQAB

How selectors solve the multi-sender problem

Selectors let one domain publish more than one DKIM key at the same time. That matters when a company sends marketing email, transactional email, and third-party platform mail from the same domain, because each stream may need its own key and its own operational lifecycle.

A clean way to think about it is this:

One selector for internal transactional systems.

One selector for marketing automation.

One selector for a third-party ESP that signs on the domain's behalf.

That separation makes troubleshooting much easier when one vendor changes, because the whole domain doesn't have to move at once. It also reduces the blast radius when a key is rotated or retired.

For teams that want a faster way to inspect or generate records, the DKIM record generator guide is useful because it reinforces how selectors and TXT values fit together. For a broader operational view, project management tools for Gmail is a helpful adjacent read when multiple people are coordinating mail streams and DNS changes across a team.

DKIM key length tradeoffs at a glance	ㅤ	ㅤ	ㅤ	ㅤ
Key size	Security margin	DNS TXT record size	Resolver compatibility	Recommended for
1024-bit	Lower	Smaller	Broad, but aging	Legacy setups that still need a transition plan
2048-bit	Stronger	Larger	Broad, with more attention to formatting	Most modern sending environments

Key Lengths, Multiple Selectors, and Safe Rotation

Key management is where DKIM stops being a textbook topic and becomes an operational discipline. A single selector can work for a small setup, but as soon as different systems send on behalf of the same domain, selector planning starts to matter for uptime, auditability, and deliverability.

Choosing the right key size

A 1024-bit key is easier to fit into DNS, but a 2048-bit key gives a stronger security margin. That stronger margin is one reason adoption moved toward larger keys after 2020, and historical DMARC.org statistics show DKIM keys tripled from 2020 to 2021, with 1,024-bit keys roughly doubling and 2,048-bit keys increasing 4.5× in that period (Valimail DKIM overview).

The practical tradeoff is straightforward. Bigger keys are better for security, but they also create longer TXT values, which means cleaner DNS formatting matters more. If a DNS console truncates the value or wraps it badly, the record can fail even when the private key itself is fine.

Why multiple selectors are safer

A single selector forces every sending stream to share the same key lifecycle. That's risky because a provider switch, a broken integration, or a delayed update can affect every message stream at once.

Separate selectors make it possible to isolate risk:

Marketing can rotate without touching receipts.

Transactional mail can stay stable while a vendor is migrated.

Third-party tools can be retired without leaving the whole domain exposed.

A safer rotation pattern

A clean rotation process usually looks like this:

Publish the new selector in DNS before changing anything else.

Start signing with the new private key while the old key still exists.

Watch verification results on live mail from both streams.

Remove the old key only after the transition is stable.

This avoids a common outage pattern where the old key is deleted too early, then messages signed by the previous system start failing lookup or verification.

Common DKIM Misconfigurations That Hurt Deliverability

The most frustrating DKIM issues usually don't look dramatic. They show up as “almost working” setups, where one stream passes and another fails, or where a record exists in DNS but the receiving server can't use it the way the sender expected.

The failures that show up most often

A stale selector is common after an ESP switch. The DNS record still exists, but the active sender moved elsewhere, so the domain owner keeps seeing a valid-looking key that no longer matches reality.

A second issue is a truncated TXT value. Some DNS consoles handle long DKIM strings badly, and the visible record looks fine until a receiver tries to validate it and gets only part of the key. That creates confusing failures because the record exists, but the signature can't be verified.

Broken alignment is another recurring problem. The message can be signed correctly while the signing domain in the header doesn't match the visible From domain closely enough for DMARC to treat it as aligned. In that case, DKIM may pass and the message can still struggle with inbox placement because DMARC evaluates the broader identity picture.

There's also the “revoked but still present” case. Some teams publish a selector with an empty p= value to disable the key, but forget that the stale selector still lives in DNS. That leaves a confusing trail during troubleshooting because the hostname exists even though the usable key is gone.

Why a DKIM pass still doesn't guarantee the inbox

Authentication helps, but it's not the entire inbox decision. A passing signature on a low-reputation domain can still land in spam, and a valid key on a misaligned or poorly behaved stream won't override every other signal mailbox providers use.

What to check	Why it matters
Selector freshness	Old selectors create misleading verification paths
TXT integrity	Truncated values break signature lookup
From alignment	DMARC can still fail even when DKIM passes
Key age	Old or weak keys increase operational and security risk
Stream separation	One bad sender shouldn't take down all mail

Teams often get tripped up here. They see “DKIM pass” and assume the job is done, then wonder why newsletters still underperform or why a transactional system still lands in spam. Authentication is a signal, not a promise.

How to Check, Diagnose, and Fix DKIM Issues

The fastest DKIM troubleshooting path starts with DNS and ends with a full deliverability check. First, confirm the selector hostname exists and the TXT value is intact. Then inspect a test message's headers to see whether the signature passed when the email moved through the receiving side.

A practical diagnostic workflow

Check the selector in DNS. Confirm the hostname matches the sender's selector and that the TXT value wasn't truncated.

Read the message headers. Look for the DKIM signature and the authentication result in the received email.

Check the context. Review SPF, DMARC, MX, PTR, and blacklist status so DKIM isn't judged in isolation.

A useful next step is to compare what the sender thinks it published with what the receiver sees in headers. That catches the common mismatch between a configured record and a live signature.

For a quick primer on reading headers, the email header reading guide helps readers connect the raw message data to the authentication result without guessing.

How to fix the three most common failures

Missing record: publish the correct selector-based TXT record, then retest after DNS has propagated.

Truncated record: re-enter the full key exactly as provided by the signing platform, then verify the value length in DNS.

Stale selector: either reactivate the expected sender or remove the orphaned record after confirming no active mail stream still depends on it.

mailX is useful here because it combines DKIM Checker, DKIM Generator, DMARC Checker, SPF Checker, Blacklist Checker, and a full deliverability audit in one place, with plain-English explanations and exact remediation steps. For teams building automated workflows, the MCP endpoint at mailX MCP and the Agent Skill make the same checks available to AI agents instead of forcing blind sending.

DKIM Questions You Might Still Have

How often should DKIM keys be rotated?Rotate on a regular schedule, and don't leave old selectors sitting around without a reason. The safest habit is to keep the old key live only long enough to validate the new one, then retire it cleanly.

Is DKIM enough to reach the inbox in 2026?No. DKIM is important, but mailbox providers still evaluate reputation, alignment, and other authentication signals before deciding where the message belongs.

What happens if SPF passes but DKIM fails?The message may still authenticate under DMARC if alignment and policy conditions are satisfied, but a DKIM failure can still weaken trust and create troubleshooting noise. The result depends on the full message context, not one check alone.

Can AI agents check DKIM automatically before sending?Yes, if they're connected to live tools through API or MCP. That's the safer pattern because agents shouldn't send blindly when a bad selector or broken DNS record could hurt deliverability.

Email deliverability issues are rarely random. They usually come from authentication, DNS, reputation, blacklist, or infrastructure signals, and DKIM is one of the first places to look when messages start underperforming.

Run a free deliverability audit with mailX to check DKIM, SPF, DMARC, blacklist status, and related DNS signals in one place. It gives plain-English explanations and exact remediation steps, so you can stop guessing and fix what's hurting inbox placement fast.