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

When an email lands in your inbox, nothing in the original mail protocol guarantees it really came from who it claims, or that it wasn't tampered with along the way. DKIM closes part of that gap by attaching a verifiable cryptographic signature to every message. The sending server signs the message with a private key; the receiver fetches the public key from your DNS and confirms nothing changed. This guide explains what DKIM is, how the signature works, how to publish your record, how to handle selectors and rotation — and why DKIM alone isn't enough without DMARC.

What DKIM actually is

DKIM (DomainKeys Identified Mail), defined in RFC 6376, is an authentication mechanism that proves two things at once: that the message was authorized by the signing domain, and that it was not altered between sending and delivery. It relies on asymmetric cryptography, exactly like HTTPS: a key pair, a private key you keep secret on your sending infrastructure, and a public key you publish openly in DNS.

On the way out, your server computes a signature over selected headers of the message (typically From, Subject, Date…) and the body, using the private key. That signature travels with the message in a dedicated header. On arrival, the receiving server fetches the matching public key from your DNS and recomputes the signature. If the result matches, you get two certainties: the message came from a source holding your private key, and it is intact — not a single byte of the signed content was modified in transit.

This is a fundamental difference from SPF, which only checks which IP sent the message. SPF never looks at the content; DKIM seals it. The two are complementary, and you need both.

How the signature works, step by step

The mechanism comes down to three moments. Once you can picture it, everything else falls into place.

1. On sending — the server signs. Your sending server (or platform: Google Workspace, Microsoft 365, your marketing sender…) takes the message, selects a list of headers to protect plus the body, then computes a cryptographic signature with the private key. It inserts a DKIM-Signature header into the message. That header carries three decisive pieces of information: the signing domain (d=), the selector (s=) and the signature itself (b=), plus the list of covered headers (h=).

2. On receiving — the server fetches the public key. The receiver reads the DKIM-Signature header, finds d=your-domain.com and s=s1, and knows exactly where to look for the public key: at the DNS name s1._domainkey.your-domain.com. It makes a simple TXT DNS lookup and retrieves the key.

3. Verification — the receiver recomputes. With the public key, the receiving server recomputes the signature over the same headers and the same body. If it matches, the message is declared intact and authenticated for the signing domain. If not, DKIM fails: either the message was modified, the key didn't match, or the signature was missing.

This whole dance is automatic and invisible to the human reading their mail. It plays out in a few milliseconds, in the background, for every single email.

What your DKIM record looks like

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

s1._domainkey.your-domain.com.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Let's break down the tags that matter:

• s= (the selector) — this isn't a tag inside the record, but the prefix of the DNS name. The selector lets you publish 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 your keystone for two recurring needs.

A distinct selector per sending source. If you send through Google Workspace and a marketing platform and your own transactional server, give each one its own selector with its own key pair. The payoff is huge: the day a provider is compromised, or you leave them, you revoke only that selector (by removing its p=) without touching the others. Your 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. Generate a new key pair and publish the new public key under a new selector (e.g. s2), leaving the old one (s1) in place.
2. Switch your sending server to sign with the new key (s2).
3. Wait until all mail signed with the old key has been delivered (a few days of margin).
4. Remove 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 if you're starting from scratch, our guide on generating a DKIM key pair gives you 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. Always generate 2048-bit keys for anything new. If you're still running 1024, use your next rotation to move up to 2048 — 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. If you want to inspect a real signature, how to verify a DKIM signature shows you how to read 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 your 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: you need DMARC 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 your 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 impersonation of your identity. 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 your visible domain and tells receivers what to do on failure. For the big picture, start with what is DMARC — it's the standard that finally gives your DKIM signature meaning.

Take action

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 your visible domain. Here's the order of march I recommend:

• Generate a 2048-bit key and publish it under a clear selector (one per sending source).
• Confirm each of your sending platforms actually signs with DKIM — Google and Microsoft enable it in a few clicks, but third-party tools often forget.
• Plan a rotation on a regular cadence via a second selector, without ever cutting the flow.
• Cap it all with DMARC to require alignment and shut the door on impersonation.

Don't want to guess where you stand? Run a free, instant check of your SPF, DKIM and DMARC setup with our free DMARC analyzer — it shows your detected selectors, your key sizes, and a clear grade. Then let Thomas, your virtual CISO, tell you exactly what to fix and in what order.

Analyze your domain for free → or create an account and let Thomas handle the rest.