DKIM: Proving a Message Wasn’t Changed — Not Who Sent It

DKIM (DomainKeys Identified Mail) is often described as a way to “verify the sender” of an email.

That description is wrong — or at least incomplete.

DKIM doesn’t verify who wrote an email. It doesn’t confirm that the visible From address belongs to a real person, company, or brand. What DKIM does is narrower, more mechanical, and easier to misunderstand:

It proves that an email hasn’t been altered since it was signed, and that a domain takes responsibility for that exact message.

Think of DKIM as a tamper seal, not an identity badge.

That distinction matters, because many DKIM failures — and false assumptions about “secure email” — come from expecting it to do something it was never designed to do.

DKIM is only one part of a broader system. If you want the full context of how SPF, DKIM, and DMARC fit together, this earlier post explains how email authentication actually works.

What DKIM actually checks

At a technical level, DKIM works by attaching a cryptographic signature to an email when it’s sent.

In simplified terms:

1. The sending server selects specific headers and the message body.
2. It creates a cryptographic hash of that data.
3. That hash is signed using a private key controlled by the sending domain.
4. The signature is added to the message as a DKIM header.
5. When the message arrives, the receiving server:
   • Looks up the public key in DNS
   • Recalculates the hash
   • Verifies the signature

If the values match, DKIM passes.

If anything has changed, DKIM fails.

No scoring. No heuristics. No interpretation.

DKIM answers one question only:

Has this message remained intact since the domain that signed it sent it?

What DKIM ignores completely

This is where confusion creeps in.

DKIM does not:

• Validate the visible From address
• Confirm that the signing domain is one the user recognises
• Stop someone signing mail from a look-alike or disposable domain
• Judge intent, legitimacy, or safety
• Block spam or phishing by itself

A phishing email can be perfectly DKIM-signed — and many are.

If the message wasn’t altered after signing, DKIM will pass, even if the content is malicious. That’s not a flaw. It’s simply outside DKIM’s scope.

Why DKIM exists at all

DKIM was created to solve a practical problem: email often gets modified in transit.

Mailing lists add footers. Gateways rewrite headers. Security tools insert banners. Even innocent formatting changes can break message integrity.

Before DKIM, there was no reliable way for receiving mail servers to know whether a message had been altered — or to hold any domain accountable for it.

DKIM introduced two things:

1. Integrity checking — detecting modification
2. Domain responsibility — a domain explicitly signs what it sends

Importantly, DKIM doesn’t say “this message is good”. It says:

This domain claims ownership of this message, exactly as it appears now.

How DKIM signatures are structured

If you inspect a DKIM-signed email, you’ll see a header that looks dense and unreadable at first glance.

The important parts are:

• d= — the signing domain
• s= — the selector (which key to use)
• h= — which headers were signed
• bh= — hash of the body
• b= — the actual signature

The selector lets a domain rotate keys without breaking mail. Public keys are published in DNS under a record derived from s= and d=.

Receivers don’t need prior trust. They just fetch the key and verify the maths.

Here’s what that looks like in practice — first in DNS, then in the message itself.

A DKIM DNS record example

selector1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
)

Explained in plain English:

• selector1 identifies which key to use
• _domainkey is the fixed DKIM namespace
• p= contains the public key
• The private key never leaves the sending system

DKIM-Signature header snippet

DKIM-Signature: v=1; d=example.com; s=selector1;

Explained in plain English:

• d= identifies the domain that signed the message
• s= identifies which selector the receiver should use to find the public key in DNS
• The signature is created using the domain’s private key
• The private key never leaves the sending system

Why DKIM fails silently

One of DKIM’s biggest problems isn’t cryptography — it’s visibility.

Most users never see DKIM results. Even administrators often only notice failures indirectly, through delivery issues or DMARC reports.

Common causes of DKIM failure include:

• Mailing lists that modify the message body
• Forwarders that re-encode content
• Security appliances that rewrite headers
• Broken canonicalisation settings
• Incorrect DNS records or expired keys

Because DKIM is evaluated automatically and quietly, failures can persist for months without obvious symptoms — until DMARC enforcement exposes them.

Forwarding, mailing lists, and “legitimate” breakage

DKIM is fragile by design.

Any modification to signed parts of the message breaks the signature. That includes changes made with good intentions.

This is why forwarding and mailing lists are such persistent edge cases. SPF often fails because the sending IP changes. DKIM often fails because the content changes.

Modern mailing list software and forwarding services try to work around this in a few ways — sometimes by re-signing messages, sometimes leaving the original signature in place and adding their own. Forwarding services may also re-sign messages under their own domain to maintain authentication. Even with these techniques, DKIM remains sensitive to modification, and the problem never fully disappears.

DKIM assumes a relatively clean, predictable path from sender to receiver. Email, in practice, rarely behaves that way.

Why “DKIM pass” doesn’t mean “trusted”

A DKIM pass is often treated as a badge of legitimacy. It isn’t.

DKIM doesn’t express reputation, history, or intent. It expresses continuity.

That continuity becomes meaningful only when it’s tied to something users recognise — and that’s where DMARC enters the picture.

Without DMARC alignment, a DKIM-signed message can say:

This message was signed by a domain you’ve never heard of.

And still pass.

Where DKIM fits in the bigger picture

DKIM is one piece of a larger system:

• SPF checks where a message came from
• DKIM checks whether it was changed
• DMARC decides whether those results are acceptable

On its own, DKIM is a signal.

With DMARC, it becomes enforceable policy.

That policy — alignment, reporting, and enforcement — is what finally connects technical authentication to user-visible trust.

Understanding DKIM means accepting its limits

DKIM is not a security stamp. It’s not a trust guarantee. It’s not proof of identity.

It’s a narrow, precise tool that answers one question extremely well — and ignores everything else.

Once you understand that, DKIM stops being mysterious. And when combined properly with SPF and DMARC, it becomes one of the quiet foundations that makes modern email workable at scale.

DKIM tells a receiving server whether a message arrived intact, and SPF tells it whether the sending server was authorised — but neither answers the final, practical question: what should happen when those checks fail?

That decision is left to DMARC, which ties SPF and DKIM to the domain users actually see, sets expectations for receivers, and turns passive signals into enforceable policy. Without DMARC, SPF and DKIM remain useful — but incomplete.

DKIM proves message integrity, not identity.

To see how DKIM fits alongside SPF — and how DMARC turns those signals into policy — continue with the SPF and DMARC explainer.

For a formal specification of how DKIM works, including signature formats and verification rules, see the official DKIM documentation at dkim.org.