Of the three big email-authentication standards, DKIM is the one that actually proves a message wasn’t altered in transit — and, just as importantly, that it genuinely came from a domain that holds the private key. SPF checks the envelope path; DKIM signs the message itself. If you’ve ever wondered why a forwarded email still passes authentication when SPF breaks, DKIM is the reason. It’s also the piece people most often misconfigure, because half of it lives with your mail provider and half lives in your DNS.
How DKIM signing actually works
When your provider sends a message, it computes a hash of selected headers and the body, encrypts that hash with a private key, and attaches the result as a DKIM-Signature: header. The matching public key is published in your DNS. A receiver reads the signature, notes which domain (d=) and selector (s=) signed it, fetches the public key from <selector>._domainkey.<domain>, and re-computes the hash. If it matches, two things are proven: the signed content wasn’t modified, and whoever sent it controls the private key for that domain. The mechanism is defined in RFC 6376.
Selectors — why we can’t always guess
A single domain can have many DKIM keys, each under a different selector, so a provider can rotate keys or run separate streams (transactional vs. marketing) without collisions. The selector isn’t secret, but it also isn’t discoverable from DNS alone — you have to read it from a real message’s DKIM-Signature header (the s= tag), or know your provider’s convention. Common ones: Google Workspace uses google, Microsoft 365 uses selector1/selector2, Amazon SES uses long token selectors, Mailchimp uses k1. If you don’t know yours, enter the domain and we’ll try common selectors, or paste one from the header analyzer.
What a healthy key looks like
- Key type & length. Almost all keys are RSA. Use at least a 1024-bit key; 2048-bit is the modern recommendation. Anything shorter (512-bit) is trivially breakable and is rejected by many receivers.
- Not in testing mode. A
t=yflag means “testing” — receivers are told to treat failures leniently, which undermines the point. Remove it once you’ve confirmed signing works. - Not revoked. An empty
p=value revokes the key. If you see that unexpectedly, the key was retired but your provider is still signing with it — a guaranteed authentication failure. - One clean TXT record. DKIM public keys are long and often span multiple quoted strings; they must concatenate cleanly. A truncated or doubled record breaks verification.
DKIM, alignment and DMARC
DKIM on its own tells a receiver “this was signed correctly.” What turns it into anti-spoofing protection is alignment: for DMARC to pass on the DKIM side, the domain in the signature’s d= tag must match (or be a subdomain of) the domain in the visible From: address. You can have a perfectly valid signature that still fails DMARC because it’s signed by your ESP’s domain instead of yours — which is exactly why providers ask you to publish CNAMEs so they can sign as your domain. To see the whole picture at once, run the Email Health Check, and confirm real signatures land in a live inbox with the Outbound Deliverability Test.
How to fix a failing DKIM setup
- Find the selector from a recently sent message’s
DKIM-Signatureheader (s=). - Publish the exact record your provider gives you — usually a CNAME (so they manage rotation) or a TXT with the public key. Copy it verbatim; a single altered character invalidates the key.
- Check propagation and confirm this tool reads a valid
p=value of the expected length. - Send a test and read the receiving side’s Authentication-Results — you want
dkim=passwith ad=that aligns to your From domain.
Frequently asked questions
- What is a DKIM selector and where do I find it?
- A label that lets a domain host multiple DKIM keys. The key lives at
<selector>._domainkey.yourdomain.com. Read it from thes=tag of a sent message’sDKIM-Signatureheader. - What key length should I use for DKIM?
- At least 1024-bit RSA, with 2048-bit recommended today. Avoid 512-bit — it’s breakable and widely rejected.
- DKIM passes but DMARC still fails — why?
- DKIM has to be aligned — the signature’s
d=must match your From domain. A valid signature from your ESP’s own domain isn’t aligned. Sign as your domain via the CNAMEs your provider gives you. - Do I need DKIM if I already have SPF?
- Yes — SPF breaks on forwarding, DKIM survives it. DMARC needs at least one aligned pass, and having both is far more robust.