DKIM Replay Attacks

DKIM replay is an infrastructure attack against senders, not a message-forgery attack against recipients. An attacker obtains one legitimately DKIM-signed message from a reputable domain and retransmits it — verbatim — to millions of new recipients. Because DKIM (RFC 6376) authenticates content, not transport path or envelope, every copy still carries a valid signature: the d= domain "vouches" for spam it never sent to those recipients, and its reputation is spent by the attacker.

The problem statement is documented in draft-ietf-dkim-replay-problem (Chuang/Google, Crocker, Robinson/Google, Gondwana/Fastmail). Status as of this extraction (2026-07): the draft's last revision (-00) is dated 2023-07-28 and has expired; the IETF DKIM working group has since moved from problem statement to solution work — see DKIM2. It remains the reference articulation of the attack.

Attack mechanics

1. Attacker creates or compromises an account at a high-reputation sender — a free mailbox provider, or an ESP free trial — and gets one message signed by the target's d= domain. The message content is the attacker's payload (spam/phish), or a benign message the payload can be smuggled into (see l= below).
2. Attacker captures the fully signed message (they are the recipient, so this is trivial — send it to themselves).
3. Attacker re-injects the message through their own infrastructure to an arbitrarily large new recipient list. The RFC 5321 envelope (MAIL FROM, RCPT TO) is not signed, so it can be freely rewritten; the RFC 5322 headers and body are untouched, so bh= and b= still verify.
4. Receivers see: valid DKIM signature, aligned d= from a trusted domain, DMARC pass. Reputation systems attribute the mail volume — and the ensuing complaints and spam classifications — to the signing domain.

Nothing in RFC 6376 is violated. Indeed the RFC explicitly notes that re-mailing a signed message is indistinguishable from legitimate forwarding — which is precisely the property that lets DKIM survive forwarding where SPF breaks. The core difficulty, per the draft: receivers cannot differentiate legitimate forwarding flows (alias forwarding, mailing lists, "send to a friend") from a replay attack. Any naive fix that kills replay also kills forwarding.

Why existing DKIM tags don't fix it

Tag	Why it fails
l= (body length)	Orthogonal at best, actively harmful at worst: it limits which body octets are signed but does nothing to bind recipients. Worse, l= lets the replayer append unsigned malicious content that renders after the signed portion while the signature still validates (exploited in the wild, 2024). Never sign with l=.
x= (expiration)	Time-limits signature validity, but cannot distinguish a legitimate 2-hour forwarding delay from a 2-hour replay campaign. Replay campaigns blast their volume within minutes of obtaining the signed message — well inside any x= window generous enough for real-world delivery delays (queue retries, greylisting, mailing-list digests). RFC 6376 itself says x= is not an anti-replay defense.
t= (timestamp)	Informational only; same window problem as x=.
Signing To:	The To: header is typically signed — but replay doesn't modify it. The spam is delivered to RCPT TO recipients who don't appear in the signed To:. A mismatch between signed To: and actual recipient is also normal (Bcc, aliases, forwarding, mailing lists), so receivers can't hard-fail on it.

Current mitigations and tradeoffs

No complete fix exists within DKIM as specified; these reduce exposure and blast radius. (The protocol-level fix is the DKIM2 effort, which binds signatures to the SMTP envelope per hop.)

Sender/ESP side

Mitigation	Mechanism	Tradeoffs
Oversigning	List To:, Subject:, From:, Reply-To:, Cc: in h= one more time than they occur, so a replayer cannot add another instance (e.g., a second Subject that some MUAs display) without breaking the signature.	Cheap, do it always. Defeats header-addition variants only — pure verbatim replay is untouched.
Short x= expiration	Sign with x= a small number of hours after t=. Narrows the replay window; stale replayed copies fail.	Legitimate delayed delivery (retries after a receiver 4xx, greylisting) fails verification too; many verifiers ignore x= entirely; attackers replay fast.
Per-stream / per-tenant selectors and d= isolation	Sign each customer or mail stream with its own selector or subdomain, so a replay incident burns one tenant's identifier, not the shared platform domain.	Doesn't prevent replay; contains the reputational blast radius and makes the abusive tenant identifiable and revocable (publish empty p= to kill the selector). Key-management overhead at ESP scale.
Per-recipient signing	Compute a distinct signature per RCPT TO (recipient bound into signed content, e.g. via a signed per-recipient header).	The strongest in-protocol option, but: one signing operation and one distinct message body/header set per recipient (kills multi-RCPT delivery efficiency); breaks legitimate forwarding to a different address; no standard for how verifiers should check the binding.
Content/recipient vetting before first signature	The attack requires obtaining one signed payload — so trial-account abuse controls, outbound content scanning, and URL reputation checks at signing time are DKIM-replay controls.	Arms race; benign-looking payloads (the l= trick, remote content) evade scanning.
Volume anomaly monitoring	Watch Google Postmaster Tools / FBL data for spam-rate and volume spikes on a d=/selector that don't match your own send logs — the signature of a replay in progress.	Detection, not prevention; response is selector revocation + provider escalation.

Receiver side (what the draft discusses)

• Counting / rate observation: the same signature (or bh=) suddenly seen across an anomalously large, uncorrelated recipient set is a replay fingerprint. Requires large-scale visibility (favors big mailbox providers) and cross-system coordination.
• Envelope/header divergence signals: replayed mail typically shows MAIL FROM/RCPT TO domains unrelated to the signing domain and to the signed To:. Usable as a scoring signal, not a hard rule (forwarding produces the same shape).
• Receivers are advised to treat a valid DKIM signature as an identifier for reputation, not a whitelist token — replay is exactly the weaponization of signature-equals-trust shortcuts.

Impact on ESPs

• ESPs are a preferred harvesting target: free trials hand attackers a signing oracle for a domain with warmed reputation. One signed message from a trial account can be replayed at a volume exceeding the ESP's entire daily legitimate send.
• The damage lands on whatever d= signs the message. Shared-domain signing (all customers under the ESP's domain) means one incident degrades delivery for every customer — the strongest architectural argument for customer-specific d=/selectors (see M3AAWG Sending Domains BCP).
• Incident response: identify the replayed message (FBL samples, Postmaster spam-rate spike), revoke the selector (empty p=), suspend the originating account, and rotate to a new selector for the legitimate stream. Keep old selectors' keys distinct per stream so revocation is surgical.
• Do not respond to a replay incident by adding l= or removing To: from h= — both make things worse.

Related

• DKIM — base protocol, oversigning and l= details
• DKIM2 — the in-progress protocol redesign whose envelope binding is the actual fix
• Reputation Monitoring — detecting the spike