DKIM replay is one of those topics that sounds exotic until you realize the core idea is simple.
An attacker does not forge a new DKIM signature.
They take a message that was already signed legitimately, keep the signed parts intact, and send that same message again to many more recipients than the original sender intended.
That matters because DKIM validates message integrity and signer responsibility for the signed content. It does not prove that a message is fresh, unique, or being delivered only to the audience the sender originally intended.
RFC 6376 explicitly calls out replay or spam attacks as a DKIM risk. The model is straightforward: a spammer gets access to a real DKIM-signed message and reuses it at scale so the message still carries a valid signature from a reputable domain.
The key point is this:
d= domain can still be aligned with the visible From domainSo replay is not mainly a cryptographic failure. It is a context failure.
DMARC does not ask whether a message was intended for the current recipient.
It asks whether at least one supported authentication method produced a pass result on an aligned identifier. RFC 7489 is explicit on that.
If a replayed message keeps a valid aligned DKIM signature, DMARC can still evaluate it as a pass.
That is the same general principle behind multiple DKIM signatures explained: DMARC is about aligned authenticated identifiers, not about the full business legitimacy of the message.
A DKIM pass means the signed content still matches the signer domain. It does not mean the message is fresh, expected, or being sent to the right audience.
A simple example:
example.com sends a legitimate DKIM-signed announcement.d= value aligns with From:, DMARC can still pass.This is why replay often gets misunderstood.
Admins expect authentication to answer "is this message authorized?" But DKIM only answers a narrower question: "did this signer domain sign these bytes, and are the signed bytes still intact?"
Replay is real, but it is not equally important for every sender.
It matters most when all of these conditions line up:
That makes replay more relevant for some message classes than others.
RFC 6376 section 8.6 specifically notes the attacker is trying to benefit from the signing domain's reputation rather than their own.
This is why a bank alert containing tightly scoped account-specific details is a different replay story than a generic newsletter blast.
Replay is often mixed up with several other problems.
It is not:
If the private key was stolen, that is a different class of incident entirely. An attacker with the real signing key can generate new signed mail, not just resend old signed mail.
If a mailing list or forwarder redistributes a message and the content changes, that is more in the territory covered by DKIM canonicalization and common breakage and DMARC, forwarding, mailing lists, SPF, DKIM, and ARC.
This is the design boundary that matters most.
DKIM was built to let a domain sign selected headers and body content so verifiers can confirm that signed content has not changed. RFC 6376 also says DKIM's signature verifies the hashed content and "asserts nothing else" about protecting end-to-end message integrity.
That means DKIM does not natively answer:
So replay is not some weird exception to DKIM. It is a direct consequence of what DKIM was and was not designed to prove.
Usually, replay is not the first thing most domain owners should optimize.
For most teams, bigger risks still come from:
If those basics are not solid yet, fix them first.
Replay becomes more worth focused attention when:
There is no single "set this DNS record" fix for DKIM replay.
The practical goal is to make captured signed mail less reusable and easier to detect when it is abused.
If replayed mail only makes sense for the original recipient, the attacker gets less value from mass reuse.
That does not mean adding random noise. It means signing content that meaningfully ties the message to the intended context, where appropriate.
The shorter the message remains valuable, the smaller the replay window.
This is mostly an application and campaign design issue, not a DKIM knob.
RFC 6376 notes that large verifiers may detect unusually large volumes of mail with the same signature over a short period. Even if you are not a mailbox provider, the operational lesson is still useful: look for abnormal duplication patterns, complaint spikes, and stream-level anomalies.
The RFC treats reputation systems as a partial mitigation, because they can react when authenticated mail starts behaving like spam. In practice that means complaint monitoring, provider dashboards, and abuse desk signals matter even after SPF, DKIM, and DMARC are working.
If a message is both widely reusable and highly trusted, it is a better replay candidate.
That does not mean "stop signing newsletters." It means generic high-value content deserves stronger monitoring and stream discipline.
Not cleanly, and not always quickly enough.
RFC 6376 section 8.7 says domains may want to revoke a key when undesirable behavior is detected, including replay abuse. But the RFC also explains the limits:
So key rotation is still good hygiene, but it is not a magic replay kill switch. That fits with the broader guidance in DKIM selectors and key rotation playbook and How Often Should You Rotate DKIM Keys?.
Think of DKIM like a genuine stamp on a document.
The stamp can prove the document was issued by the expected authority and was not altered after stamping.
But if someone photocopies that stamped document and hands it to the wrong crowd, the stamp by itself does not explain whether that redistribution was intended.
That is the operational shape of DKIM replay.
DKIM replay is the reuse of a legitimately signed message, not the forging of a new one.
It matters most for reusable, reputation-bearing mail that can be resent broadly without changing signed content. Because aligned DKIM can still verify, DMARC can still pass on replayed mail.
So the right response is not to expect DKIM to prove freshness. The right response is to treat replay as an abuse-handling problem: reduce how reusable sensitive messages are, monitor for anomalous authenticated traffic, and remember what DKIM is actually designed to guarantee.