DKIM replay: when a valid signature carries spam

Unsigned headers as an attack angle

Basic replay resends the message identically. A finer variant exploits what the signature does not cover. The h= tag lists precisely which headers are signed; any header absent from that list escapes protection and can therefore be added or modified without invalidating the signature.

The consequences are concrete. If Subject is not in h=, the subject line can be rewritten at will to fit each campaign, without touching the hash. If To is not signed, the displayed recipient can be forged. More devious still: injecting a duplicate header. Many mail clients display the first — or the last — occurrence of a header; if the signer signed only one, adding a second Subject or a second From slips past verification while changing what the human sees on screen. The replayed message thus personalizes itself for each victim, while the original signature stays technically intact: it only ever covered what the signer chose to include.

The defenses, mostly on the signing side

The difficulty comes down to an imbalance: the recipient sees only a valid signature and holds almost no lever. The real defenses live with whoever signs — a large sender, an ESP, a mailbox provider.

• Sign broadly. The first defense is to include in h= every header that carries meaning: From, To, Cc, Subject, Date, Message-ID, Reply-To, Content-Type, and more. The wider the coverage, the less unsigned surface remains to manipulate. An h=from pared down to the bare minimum leaves everything else open to tampering.
• Oversigning. The technique consists of signing a header more times than it actually appears in the message — for instance by declaring h=from:from:to:to:subject:subject:…. Adding an extra occurrence of one of those headers then breaks the expected count, and verification fails. It is the direct counter to duplicate-header injection: it forbids adding a second Subject or a second From without breaking the signature.
• Short-lived keys and regular rotation. A replayed message stays verifiable only as long as its associated public key is published. Rotating keys and retiring old selectors shortens the window during which a captured signature remains valid — one of the benefits of signing-key renewal. The limit is clear: rotation does not stop an immediate replay, since most of the damage happens in the hours right after capture, well before any reasonable rotation.
• The x= tag, with its limits. DKIM allows dating a signature's expiry through the x= tag (a timestamp). Past that point, a verifier may reject the signature. In theory, a short window shrinks the time useful for replay. In practice, three caveats apply: not every verifier enforces x=; too tight a window makes legitimate delayed mail fail (queues, forwards, greylisting delays); and a few minutes are often enough to launch a mass send. The tag reduces the risk, it does not remove it.
• Watch for abnormal spikes. On the signing side, replay leaves the trace described above: a burst of "DKIM-only" messages from addresses foreign to the usual sending fleet. A legitimate domain emits from a stable set of IPs; a spike that departs from it signals a replay in progress, and regular report reading is the only way to catch it early.

One point deserves to be stated plainly, because it invites confusion: lengthening the key from 1024 to 2048 bits protects against forging a signature, not against replay. Here the key is never broken — a genuine signature is simply reused. Conflating the two threats leads to reinforcing the wrong lock.

What DMARCbis changes (and does not)

DMARCbis, the current standard described by RFC 9989, 9990 and 9991, modernizes several mechanisms: the Public Suffix List gives way to the DNS Tree Walk, the pct tag disappears in favor of a test mode carried by t=, and new tags such as np or psd refine subdomain handling. None of these changes touches replay.

The reason is structural: DMARCbis still reasons at the alignment level, and it keeps returning pass on a valid, aligned DKIM signature. Replay operates one layer below, in DKIM itself, where DMARCbis adds neither a counter nor any notion of a unique recipient. Migrating to the current standard remains worthwhile for other reasons, but it does not close this door. The IETF community is separately working on extensions meant to make DKIM replay-resistant — tying a signature to a send, a volume, or a trajectory — but that work is not yet a widely deployed standard in 2026. As things stand, the defense remains organizational, not protocol-level.

Who is really affected

Replay targets, above all, the identities worth borrowing. Large senders, email platforms and mailbox providers that offer free or trial accounts concentrate the problem: their good reputation is the coveted asset, and the trial account is the capture vector. For them the stake is operational and permanent — their name serves as the vehicle for spam, and their deliverability suffers. That is where broad signing, oversigning, trial-account abuse detection and rate limiting earn their keep.

A small-business domain sits in a different position. Its reputation usually holds too little value to make it a replay target: an attacker gains nothing from sending under the name of a small, unknown domain. So the small domain is rarely the source of a replay. It can, however, be a recipient — and there, no DMARC setting will filter a message that legitimately passes every check; only classic spam filtering remains in play. The useful lesson for a small domain is broader: signing cleanly and oversigning key headers stays a low-cost hygiene, and above all, a valid signature authenticates a domain, never an intent. It is the same foundation used to prevent email spoofing: authentication proves origin, not goodwill. To see concretely what a signature covers and what it leaves open, reading a signature in the headers in a received message is the basic exercise.

In summary

DKIM replay exploits an intentional property of the protocol: a valid signature stays valid as long as the body and signed headers do not change, with no link to the original send or the recipient list. A message signed once by a reputable domain — often via a trial account — is redistributed en masse and clears the filters thanks to a borrowed reputation. DMARC sees nothing, because everything is technically correct; unsigned headers add an angle for disguise. The defenses live on the signing side: a broad h=, oversigning, key rotation, the partially effective x= tag, and spike monitoring. DMARCbis does not close this door, and the risk weighs mostly on large senders, far more than on a small-business domain.

A first diagnosis costs nothing: the free DMARC analysis reveals the state of a domain's signatures, the stability of its sending sources, and the alignments in place. To track signed-header coverage over time and spot the abnormal spikes in reports — the quiet signal of a replay — creating an account opens the continuous monitoring that this threat, silent by nature, makes necessary.