What is DKIM? Signatures, selectors, and keys

DKIM — DomainKeys Identified Mail, defined in RFC 6376 — attaches a cryptographic signature to every message your mail server sends. The receiving server fetches your public key from DNS and verifies the signature. A valid signature proves two things: the message was authorized by the domain that signed it, and the signed parts were not altered in transit.

Unlike SPF, which depends on which server the mail arrived from, a DKIM signature travels inside the message — so it keeps working when mail is forwarded. That property makes DKIM the sturdier half of the authentication pair, and the one most worth getting right.

How a DKIM signature works

When your mail server (or your email provider's) sends a message, it computes two hashes — one over the message body, one over a chosen set of headers — and signs them with a private key only the sender holds. The result is added to the message as a DKIM-Signature header. A simplified one looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
  h=from:to:subject:date; bh=Fx8oWL...; b=KqZtE1...

The tags that matter:

Tag	Meaning
d=	The signing domain — the domain claiming responsibility for the message. This is the value DMARC alignment compares against.
s=	The selector — which of the domain's keys signed this message.
h=	The headers covered by the signature (From: is always required).
bh=	The hash of the message body.
b=	The signature itself.

The receiver reverses the process: it reads d= and s= from the header, fetches the matching public key from DNS, recomputes the hashes, and checks them against the signature. Any mismatch — a modified body, an altered signed header, a wrong key — and the verification fails.

Note what DKIM does not do: it does not encrypt anything, and a valid signature does not mean the mail is trustworthy — spammers sign their mail too. It means the mail genuinely comes from the d= domain. Whether that domain is your domain is the question DMARC alignment answers.

Selectors: why one domain has many keys

The public key is not published at a fixed place. It lives at a DNS name built from the selector:

<selector>._domainkey.<domain>

For the signature above, the receiver queries the TXT record at mail2026._domainkey.example.com. Selectors exist so one domain can hold many keys at once — one per sending service, plus old and new keys side by side during rotation. Google Workspace uses the selector google by default; Microsoft 365 uses selector1 and selector2; ESPs generate their own (k1, s1, and so on).

Selectors have one awkward consequence for anyone checking a domain from the outside: DNS offers no way to list them. You can query a selector you already know, but you cannot enumerate a domain's selectors — the namespace under _domainkey is effectively unguessable unless you know which services the domain uses. Diagnostic tools work around this by probing a list of common selectors, which finds most real-world setups but can never prove a domain has no DKIM key. That is why an honest checker reports "no key found at the common selectors," never "no DKIM." Check a specific selector — or probe the common ones — with the DKIM checker.

The public key record

The DNS side of DKIM is one TXT record per selector:

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

• v=DKIM1 — version marker.
• k=rsa — the key type.
• p= — the public key itself, base64-encoded. This is the long blob your provider hands you.

In almost every hosted setup you never generate this yourself: the provider creates the key pair, keeps the private key, and gives you the exact TXT record (or a CNAME pointing at one they host) to publish. Publishing the record is your only job — and the place setups usually go wrong, through truncated values, added quotes, or a record pasted at the wrong host name.

One special case worth knowing: a record with an empty p= value is a revoked key, per RFC 6376. It tells receivers "this key existed and is deliberately no longer valid" — different from no record at all, and occasionally the explanation when a signature that used to verify suddenly does not.

Key length: 1024 vs 2048 bits

DKIM keys are almost always RSA, and the practical question is size. RFC 8301 settled it: signers should use keys of at least 2048 bits, and verifiers must accept keys from 1024 to 4096 bits. A 1024-bit key still verifies today, but it offers a much thinner security margin, and there is no operational reason to prefer it — major providers now issue 2048-bit keys by default. If your key predates that shift, rotating to 2048 bits is the fix.

(A newer alternative, Ed25519 signatures, is defined in RFC 8463 — smaller keys, cleaner cryptography — but receiver support is still not universal, so it is deployed alongside RSA rather than instead of it.)

Key rotation

The private key is a credential, and like any credential it should not live forever. If it leaks — a compromised server, a departed vendor, a backup in the wrong place — whoever holds it can sign mail as your domain, and the signatures will verify.

Selectors make rotation clean, with no moment where mail goes unsigned:

1. Generate a new key pair and publish the public key at a new selector.
2. Switch signing to the new key.
3. Leave the old record in place briefly — mail signed before the switch is still in transit and still needs to verify.
4. Then remove the old record, or revoke it explicitly by publishing it with an empty p=.

Hosted providers that manage keys via CNAME often rotate for you automatically. If you manage raw TXT keys yourself, rotation is your job — on whatever schedule your security posture calls for, and immediately whenever you suspect the private key has leaked or you stop using the service that held it.

What breaks DKIM

A signature fails when the signed content changes between signing and verification. The usual culprits:

• Mailing lists that add a subject prefix or a footer — the body hash no longer matches. (List software often re-signs with its own domain instead, which verifies but is no longer your signature.)
• Gateways and filters that rewrite links, add disclaimers, or re-encode the message after it was signed.
• DNS problems — the key record deleted, truncated by a DNS panel that mangles long TXT values, or published at the wrong name.

Ordinary forwarding, by contrast, usually leaves the message intact — which is exactly why DKIM survives it when SPF does not.

DKIM's role in DMARC

For DMARC, a DKIM pass counts only when it is aligned: the d= domain in the signature must match the domain in the visible From: header. An ESP signing with d=esp-example.com on mail whose From: is your domain produces a valid but unaligned signature — real authentication, zero DMARC value. The setting that fixes this is usually called "custom signing domain" or similar in your provider's dashboard, and it is the single most important DKIM option to switch on.

Because DKIM survives forwarding and SPF does not, an aligned DKIM signature is what keeps your legitimate mail passing DMARC in the messy real world. Domains that reach p=reject safely almost always get there on the strength of DKIM.

Check your setup

Whether DKIM is actually working for your domain comes down to checkable facts: a key at the selector your provider uses, an intact p= value, a sensible key size, and a d= that aligns with your From: domain. A scan of your domain probes the common selectors and reports what it finds — alongside SPF, DMARC, MX, DNS, blacklist, and expiry checks — so you can see the whole authentication picture in one pass.