What is DKIM, and how does it prove an email wasn't tampered with?

What a DKIM record looks like

The public key is published in DNS under a very specific name: <selector>._domainkey.example.com. Here's a concrete example of a TXT record:

s1._domainkey.example.com.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

The tags that matter, one by one:

• s= (the selector) — this isn't a tag inside the record, but the prefix of the DNS name. The selector allows several keys in parallel: one per sending provider, or an old one and a new one during a rotation. It's the pivot of all DKIM management. We explore it in depth in the role of the DKIM selector.
• p= (the public key) — the public key, base64-encoded. This is the heart of the record. Crucial detail: deleting p= or emptying its value revokes the selector — receivers then treat the key as withdrawn. It's the clean way to disable a compromised key.
• k= (the algorithm) — the key algorithm, rsa being by far the most common. Some modern infrastructures also accept ed25519, which is more compact and often published as a second selector alongside RSA.
• v=DKIM1 — the version, present at the start of every record.

One thing that trips up beginners: the public key is often too long to fit in a single 255-character DNS string. It then gets split into several quoted strings, which the resolver stitches back together. That's not an error — it's normal behavior.

Selectors and rotation: the real DKIM craft

This is where DKIM goes from "it works" to "it works cleanly and lasts." The selector is the keystone for two recurring needs.

A distinct selector per sending source. Where mail leaves through Google Workspace and a marketing platform and an in-house transactional server, each one gets its own selector with its own key pair. The payoff is huge: the day a provider is compromised, or the contract ends, only that selector is revoked (by removing its p=), without touching the others. The remaining streams keep signing and passing without interruption.

Regular rotation. A DKIM key isn't forever: the longer it lives, the greater the risk it leaks. Best practice is to rotate it periodically, and the selector makes the operation painless:

1. Generating a new key pair and publishing the new public key under a new selector (e.g. s2), leaving the old one (s1) in place.
2. Switching the sending server over to sign with the new key (s2).
3. Waiting until all mail signed with the old key has been delivered (a few days of margin).
4. Removing the old selector (s1) from DNS.

No interruption, no rejected message during the switch. We walk through the full procedure, with the pitfalls, in how to rotate a DKIM key without breaking deliverability. And for a start from scratch, our guide on generating a DKIM key pair has the exact commands.

Key size: 1024 vs 2048 bits

The RSA key length determines its strength. Two sizes are still in circulation today:

• 1024 bits — historically the default standard, still accepted by receivers, but now considered weak. A 1024-bit key remains crackable by a motivated attacker with resources, and more and more providers are deprecating it.
• 2048 bits — the choice to prefer. It's the recommended standard today, offering a comfortable security margin for years to come. Nearly all DNS providers and sending platforms support it effortlessly.

The only historical constraint of 2048-bit keys was DNS record length (hence the string-splitting mentioned earlier), but that's no longer a real obstacle. Anything new is generated at 2048 bits, without exception. A domain still running 1024 uses its next rotation to move up — exactly the kind of switch selectors make easy. We compare the two in detail in DKIM 1024 vs 2048 bits: which to choose.

Signed body, signed headers: what DKIM really protects

A useful subtlety: DKIM doesn't blindly sign the whole message. It signs the body and a chosen list of headers (declared in the signature's h= tag). Headers not listed can change without breaking the signature — which is intentional, since some technical headers are legitimately rewritten by intermediate servers.

This distinction explains a common phenomenon: an email can be modified in transit (a gateway adding an "external" banner, a mailing list appending a footer) and see its DKIM signature break, because the signed body is no longer identical. That isn't necessarily an attack — sometimes it's just an overzealous intermediary. It's precisely to tell these cases apart that we cross-check DKIM against the other signals. For a look at a real signature, how to verify a DKIM signature walks through each tag by hand.

DKIM and forwarding: where it shines

Here's DKIM's decisive advantage over SPF. When an email is forwarded — say, from a work address to a personal @gmail.com — the sending IP changes: it's now the forwarding server delivering the message. As a result, SPF breaks, because the forwarder's IP isn't in the sender's SPF record.

DKIM, by contrast, survives forwarding much better. The signature travels with the message; as long as the signed body and headers aren't modified, the signature stays valid even after several hops. That's why DKIM is often the only mechanism that "holds" on forwarded mail, and why it's essential to deploy it correctly. A domain that relies on SPF alone will see part of its legitimate mail fail authentication the moment it passes through a forward.

Why DKIM isn't enough: DMARC goes on top

Here's the point never to forget. DKIM proves a message is intact and signed by a domain. But it does not verify that this domain matches the one the user sees in the From: field. An attacker can happily sign their mail with DKIM for their own domain (evil.com), pass the DKIM check with no problem, and still display someone else's domain in the From:. DKIM, on its own, doesn't see the lie.

The missing link is called alignment, and it's the job of DMARC. DMARC requires that the domain authenticated by DKIM (the d=) match the visible From: domain. That rule is what turns DKIM from a mere integrity proof into real protection against identity impersonation. Without DMARC, DKIM is a lock on a door the attacker simply bypasses by climbing through the window next to it.

That's why DKIM, SPF and DMARC form a whole. DKIM and SPF provide the evidence; DMARC ties it to the visible domain and tells receivers what to do on failure. For the big picture, the fundamentals, explained without jargon is the entry point — it's the standard that finally gives a DKIM signature meaning.

The order of march

DKIM isn't complicated, but every detail counts: the right selector, a 2048-bit key, a clean rotation, and above all DMARC on top to tie it all back to the visible domain. Here's the order of march I recommend:

• Generating a 2048-bit key and publishing it under a clear selector (one per sending source).
• Confirming that each sending platform actually signs with DKIM — Google and Microsoft enable it in a few clicks, but third-party tools often forget.
• Planning a rotation on a regular cadence via a second selector, without ever cutting the flow.
• Capping it all with DMARC to require alignment and shut the door on impersonation.

Guesswork is avoidable: a free, instant check of any SPF, DKIM and DMARC setup runs through our free DMARC analyzer — it surfaces the detected selectors, the key sizes, and a clear grade. Thomas, the virtual CISO, then names exactly what to fix and in what order.

Free DMARC analysis of a domain or an account, and Thomas handles the rest.