There is a new IETF draft making the rounds that deserves more attention from the deliverability community than it's currently getting. It's called DKIM2, and if the name sounds like a simple version bump, the scope of what it tries to solve is anything but simple.
The draft (draft-clayton-dkim2-spec, currently at version 08) is authored by Richard Clayton from Yahoo, Wei Chuang from Google, and Bron Gondwana from Fastmail. When Yahoo, Google, and Fastmail collaborate on replacing a foundational email authentication standard, that's worth paying attention to.
I want to be upfront: I am not a protocol designer. I have not implemented DKIM at the RFC level. What I am is someone who has spent 27 years working with email infrastructure, troubleshooting deliverability issues, and staring at SMTP logs trying to figure out why authenticated mail ends up in spam. This article is written from that perspective. Not "here's how the spec works" but "here's why it matters for people like us."
The problems we live with every day
If you work in email deliverability, you already know these pain points. You just might not have connected them to DKIM's limitations.
Forwarding breaks everything. A subscriber sets up mail forwarding from their work address to their personal Gmail. Your message was properly DKIM-signed when it left your infrastructure. The forwarding server passes it along, maybe adds a header, maybe modifies the envelope. By the time Gmail receives it, your DKIM signature is invalid. Gmail sees an unsigned (or broken-signed) message claiming to be from your domain. What happens next depends on DMARC policy, SPF alignment, and Gmail's mood that day. For the practitioner troubleshooting this, the experience is maddening. You did everything right. The authentication broke in transit. And you have zero visibility into what happened between your outbound MTA and the final destination.
Mailing lists are a nightmare. This one has been a thorn in the industry's side for over a decade. A mailing list receives your message, adds a subject prefix, appends a footer, maybe rewrites the From header for DMARC alignment. Every one of those modifications invalidates your DKIM signature. ARC (Authenticated Received Chain, RFC 8617) was supposed to fix this by letting intermediaries vouch for the original authentication. In practice, ARC adoption has been limited, and the IETF working group that developed it has already concluded. From what I understand, the DKIM2 authors explicitly reference this: the lessons learned from ARC directly informed their approach.
The black box between send and inbox. This is the one that frustrates me most as a practitioner. When a message leaves my infrastructure, it's properly authenticated. When it arrives at the destination, sometimes it's not. What happened in between? With DKIM1, I have no idea. There is no chain of custody. There is no record of which systems touched the message, what they changed, or why my signature broke. I'm left guessing, checking headers manually, and hoping I can reconstruct the path.
What DKIM2 proposes to change
From what I've read in the current draft, DKIM2 introduces several concepts that directly address these problems. I'll describe them at a high level — the spec itself runs to 37 pages for anyone who wants the technical details.
Chain of custody. This is the big one. Instead of a single DKIM signature that either validates or doesn't, DKIM2 requires every system that handles the message to add its own signature. The originating MTA signs it. The forwarding server signs it. The mailing list signs it. Each hop in the chain adds a DKIM2-Signature header. The receiving server can then walk the entire chain backwards and verify every link. This means that when a message arrives with a broken original signature, the receiver doesn't just see "invalid DKIM." It can see exactly which system in the chain modified the message, and it can evaluate the reputation of that system.
Recipes for modifications. This is the part I find most clever. When an intermediary modifies a message (adding a footer, changing a header), it doesn't just re-sign and hope for the best. It includes a "recipe" in its signature that documents exactly what it changed. The recipe contains instructions to reverse the modifications, so the verifier can reconstruct the original message and validate the original signature. Think of it as a diff for email authentication. Instead of "something changed and now your signature is broken," it becomes "here is precisely what changed, and here is how to undo it to verify the original."
Replay protection. This one I know primarily from reading about it rather than from personal experience. DKIM replay attacks happen when someone takes a legitimately signed message and sends it to millions of recipients who were never intended to receive it. The original signature still validates because the message content hasn't changed. From what the draft describes, DKIM2's chain of custody addresses this because a verifier can check whether the message was actually routed through legitimate intermediaries to reach the intended recipient, rather than being replayed by a bad actor.
Bounce authentication. Another problem I've seen the effects of without always connecting it to DKIM: backscatter. Forged bounce notifications sent to domains that never sent the original message. DKIM2 includes provisions to ensure that Delivery Status Notifications can only be sent to entities that were actually involved in transmitting the message. The chain of custody makes this verifiable.
What stays the same
It's worth noting what doesn't change. From what I can tell, DKIM2 uses the same DNS infrastructure for key storage. Keys live in the same _domainkey subdomain. The supported algorithms (RSA-SHA256 and Ed25519-SHA256) are familiar. Selectors work the same way. This matters because it means DKIM2 doesn't require rebuilding DNS infrastructure from scratch. The migration path, at least for key management, looks manageable.
Why the timing matters
Richard Clayton is presenting on DKIM2 at the Deliverability Summit in Barcelona next month (April 20–22). The spec is at version 08, published March 2, 2026. The structural overhaul happened in version 07, submitted in February: recipes, SMTP parameters, and cryptographic data were moved into JSON objects that are base64-encoded into the header fields. Version 08 followed with editorial cleanup and section reorganization — no changes that affect implementors. The IETF DKIM mailing list is actively discussing the draft. This is not a theoretical exercise sitting in a drawer. It's being actively developed by people at the organizations that process the majority of the world's email.
That said, it's important to be clear about what this is and what it isn't. The draft is an individual submission. It is not yet an endorsed IETF standard. It has no formal RFC status. The spec could change substantially before (or if) it reaches that stage. But the direction is clear, and the problems it addresses are real problems that every deliverability practitioner deals with.
What practitioners should do now
Nothing drastic. But stay informed.
Read the draft if you're technically inclined — it's at datatracker.ietf.org/doc/draft-clayton-dkim2-spec/. Follow the IETF DKIM mailing list discussions. If you're at the Deliverability Summit, attend Clayton's session.
For platform builders and ESP developers, this is worth tracking closely. If DKIM2 reaches adoption, it will require changes to how MTAs handle signatures, how forwarding works, and how verification is performed. That's not a small lift, and early awareness gives you time to plan.
For deliverability practitioners like me, the main takeaway is this: the problems we've been working around for years — forwarding breakage, mailing list authentication failures, the opacity of the message path — these are being addressed at the protocol level by the people who run the largest mailbox providers on the planet. That's encouraging. It's also a reminder that email authentication is not a solved problem. It's an evolving one.
I'll be following this closely and will share updates as the spec progresses. If you're working in this space and want to discuss what DKIM2 might mean for your infrastructure, I'd love to hear from you.
Bram is the founder of Engagor, an Agentic Email Intelligence Platform, and has 27 years of experience in email infrastructure and deliverability consulting. Engagor gives you complete visibility into your email authentication health across every MTA and ESP in your stack.
