What is DKIM?
DKIM — DomainKeys Identified Mail — is the second of the three email authentication standards, and the one doing the heaviest lifting in modern email. Where SPF asks "did this message come from an approved server?", DKIM asks a better question: "does a domain cryptographically vouch for this exact message?"
You do not need to understand cryptography to understand DKIM. You need one image: a tamper-evident seal.
A tamper-evident seal for email
When your mail server (or your email provider's server) sends a message, it computes a digital signature over the message body and a chosen set of headers — From, Subject, Date and so on — using a private key that only the sender holds. That signature is attached to the message as an extra header.
The receiving server then fetches the matching public key from the sender's DNS and verifies the signature. If it checks out, two things are proven at once:
- the message was genuinely authorised by the signing domain, and
- neither the signed headers nor the body were altered anywhere along the way.
That is exactly what a tamper-evident seal on a parcel does: an intact seal tells you who sealed it and that nobody opened it in transit. Change so much as one character of a signed part, and the seal breaks.
The seal itself travels in a DKIM-Signature header. Trimmed to the parts that matter:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
h=from:to:subject:date; bh=4mXeI0...; b=KpB2fA...Two tags in that header do most of the work: d= and s=.
d= — the domain that vouches
The d= tag names the domain taking responsibility for the message — the domain whose DNS holds the public key, and the domain whose reputation is on the line. When people say "the message passed DKIM", the precise statement is: "the message carries a valid signature from the domain in d=".
Note what DKIM does not require: d= does not have to match the From address your reader sees. Any domain can sign any message. That flexibility is a feature — it is how an email provider can sign on your behalf — but it is also a gap, because a phishing message signed by attacker-domain.example still "passes DKIM". Closing that gap is DMARC's job: it checks whether the signing domain aligns with the visible From domain, which we cover in DMARC alignment explained.
Selectors: where the public key lives
The s= tag is the selector — a label that tells receivers which key to fetch. The receiver combines the selector and the domain into a DNS name of the form selector._domainkey.domain and looks up the TXT record there:
mail2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC..."The long p= value is the public key itself.
Selectors exist so a domain can hold many keys at once. Your transactional provider signs with one selector, your newsletter tool with another, your own mail server with a third — and, as we will see below, selectors are also what makes replacing a key painless.
DKIM survives forwarding — SPF doesn't
Here is the property that makes DKIM the workhorse of email authentication: the signature travels inside the message.
SPF is evaluated against the IP address of whichever server made the final delivery, so ordinary forwarding — an old mailbox redirecting to a new one, an alias at your university relaying to Gmail — breaks it. DKIM does not care which servers a message passed through. As long as the signed content arrives unmodified, the seal verifies, whether the message travelled one hop or five.
The honest caveat: unmodified is doing real work in that sentence. Traditional mailing lists that add a [list-name] tag to the subject or append a footer to the body are modifying signed content — and the seal breaks, exactly as a tamper-evident seal should. For most domains this affects a tiny sliver of traffic, but it is worth knowing the pattern when you see occasional DKIM failures from list servers in your DMARC reports.
Key rotation basics
Cryptographic keys should not live forever: the longer a private key exists, the longer it has to leak, be stolen, or be quietly brute-forced. Two habits keep DKIM healthy:
- Use 2048-bit RSA keys. 1024-bit keys are still seen in the wild but are considered weak; 2048 is the accepted standard.
- Rotate periodically — every six to twelve months is a common policy. Selectors make this seamless: generate a new key pair, publish the public key under a new selector, switch your server to sign with it, then retire the old record after a few days once in-flight mail has cleared.
If a provider sends on your behalf, rotation is usually their problem — the CNAME records they had you publish let them swap keys without involving you. That is one less thing to maintain, and a good reason to prefer providers that do it.
Checking your DKIM setup
DKIM is working when three things are true: your mail carries a signature, the public key is reachable in DNS, and the signing domain is yours — not just your provider's. You can verify the DNS half right now with the free DKIM lookup tool, which fetches and validates the key at any selector you name.
Then complete the picture: SPF covers the server list, and DMARC alignment ties both checks to the From address your recipients actually see.