The IETF DKIM Working Group released a new version of the DKIM2 specification on May 17, 2026. This is the third revision of the working group document, continuing steady progress toward an eventual RFC. For anyone who has been following DKIM2 since the early drafts, this is the clearest sign yet that the working group is close to something ready for real use.
Need a refresher before reading on? View our detailed explainer on What is DKIM2 for the background.
What Changed in This Update
The new version is called draft-ietf-dkim-dkim2-spec-02. It was written by Richard Clayton (Yahoo), Wei Chuang (Google), and Bron Gondwana (Fastmail), the same team that has worked on the document from the start. The first official IETF working group draft was draft-ietf-dkim-dkim2-spec-00, published on March 24, 2026, which replaced the earlier individual draft (draft-clayton-dkim2-spec). Since then, the document has moved through revisions -01 in April and -02 in May, with the specification being shaped by the wider working group rather than by its original authors alone.
The May 17 revision is an incremental update that continues to refine the technical details of the specification. The most notable changes are:
- Authentication-Results headers excluded from signing: These headers often change as mail crosses system boundaries, so leaving them out of the signature avoids unnecessary verification failures.
- Clearer rules for donotmodify and donotexplode flags: Senders can state more firmly that a message should not be altered or sent to multiple recipients, and verifiers now have explicit checks and error messages when those requests are ignored.
- Removed the z body recipe: Originally included for truncated bounce messages, it turned out not to be needed in practice. Cutting it simplifies the spec without losing functionality.
- Tighter technical rules: Clarifications around base64 padding, semicolon separators in header fields, and JSON formatting reduce ambiguity and make compatible implementations easier to build.
Readers tracking the spec closely can compare versions directly through the IETF Datatracker.
The Two Problems DKIM2 Solves
Two long-standing problems with DKIM1 led to this rewrite.
The first is the DKIM replay attack. Here, an attacker takes a legitimate signed message and sends it again to other mailboxes, abusing the original domain’s good reputation. DKIM2 fixes this by recording recipient details inside the signed content and building a chain of custody across every step the message takes. Replayed messages no longer look real to a verifier.
The second is broken signatures during forwarding. Mailing lists and forwarders often change headers or body content in ways that break the original DKIM signature. This is why messages sent through tools like Mailman often fail DMARC checks for the sender’s domain. DKIM2 handles this natively. Each system that touches the message records its changes and adds its own signature to the chain. Verifiers can then trace the message back to the original sender without the chain breaking.
For background on the forwarding problem, see our article on DMARC and Mailing Lists.
ARC is Being Retired
The forwarding fix also explains a related update worth knowing about. On April 22, 2026, Trent Adams (Proofpoint) and John Levine (Taughannock Networks) submitted draft-ietf-dmarc-arc-to-historic-00 to the IETF DMARC Working Group. This proposes that Authenticated Received Chain (ARC) be reclassified as a historic standard.
The draft’s stated reason for concluding the ARC experiment is that the operational experience gained from ARC is being incorporated into the proposed DKIM2 work as the successor to DKIM. In other words, the lessons from ARC are not being thrown away. They are being folded into a cleaner solution.
If you want to learn in detail about ARC and what it does, you can go through our guide on What is ARC.
What Domain Owners Need To Do Right Now
For most senders, the answer is: nothing urgent.
DKIM2 keys use the same DNS record structure as today’s DKIM keys, so your existing DNS setup carries over. The specification assumes a long period where DKIM1 and DKIM2 will run side by side, so there is no forced switch. First deployments at major mailbox providers are expected in late 2026, with wider rollout continuing into 2027 and beyond.
What matters now is making sure your current DKIM setup is in good shape. That means properly published keys, sensible rotation, and no leftover selectors. Any problems you carry today will follow you into the DKIM2 era. If you need to review the basics, start with learning What is DKIM.
If you would rather not manage signing keys yourself when the change begins, PowerDMARC’s hosted DKIM takes care of publication, rotation, and monitoring, so you are ready as DKIM2 rolls out.
- DKIM2 Specification Update: What’s New in the May 2026 IETF Draft - May 25, 2026
- Is Windows Defender Enough for Small Business Security? - May 14, 2026
- DMARCbis Explained – What’s Changing and How to Prepare - April 16, 2026
