DKIM Replay Attacks, Explained Properly

The Gap Between "Validly Signed" and "Sent as Intended"

DKIM answers one specific, narrow question extremely well: has this exact signed content been altered since it was signed, and was it genuinely signed by someone holding the private key for the claimed domain. It says nothing at all about how many times that content has been delivered, to whom, or when. That's not an oversight or a design flaw — it's simply outside what DKIM set out to verify in the first place. But it creates a specific, exploitable gap: if an attacker can get their hands on a copy of a message that was legitimately signed once, that copy remains perfectly, cryptographically valid no matter how many additional times it gets resent to entirely different recipients the original sender never intended to reach. The signature doesn't know or care that it's being replayed; it only knows the content matches what was signed.

This is what a DKIM replay attack exploits: not a weakness in the cryptography itself, which continues working exactly as designed, but a mismatch between what DKIM actually guarantees and what people sometimes assume it guarantees.

Why the Signature Doesn't Break on Replay

Walking through the mechanics makes the gap concrete. A DKIM signature is computed over a defined set of headers plus the canonicalized body hash, using the signer's private key. Verification recomputes the same hash over the received content and checks it against the signature using the corresponding public key. Nothing in that process references delivery count, recipient address, or send time in any way that would cause a second, third, or thousandth delivery of byte-for-byte identical content to fail verification — the content hasn't changed, so the hash matches, so the signature checks out, every single time, regardless of how many times "every single time" ends up being.

What Attackers Actually Get Out of It

Common Vectors: How Attackers Actually Get a Replayable Message

Why DMARC Doesn't Close This Gap Either

It's a reasonable instinct to assume DMARC, layered on top of DKIM specifically to add policy enforcement, would catch this. It doesn't, for the same underlying reason: DMARC's DKIM alignment check verifies that a passing signature's signing domain matches the visible From: domain, which remains true for a replayed message exactly as it was for the original. DMARC has no concept of delivery count or replay detection built into its evaluation model — it's checking alignment and policy disposition, not tracking whether this specific signed payload has been seen and delivered before. A replayed message that was DMARC-compliant the first time it was sent remains DMARC-compliant on the hundredth replay.

What Actually Helps, Since DKIM and DMARC Alone Don't

Meaningful mitigation lives outside the authentication protocols themselves. On the sending side: rate limiting and anomaly detection specifically around features capable of generating signed, replayable content on user demand, watching for unusual patterns like the same message content being triggered at unexpectedly high volume. On the receiving side: reputation and behavioral analysis that looks beyond simple pass/fail authentication results, since a technically valid signature paired with an anomalous delivery pattern (identical content suddenly arriving for thousands of unrelated recipients) is a detectable signal, just not one DKIM or DMARC themselves are designed to surface. Setting a reasonably short x= expiration tag on signatures where the use case tolerates it also meaningfully narrows the window during which a captured signature remains replayable, though it doesn't eliminate the risk within that window and needs to be balanced against realistic delivery and verification timing to avoid breaking legitimate late verification.

A Concrete Illustration of a Replay Scenario

Abstract descriptions of replay attacks are harder to reason about than a specific worked scenario, so consider a plausible one in detail. A widely-used SaaS platform sends a legitimately DKIM-signed "your document has been shared with you" notification email whenever a user shares a file with someone else's email address, signed under the platform's own well-established, high-reputation sending domain. An attacker discovers the sharing feature can be triggered by any authenticated user for any arbitrary recipient email address, without meaningful rate limiting. By repeatedly triggering the sharing notification with attacker-controlled document names and descriptions crafted to look like phishing bait, but sent to a large number of recipient addresses, the attacker generates a large volume of genuinely, validly DKIM-signed messages from the platform's trusted domain, each one individually indistinguishable from a legitimate sharing notification by any authentication-based check. This isn't technically a "replay" of one single captured message in the strictest sense, but it illustrates the same underlying category of abuse: exploiting a system's capacity to generate validly signed content on demand, at a volume and for a purpose the platform never intended, in a way that borrows the platform's reputation to bypass authentication-based filtering that would otherwise catch unsolicited bulk mail from an untrusted source.

Distinguishing True Byte-for-Byte Replay From Abuse of Signing Infrastructure

It's worth drawing a clear line between two related but distinct risk categories that both get loosely called "DKIM replay" in casual discussion. True replay is exactly what the term implies: capturing one specific, already-signed message and resending that identical copy elsewhere, unmodified. The scenario above is a related but distinct pattern — abuse of a system's capacity to generate new, validly signed messages on demand, at scale, for a purpose the system's operator never intended. Both exploit the same underlying gap (DKIM validity doesn't constrain delivery scope or volume), but they call for somewhat different mitigations: true replay is best addressed by limiting how long a captured signature remains usable (via the x= expiration tag) and by protecting the systems that might expose a signed message to capture in the first place, while abuse of on-demand signing infrastructure is best addressed by rate limiting and anomaly detection on the feature that generates the signed content, regardless of whether any specific message is ever literally "replayed" in the strict sense.

What Receiving Mail Systems Can Realistically Do About This

From the receiving side, since DKIM and DMARC themselves offer no built-in replay detection, mailbox providers and enterprise mail security systems that want to catch this pattern generally rely on techniques layered on top of, not inside, the authentication protocols themselves: tracking content similarity and delivery volume patterns across otherwise-unrelated recipient mailboxes, flagging cases where identical or near-identical signed content suddenly arrives at unusual volume or velocity, and factoring broader behavioral signals (recipient engagement, complaint rates, sudden shifts in a sending domain's typical traffic pattern) into filtering decisions rather than trusting a valid DKIM/DMARC pass as a sufficient signal on its own. This is precisely why "the message passed DKIM and DMARC" has never been treated by well-built mail security systems as equivalent to "this message is definitely legitimate and safe" — authentication passing establishes who genuinely sent (or at least signed) the content, not that the content or its delivery pattern is trustworthy or intended.

Why This Risk Category Is Sometimes Overlooked in DKIM Discussions

Most DKIM documentation and guidance, understandably, focuses on the mechanics of getting signing and verification working correctly — key generation, selector setup, canonicalization choices — and considerably less material addresses what DKIM deliberately doesn't cover. This isn't an oversight in how DKIM itself is documented; it's a reasonably accurate reflection of DKIM's actual, narrow scope as a protocol. But it does mean that organizations setting up DKIM primarily by following setup guides can come away with an inflated sense of what a passing DKIM check actually guarantees, simply because most of what they read focused on achieving a pass rather than on what a pass does and doesn't mean once achieved. Treating DKIM's guarantee as strictly "this content, as signed, is authentic and unaltered" rather than as any broader assurance about legitimacy or intended delivery is the correct mental model, and understanding replay risk is really just one specific, concrete illustration of that narrower scope in practice.

Where This Fits Alongside Other Email Authentication Limitations

DKIM replay isn't the only place where email authentication protocols have a narrower scope than casual understanding sometimes assumes. SPF verifies sending IP authorization for a specific envelope domain, not content integrity. DMARC layers a policy and alignment framework on top of SPF and DKIM, but inherits the scope limitations of whichever underlying check actually passed. None of these protocols, individually or combined, were designed to solve every possible category of email abuse — they solve specific, well-defined problems (sender authorization, content integrity, policy alignment) precisely and well, while leaving other problems, like replay, content-based social engineering, or compromised-but-legitimate-looking accounts, to other layers of defense entirely. Understanding DKIM replay specifically is useful less as an isolated curiosity and more as a concrete entry point into understanding this broader, important pattern: strong technical authentication and complete trustworthiness are related but genuinely distinct properties, and conflating them is where a lot of real-world security gaps quietly live.

A Brief Note on Responsible Disclosure

If you discover a specific on-demand signed-content feature in a product you use that appears exploitable for this kind of abuse, responsible disclosure directly to the platform's security team, rather than public discussion of the specific exploitable mechanism, is the appropriate path — the general pattern described in this guide is useful for understanding and defending against the risk category broadly, but publicly detailing a specific working exploit against a specific named platform serves attackers more than it serves anyone trying to build better defenses.

Replay Risk as a Consideration in Product Feature Design

For teams designing new product features that will trigger automated, DKIM-signed outbound email, building replay-abuse consideration into the design phase itself — rather than retrofitting rate limiting after abuse is discovered in production — tends to produce meaningfully more resilient outcomes. Concrete design questions worth asking upfront include: can this feature be triggered by an authenticated user for an arbitrary, attacker-chosen recipient address, is there any per-user or per-recipient rate limiting on the underlying send action, and would an unusual spike in this specific message type be visible to anyone monitoring the system in time to respond before significant reputation damage occurs. Answering these during design is considerably cheaper than answering them during an active abuse incident.

Related Reading in This Series

For the fundamentals of what DKIM does and doesn't guarantee, see What Is DKIM. For exactly what the body hash covers and how tampering is detected, read DKIM Body Hash Explained. For how DKIM fits alongside SPF and DMARC as a broader authentication strategy, see SPF vs DKIM vs DMARC. To inspect a domain's DKIM configuration directly, open DKIM Lookup.