DKIM Replay Attacks: How Spammers Weaponize Your Valid Signatures

A DKIM signature stays valid no matter who forwards the message. How replay attacks abuse that property to spend your reputation, and the defenses that limit the damage.

DKIM proves that a message existed in a specific form and was signed by a specific domain. It deliberately proves nothing about who transmitted the message to whom, which is what allows forwarding to work. A replay attack turns that design property into a weapon: the attacker obtains one legitimately signed message and re-transmits it at scale, spending the signing domain's reputation on traffic the signer never sent.

Anatomy of a replay

The attack starts with a legitimate account. The attacker signs up for a service with a strong sending reputation, a large ESP customer, a SaaS product with transactional mail, a freemail provider, and provokes a signed message they control some content of: an invite, a shared document notification, a message with attacker-chosen text in a display name or comment field.

That single message, captured at the attacker's own mailbox, carries a valid DKIM signature from the reputable domain. The attacker then re-transmits it from their own infrastructure to millions of addresses. SPF fails, but DKIM passes, and if the signing domain is DMARC-aligned, DMARC passes too. Filters see authenticated mail from a trusted domain, and initial waves often reach the inbox.

The cost lands on the signer

Mailbox providers attribute authenticated traffic to the DKIM domain. When the replayed wave draws spam reports, the complaints accrue to the signing domain's reputation, not to the attacker's IPs. Victims see Postmaster Tools reputation slide, complaint rates spike, and filtering tighten, all while their own send logs show nothing unusual. That disconnect, reputation damage without corresponding sends, is the diagnostic signature of a replay.

Gmail addressed the pattern directly in its bulk sender guidance, and large senders have responded by tightening signature scope and rotation. The economics explain the attention: for an attacker, a valid signature from a major ESP is a temporary skeleton key, and for the signer, the key keeps working until it expires or rotates.

Defenses that actually help

Oversign the mutable headers

DKIM's h= tag lists the headers covered by the signature. Signing a header that does not exist yet (listing it twice, or once more than it appears) prevents an attacker from adding it later without breaking the signature. Oversign Subject, From, To, Cc, Reply-To, and Date so a replayer cannot append a second Subject or Reply-To that many clients would display in place of the original.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s2025a;
  h=from:from:to:to:cc:cc:subject:subject:date:date:
    reply-to:reply-to:message-id:message-id;
  bh=...; b=...

Never use the l= tag

The l= tag limits the signature to the first N bytes of the body, allowing anything appended after that point to ride along without invalidating the signature. It exists for a forwarding edge case that no longer justifies it. Security research in 2024 demonstrated practical exploitation against senders still using it, and the current consensus, reflected in provider guidance, is simple: do not set l= at all.

Shrink the replay window

The x= tag sets a signature expiry timestamp. A short expiry, hours rather than days, limits how long a captured message stays weaponizable, at the cost of breaking validation for slow delivery paths and late forwards. More practically, aggressive selector rotation bounds the damage: once the private key for a selector is retired and its DNS record removed or replaced, previously captured signatures can no longer be validated against a live key. Rotating immediately is also the standard containment move during an active replay incident.

Make attacker-influenced mail distinguishable

ESPs and platforms whose users can trigger signed mail should sign user-generated streams with a different selector or subdomain than their own corporate and transactional mail. Segmented signing identity means a replay incident burns the segment, not the whole domain, and postmaster teams can trace an abusive signature to the product surface that produced it.

Detecting a replay in progress

Replay abuse is the price of DKIM's portability, and it falls on whoever signs carelessly. Audit your h= list, delete any l= tag, segment your signing identities, and rehearse a fast selector rotation. The attack only works at scale against signers who made a single signature too powerful and too durable.