Signature replay

DKIM signs a message, not a delivery. Nothing in a signature names a recipient, a connection or a time, so a validly signed message can be captured and re-sent, unchanged, to anyone — and it verifies. That is replay, and it is a property of the design rather than a bug in anyone’s implementation.

How the abuse works

1. Attacker opens a free account on a large, reputable platform
2. Sends themselves one message, carefully crafted
3. The platform signs it:  d=<the platform's domain>, valid
4. Attacker captures the raw message including its signature
5. Re-sends the identical bytes to millions of recipients
6. Every receiver verifies the signature and sees a good domain

The recipients in the envelope are entirely the attacker’s choice, because the envelope is not signed. The message body reaching a million inboxes is byte-identical to one a reputable provider signed, and the signature is genuinely valid. Receivers relying on the signing domain’s reputation deliver it.

What limits it

x=, the expiry tag. A signature with a short x= stops verifying after its window closes. This is the most direct defence and the reason large senders have started setting it. It costs a little tolerance for delayed mail.
Oversigning To and Cc. Signing them commits to the displayed recipient, so the replayed copy shows the attacker’s own address to every recipient. It does not stop delivery; it makes the message obviously wrong.
Rate limiting and account vetting at the platform. This is where the real mitigation lives, and it is not a protocol matter.
Receiver-side detection. The same signature arriving from thousands of unrelated IPs in a short window is a strong and detectable signal. Large receivers act on it.

What it means for your domain

Replay is mainly a problem for platforms that sign for anyone who signs up. If your signing is confined to your own mail, the exposure is limited to messages an attacker can induce you to send them — a password reset, a receipt, an automated reply. Those are worth thinking about precisely because they are easy to trigger on demand.

Setting x= on your own mail

A window of a few days covers legitimate retry behaviour and closes the replay value of an old message. It is not free: mail delayed beyond the window loses its signature and therefore its DMARC pass, so the window has to exceed the longest retry you are willing to have delivered. Most domains do not need this; high-value transactional streams sometimes do.

Knowledge check

Why does re-sending a signed message to a different recipient not break the signature?

The envelope recipient is not covered by DKIM, and the signature covers only headers named in h= plus the body.
Receivers do not verify signatures on forwarded mail.
The To header is rewritten by the sending server, so it no longer matches anyway.
The signature covers the body only, so any header can be changed.

Correct — The envelope recipient is not covered by DKIM, and the signature covers only headers named in h= plus the body. DKIM never sees RCPT TO. Even oversigning the To header only commits to what is displayed, not to where the message is actually delivered — the two are independent, which is exactly what replay exploits.

Not this — Receivers do not verify signatures on forwarded mail. They do, and that is the point — the replayed message verifies. Nothing about this depends on the receiver skipping verification.

Not this — The To header is rewritten by the sending server, so it no longer matches anyway. A replayed message is sent byte-for-byte unchanged. Nothing rewrites anything; that is what makes the signature survive.

Not this — The signature covers the body only, so any header can be changed. It covers the headers in h= as well. Replay works without changing any header at all.

How the abuse works

What limits it

What it means for your domain

Try it on a real domain