DKIM Replay: How Spammers Borrow Your Good Reputation

DomainKeys Identified Mail (DKIM, defined in RFC 6376) lets a sending domain attach a cryptographic signature to outgoing mail. The signing server hashes a chosen set of headers plus the message body, signs that hash with the domain's private key, and stamps the result into a DKIM-Signature header. Any receiver can fetch the matching public key from DNS and confirm two things: the signed content wasn't tampered with in transit, and the signature was produced by someone holding that domain's private key.

That confirmation feeds directly into spam filtering. A message carrying a valid DKIM signature from a domain with a strong sending reputation — say, a large consumer mail provider — gets a meaningful trust boost. It is more likely to skip the spam folder. And here is where the attack begins.

The replay trick

A DKIM signature does not say "this message is going to this recipient." It says "this content was signed by this domain." The SMTP envelope — the actual RCPT TO that decides where a message is delivered — is not part of what DKIM signs. Neither, typically, is the full set of headers; only the ones the signer chose to cover.

So an attacker does this:

1. They open an account at a reputable mail provider whose outbound mail carries that provider's DKIM signature.
2. They send themselves a single message — crafted as spam or phishing — and let the provider sign it on the way out.
3. They capture that fully-signed message, headers and all.
4. They re-inject the identical message into the internet thousands or millions of times, addressing each copy to a different victim via the SMTP envelope.

Every copy still carries an intact, mathematically valid DKIM signature from the reputable domain. Receivers verify it, see the trusted signing domain, and grant the reputation boost — to spam the reputable provider never intended to blast at the world.

Why the signature keeps verifying

Two design choices make replay easy when they're handled carelessly.

The header set is selective. The signer lists which headers it covers in the h= tag. If a header isn't listed, it isn't signed — and a verifier still passes the message. Crucially, "absent" headers can sometimes be added after signing without breaking verification, depending on the configuration. The envelope recipient is never covered, which is the whole point of the replay.

The body length tag. DKIM's optional l= tag tells the verifier to sign only the first N bytes of the body. Anything appended after that boundary isn't covered by the signature but still verifies fine. An attacker who finds a signed message using l= can staple their own content onto the end. This is why current guidance is blunt: do not use the l= tag at all.

A DKIM pass is not an endorsement of the message's purpose. It is a statement that the bytes the signer covered are unchanged. Reputation systems that treat a pass as "this domain vouches for this email going here" are reading more into the signature than the math provides.

What DKIM replay is not

It is easy to confuse this with related problems, so a quick map:

Technique	What the attacker does
DKIM replay	Re-sends a genuinely signed message to new recipients to ride the signer's reputation. The signature is real and valid.
Spoofing	Forges the From: address with no valid signature at all. DMARC and DKIM are designed to catch this.
Forwarding breakage	A legitimate forward (e.g. a mailing list) modifies the body and breaks DKIM — the opposite failure, addressed by ARC (RFC 8617).

Note that DMARC does not help here. DMARC requires that a passing DKIM (or SPF) result be aligned with the visible From: domain. In a replay, the From: domain genuinely is the reputable signer — the attacker never had to forge it. Alignment passes, because nothing about the identity is fake. The message is authentic; only its distribution is abusive.

Closing the door

Defense splits between senders (who don't want their signatures weaponized) and receivers (who don't want to be fooled by a replay).

If you sign mail

• Oversign critical headers. List headers like From, To, Subject, and Date twice in the h= tag so that adding a second copy of them after signing breaks verification.
• Never use the l= body-length tag. Sign the whole body, every time.
• Rotate DKIM selectors regularly and retire old keys, shrinking the window in which a captured signature stays live.
• Rate-limit and monitor outbound volume per account, so a single user firing one weird message that then appears everywhere is detectable upstream.

If you receive mail

• Treat a DKIM pass as one weak signal, not a verdict. Combine it with envelope analysis, volume anomalies, and recipient-spread heuristics.
• Flag the fingerprint of a "one message, suddenly everywhere" pattern — the same signed body landing in many unrelated mailboxes in a short window is the signature of a replay campaign.
• Weight reputation by the sending IP and path, not by the signing domain alone.

The deeper lesson

DKIM replay is a reminder that authentication and authorization are different things. DKIM authenticates: it proves who signed and that the content is intact. It was never meant to authorize a particular delivery. The abuse exists because reputation systems quietly promoted a proof-of-origin into a proof-of-intent.

This is the same lesson that runs through almost every email-security story: the protocols do exactly what they say, and trouble arrives when we lean on them to do something they never claimed. If you want a sense of how much of email security is built from these narrow, composable proofs, our piece on email authentication walks through how SPF, DKIM, and DMARC fit together — and where each one's guarantee stops.