Separate a valid signature from an intended delivery
Replay is possible when signed material is reused in a delivery context the original signer did not intend. The signature may remain mathematically valid because the covered bytes have not changed. That does not mean the signer authorized unlimited redistribution, and it does not make every repeated message an attack. A useful analysis asks which context is authenticated, which party performed the onward delivery and what a receiver can actually observe.
RFC 6376 section 8.6 discusses replay and spam as limitations requiring operational judgment. The DKIM2 work proposes additional route and recipient context rather than treating a stronger signature algorithm as the whole answer. This article uses core draft -09, dated 1 November 2026. It is work in progress, not a published anti-replay guarantee.
Compare two fictional delivery contexts
In a classic-DKIM teaching case, a service signs a message sent to a single intended mailbox. A third party obtains the message and sends unchanged signed content to other recipients. Assuming the signed material and verification conditions remain intact, the signature can still verify. The problem is reuse of that signed artifact, not necessarily alteration of its body or compromise of the signing key.
For the DKIM2 comparison, suppose the original latest signature describes delivery to one fictional address at birch.example. Reusing that same signed envelope information while delivering to a different address should fail the draft's latest-hop recipient comparison. Section 14.4 requires every actual RCPT TO address to appear in the signed rt value, although rt can contain additional recipients. Domains compare case-insensitively; local parts require exact matching under the specified rules.
This is a stipulated comparison, not a transcript from a mail server. It isolates the additional context the proposal checks. It does not claim that simply publishing a DKIM2 key makes an existing receiver perform those comparisons, or that a legacy receiver rejects the reused message.
Follow responsibility when an intermediary adds a hop
A replaying system might instead add a new valid hop. The proposed chain then records a signing identity associated with onward handling, subject to all chain checks. That is useful attribution, but it does not automatically label the action malicious. A legitimate forwarder also adds delivery responsibility. The receiver still needs to evaluate route expectations and the reputation or role of the intermediary.
Section 15.1 describes using repeated observations of the original Message-Instance m=1 header and body hashes, together with intermediary presence and the exploded flag. It does not define a universal global database or a fixed volume threshold that every implementation must use. A receiver with only one observed message cannot establish repeated delivery by counting unseen copies.
The exploded flag reports that a system is sending to multiple addresses. It helps identify where fan-out is claimed; it is not a certificate that the fan-out was welcome. Preserve which signature carries it and whether that behavior was expected for the route. A dashboard that reduces the flag to “replay safe” would discard the decision context the draft intends to expose.
Keep legitimate duplication in the comparison
A large receiving service can encounter identical messages from ordinary bulk distribution. Several recipients may also forward copies that reconverge at the same service. Protocol retries can occasionally produce duplicates. The draft expressly discusses these distinctions. Counting equal hashes is therefore an input to assessment, not a standalone verdict that any second copy must be blocked.
An original lab plan should contain at least four cases: direct intended distribution, onward redistribution with an undeclared recipient change, a properly declared intermediary fan-out, and legitimate reconvergence. Keep the message content fixed where possible so the explanation isolates route context. Then vary the receiver's visibility: one copy, several copies and incomplete historical observations. Those are proposed cases, not experiments completed for this article.
Preserve the original clock context
Section 14.3 rejects full-verification eligibility when any signature is more than fourteen days older than SMTP acceptance or more than one day in the future relative to acceptance. The draft requires accurate knowledge of that acceptance time. Rechecking an archived message against today's clock can answer a different question from checking what was valid when it arrived.
A retrospective investigation therefore needs the original arrival metadata, not just a saved message file. Retain the observed time source, timestamp values, relevant DNS/key context and verifier version. A later missing key or changed record also does not establish what the original verifier saw. Separate “cannot reproduce historical verification” from “the original signature was invalid” unless the evidence supports the stronger conclusion.
Avoid speculative replay controls
The draft's optional nonce is available for a creator's uses, such as correlating later delivery-status information. It is not, by itself, a standardized one-time-use enforcement service. Similarly, earlier auth= sender-policy discussion concerns a separate proposal and mixed-deployment questions. It must not be presented as settled core -09 syntax or as proof that every forwarder advertises compatible behavior.
Treat an implementation's replay claim as a bounded question: which inputs are retained, for how long, across which receiving nodes, with which false-positive controls? Ask for evidence of repeated observations and route analysis, not just a successful cryptographic check. Privacy and storage implications belong in that review because detection context can accumulate delivery metadata across messages.
State what this comparison does and does not establish
The exact commission is: Compare a classic DKIM replay scenario with the draft's specific proposed detection model. The fictional comparison above explains envelope binding, intermediary attribution, repeated original-instance observations, timing and visibility limits. It is documentary analysis, not a measured detection rate, a reproduced attack or a receiver interoperability result.
Actual cases, versioned implementations, retained verifier outputs and specialist acceptance remain open. A security owner must approve any future controlled experiment, with no unsolicited traffic or production-policy changes. Site, visual and publication gates also remain outstanding. The defensible conclusion is that the proposal adds context for detecting and attributing reuse, while actual effectiveness depends on implementation, observations and receiver judgment.