DKIM2 draft 06 adds replay detection guidance for verifiers
News
Published 29 Aug 2026
Updated 29 Aug 2026
8 min read
Summarize with
DKIM2 draft 06 proposes that verifiers reject all copies when the same message arrives more than once without an indication that a legitimate expansion occurred. The new section 11.9 also says the hashes in the first Message-Instance field, identified by m=1, can help recognize duplicates. This is proposed replay detection behavior in a non-final Internet-Draft, not a rule for production mail today.
The IETF DKIM working group published draft 06 on 28 August 2026 at 18:55:38 UTC. It follows draft 05, which added SHA-512 and tighter validation rules. Draft 06 has no IESG approval, rollout, deadline, or current sender requirement. Its verifier language can change in another revision or disappear before any standards action.
Draft status matters
Do not deploy duplicate rejection as a current requirement and do not change DKIM1 or DMARC policy because of draft 06. Internet-Drafts are working documents, and this one remains under discussion.
What changed from draft 05
The main addition is section 11.9, "Check for unexpected replay." It gives verifiers a proposed response to multiple copies of a message when the DKIM2 chain contains no exploded indication. In DKIM2 terminology, an exploded message has been intentionally expanded for multiple deliveries, such as mail distributed by a mailing list. Without that signal, identical copies look suspicious.
Draft 05
- Replay check: No dedicated verifier section for unexpected duplicate copies.
- Mixed hashes: No explicit result for one passing hash and one failing hash.
- Mixed signatures: Used the nonexistent PERMFAIL term in this path.
- PASS meaning: Did not state the trust boundary as clearly.
Draft 06
- Replay check: All unexplained duplicate copies SHOULD be rejected.
- Mixed hashes: One pass plus one mismatch SHOULD be failure.
- Mixed signatures: Every supported signature is checked, with selector-specific errors.
- PASS meaning: Confirms transit and replay consistency only.
The remaining changes support that verifier model. Draft 06 corrects PERMFAIL to FAIL, adds selector details when signature outcomes differ, and states how mixed hash results should be handled. It also corrects the Delivery Status Notification citation to RFC 6522. That DSN reference fix is editorial and does not drive the replay proposal.
How the proposed replay check works
A verifier would compare incoming evidence with messages it has already observed. When multiple copies resolve to the same original Message-Instance and the chain provides no exploded indication, section 11.9 says all copies SHOULD be rejected. The proposed human-readable result is FAIL for a duplicate message without the exploded flag.
Proposed draft 06 path for identifying and rejecting unexplained duplicate messages.
The m=1 Message-Instance hashes are optional evidence for matching copies. The draft uses MAY, so it does not mandate a single storage design, retention window, or comparison database. An implementation still needs rules for scope, expiry, privacy, and synchronization across receiving systems. Those operational details will decide whether the proposal catches replay without suppressing legitimate delivery.
Legitimate duplicates remain possible
RFC 1047 documents SMTP protocol conditions that can produce duplicate messages. Draft 06 describes those duplicates as rare on today's Internet and therefore treats an unexpected duplicate as likely replay. It also admits that rejecting the first copy is often impossible and that a duplicate arriving much later can be impractical to reject.
That caveat is important. A receiver cannot know that the first accepted copy will later gain a twin. A short cache misses late replay, while a long cache increases storage and collision-management costs. Distributed mailbox infrastructure also needs consistent evidence across regions. The draft identifies desired behavior, but it does not yet settle these engineering choices.
Verifier results are stricter and clearer
Draft 06 closes ambiguity around multiple algorithms and selectors. A verifier is expected to check every signature it supports. If all signatures it can check fail, the result is FAIL. If one passes and another fails, the proposed error should identify the selector for each outcome. That detail matters during algorithm transitions because it separates an unsupported signature from a supported signature that was actually incorrect.
|
|
|
|---|---|---|
All checks pass | PASS | Transit consistent |
One hash fails | FAIL | Name algorithm |
All signatures fail | FAIL | Name selector |
Signatures differ | Report error | List selectors |
Unexplained duplicate | FAIL | Replay suspected |
Proposed verifier outcomes in draft 06
Hash handling gets the same conservative treatment. When one supplied hash value matches and another does not, the verifier SHOULD treat the result as failure. A passing SHA-256 calculation cannot cancel a failing SHA-512 calculation. The diagnostic should name the algorithm whose value did not match.
PASS has a deliberately narrow meaning. It says the message traveled without modification or replay that conflicts with the draft's model. It does not say the message is valuable, safe, wanted, or honest. It also does not say recorded modifications were benign. Reputation, content inspection, abuse controls, and local acceptance policy remain separate decisions.
Why the draft matters to mail operators
Replay detection requires state. That makes section 11.9 more than a parser change. Implementers need a duplicate identity, a retention period, a lookup path, and evidence that explains why a message was accepted or rejected. Mailbox providers need to test whether retry behavior, clustered inbound systems, and delayed queues create false duplicate signals.
- DKIM2 implementers: Preserve complete signature chains, Message-Instance fields, hash outcomes, selector outcomes, and duplicate decisions.
- Mailbox providers: Model replay state across receiving hosts and test how long duplicate evidence remains useful.
- Forwarders: Verify that normal forwarding does not create unexplained copies or lose chain evidence.
- Mailing lists: Test expansion signals for every recipient path, especially after list transformations.
- Security operators: Measure false positives before attaching rejection policy to a duplicate match.
Forwarders and mailing lists deserve special attention because legitimate fan-out can resemble replay when metadata is missing, altered, or processed inconsistently. Testing should cover one message delivered to several recipients, retries after ambiguous SMTP completion, queue recovery, delayed forwarding, and list redistribution after content changes.
What operators should do now
Draft 06 is useful input for prototypes and test plans. It is not a production mandate. The safest response is to collect evidence and learn where duplicate detection fails before any rejection behavior reaches live mail.
- Track revisions: Watch the working-group draft and compare normative language in each new version.
- Prototype separately: Keep draft-only replay experiments outside the production acceptance path.
- Test legitimate copies: Include SMTP retries, forwarding loops, queue restores, mailing-list fan-out, and delayed duplicates.
- Retain evidence: Store the full DKIM2 chain, m=1 hashes, timestamps, selectors, and exploded indications.
- Protect current policy: Do not alter DKIM1 signing, ARC processing, or DMARC enforcement because of this draft.
Current production checks still matter. Use the DKIM checker to validate today's DKIM1 DNS record and selector. Suped's DMARC monitoring can keep production authentication evidence, source activity, and failure trends visible while DKIM2 work remains separate. That workflow does not implement draft 06 or make its replay proposal a sender obligation.
What draft 06 does not change
DKIM1 remains the deployed signing standard. Its verification result authenticates a signing-domain claim over selected message content, subject to current specifications and receiver policy. Draft 06 does not amend deployed DKIM1 behavior and does not require DKIM1 verifiers to keep a global duplicate-message database.
No current compliance event
There is no approved DKIM2 standard, mandatory rollout, implementation deadline, sender setup task, or mailbox-provider enforcement date attached to draft 06. Treat claims of immediate compliance as incorrect.
ARC remains a separate mechanism for recording authentication results and message handling across intermediaries. DMARC remains a separate policy layer based on current SPF or DKIM authentication plus domain identifier matching. Neither ARC nor DMARC gains a replay-rejection requirement through this Internet-Draft.
The distinction matters because draft experiments can run beside production authentication without changing production outcomes. Operators can log proposed DKIM2 decisions, compare them with actual delivery paths, and report edge cases to the working group while continuing to apply established DKIM1, ARC, and DMARC requirements.
The practical reading of draft 06
Draft 06 makes replay detection explicit in the DKIM2 verifier model. Its proposal is clear: unexplained copies of the same message are presumptive replay, all supported signatures should be checked, inconsistent hashes should fail, and PASS should never be mistaken for a safety verdict.
The unresolved work is operational. Receivers need enough state to recognize duplicates without turning valid retries, forwarding, or list distribution into false rejections. Until the working group resolves those details and the document advances, draft 06 belongs in test environments and design reviews, not current sender policy.
