InboxRatio
Check your domain

Glossary term

What is DKIM? The signature that survives the journey

What DKIM is

DKIM — DomainKeys Identified Mail — attaches a cryptographic signature to every outgoing email, allowing any receiving server to verify two things: the message really was authorized by the domain that signed it, and the signed parts were not altered in transit. The mechanism is defined in RFC 6376.

The visible artifact is a DKIM-Signature: header on the message:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026;
  h=from:to:subject:date:mime-version;
  bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;
  b=KxLZ9uT3...

The tags that matter: d= names the signing domain, s= names the selector (which key was used), h= lists which headers were signed, bh= is the hash of the body, and b= is the signature itself.

Verification requires no prior relationship between sender and receiver. The public key sits in the signer's DNS, where anyone can fetch it. That is the elegance of the design: the signature travels with the message, the key sits at a predictable address, and any server anywhere can check the math.

How DKIM differs from SPF

SPF and DKIM are complementary answers to the same underlying problem — SMTP's lack of sender verification — approached from opposite ends.

SPF validates the delivery path: was the connecting server authorized by the envelope-sender's domain? It examines nothing inside the message, and its verdict is tied to the specific server-to-server hop being made. Forward the message once and SPF's answer changes.

DKIM validates the message itself: the signature is computed over the content, so it remains verifiable no matter how many servers the message passes through — provided nobody modifies the signed parts along the way.

Their failure modes are mirror images. SPF breaks on forwarding and survives content modification (it never looked at the content). DKIM survives forwarding and breaks on content modification (a mailing-list footer, a "scanned by" banner, an encoding rewrite). DMARC requires only one of the two to pass with alignment, which is precisely why running both is the resilient configuration: each covers the other's blind spot.

How DKIM works

On the sending side, the mail server holds a private key. For each outgoing message it hashes the body, signs the body hash plus the selected headers, and prepends the DKIM-Signature header.

On the receiving side, the verifier reads d= and s= from the signature and queries DNS for a TXT record at:

mail2026._domainkey.yourdomain.com

That record holds the public key:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

The verifier recomputes the hashes and checks the signature. Any mismatch — one altered character in a signed header, one byte changed in the body — fails verification.

Selectors are the operational hinge. Because the selector is part of the DNS name, a domain can hold many keys at once: one per sending platform, one per key generation. Your ESP signs with its selector, your ticketing system with another, and rotating a key means publishing a new selector and switching signing to it — no coordination with receivers required. Key rotation on a schedule is cheap insurance; a private key that leaks lets the holder sign mail as you until the record comes down.

Key length has a floor. RFC 8301 updated the algorithm requirements: 1024-bit RSA is the minimum verifiers must accept, 2048-bit is the recommendation, and verifiers are told to reject keys below 1024 bits. Publish 2048-bit keys; the only historical objection — fitting the longer key into a DNS TXT record — is solved by string-splitting, though some DNS panels still fumble it (more below).

For DMARC purposes, one more check rides on top: alignment. The d= domain must match the From header domain (exactly, or organizationally under relaxed alignment). A valid signature from the wrong domain passes DKIM but contributes nothing to DMARC. You can confirm your selector publishes a valid key with a DKIM checker, and see the full SPF-DKIM-DMARC picture in one pass with the email authentication checker.

DKIM and your deliverability

DKIM has quietly become the most load-bearing of the three authentication mechanisms. Google Postmaster guidelines and Yahoo Sender Hub both require bulk senders to sign with DKIM, and — less obviously — DKIM is usually the only mechanism keeping DMARC intact for forwarded mail, since SPF alignment dies at the first forwarding hop.

Beyond compliance, the d= domain is a domain reputation anchor. Mailbox providers accumulate history against the signing domain: a domain that has signed years of wanted mail carries that record with it. This cuts both ways — the reputation follows the domain to a new ESP or a new IP range, and it also means a burned signing domain stays burned until its behavior changes.

The single most consequential DKIM decision most senders make without knowing it: whose domain signs your mail. Many platforms work out of the box by signing with their own domain — the signature validates, dashboards show green, and your DMARC evaluation gets nothing from it because d= is the ESP's domain, not yours. Setting up custom-domain signing (publishing the CNAME or TXT records your platform provides) is the step that converts DKIM from "technically present" to "actually yours". We check for exactly this default in platform reviews, per our review standards.

Limitations and failure modes

In-transit modification breaks the signature. Mailing lists that append footers or rewrite subjects, security gateways that inject banners, and occasionally encoding normalization by an intermediate server all invalidate the body hash. The signature did its job — the message was modified — but the consequence lands on delivery. Signing fewer headers and using relaxed canonicalization (the c= tag) reduces false breakage from whitespace and header-wrapping changes.

ESP-domain signing. The failure mode we meet most often in real setups: green checkmarks in the ESP dashboard do not mean the signature aligns with your From domain.

The 2048-bit record splitting trap. A 2048-bit public key exceeds the 255-character limit of a single TXT string and must be published as multiple quoted strings in one record. Some DNS management panels split correctly, some truncate, and a truncated key fails every verification while looking present at a glance. Always verify the published key from the outside after any change.

Forgotten selectors. Old selectors with live keys keep working — including for whoever controls the systems they belong to. The selector granted to a vendor you dropped years ago is still authorized to sign as your domain until you remove the record. Selector hygiene is part of offboarding.

Replay. A DKIM signature validates the message, not the sending context. A signed message can be re-sent by anyone to anyone with the signature intact — which spammers have exploited by obtaining one signed message from a reputable platform and replaying it at volume. Oversigning key headers and short key rotation windows narrow the exposure.

DKIM alone proves authorization, not honesty. A perfectly signed message from a domain registered yesterday passes DKIM everywhere. The mechanism authenticates identity; reputation systems judge the identity itself.

Related terms

SPF record, DMARC, DKIM alignment, domain reputation, sender reputation, feedback loop, email warm-up.

Frequently asked questions

What does a DKIM record look like? A TXT record at {selector}._domainkey.{domain} containing v=DKIM1; k=rsa; p={public key}. The selector is announced in each message's DKIM-Signature header, so receivers always know which record to fetch.

How do I find my DKIM selector? Open a message you sent and read the s= tag in the DKIM-Signature header. Your sending platform's setup pages also list the selectors it uses for your account.

Is DKIM required to reach Gmail? For bulk senders, Gmail's sender requirements mandate DKIM signing, and Yahoo imposes the same. Low-volume senders have more slack, but unsigned mail starts every evaluation at a disadvantage and cannot pass DMARC via DKIM.

Should I use 1024-bit or 2048-bit keys? 2048-bit. RFC 8301 sets 1024 as the floor verifiers must accept and recommends 2048. The only cost is the TXT record splitting, which your DNS host should handle — verify from outside after publishing.

Why does my DKIM pass but DMARC fail? Alignment. The signature's d= domain is probably your ESP's domain rather than your From domain. Configure custom-domain signing so d= matches the domain recipients see.

Does forwarding break DKIM? Usually not — that is DKIM's advantage over SPF. It breaks only if the forwarder modifies signed content, which mailing lists commonly do and plain forwarding usually does not.

Check today whose domain actually signs your mail — the DKIM checker plus one glance at a sent message's d= tag settles it in under a minute.

Sources