Email authentication is entering its next chapter. In our latest CSA Live webinar, Sebastian Kluth (CSA) sat down with Kieran Cooper (Halon) and Bron Gondwana from Fastmail, one of the authors of the current DKIM2 draft specification, to talk about DKIM2, the proposed next evolution of DKIM that is currently being developed at the IETF. Participants registered from more than 40 countries, reflecting broad international interest in the topic.

The conversation covered why DKIM2 is needed, how it works under the hood, and what senders should realistically be doing about it today.

Why DKIM alone is no longer enough

DKIM has been foundational to email authentication for years, and DMARC would not work without it. But as Kieran Cooper pointed out, too much email still sits in a grey area: DKIM cannot verify the SMTP envelope, cannot confirm the intended recipient, and does not survive well when messages pass through mailing lists or get modified in transit. ARC addressed part of this problem by creating a chain of responsibility, but it still leaves receivers dependent on trusting what previous hops claim to have done. On top of that, the industry knows it eventually has to move away from RSA cryptography toward post-quantum algorithms, and today’s DKIM has no clean way to do that without risking a disruptive, all-or-nothing cutover.

How DKIM2 closes the gaps

A key shift with DKIM2 is that receivers can verify how a message changed in transit, rather than simply trusting what previous hops claim to have done. Bron Gondwana walked through how this works in practice: DKIM2 incorporates SMTP envelope information, including MAIL FROM and RCPT TO, into the signature, so a signed message can no longer be replayed to a different recipient. Every hop in a message’s journey can add a signature, similar in principle to how ARC chains work, but DKIM2 goes further: every change is documented in a “message instance” header, along with a “recipe” describing exactly what was altered and by whom. That means a message can, in theory, be reconstructed all the way back to its original form, even if the original sender only used DKIM1.

Bounces also become traceable and verifiable. Because they always travel back up the same chain rather than shortcutting to the original sender, Bron Gondwana explained that this is designed to prevent both DKIM replay and backscatter within the DKIM2 chain. And because a signature can carry more than one cryptographic algorithm at once, this could allow providers to phase in new cryptographic algorithms, including post-quantum cryptography, without breaking deliverability for anyone still validating the older algorithm.

What this means for senders right now

Both speakers were clear on one point: this is not a moment to panic. DKIM2 is designed to work with existing DKIM keys and DNS records, so there is no need for an immediate DNS update. If you are already signing with DKIM properly today and your alignment is in good shape, you are most of the way there. Kieran Cooper argued that senders should increasingly rely on DKIM rather than SPF for DMARC alignment, particularly as DKIM2 is built around cryptographic verification rather than IP-based trust.

Senders running mailing lists, filters, or anything that modifies messages in transit will need to think about how they generate the “recipe” for those changes. Cooper also expects greater use of CNAME-based key delegation by ESPs over time, which would make key rotation easier to manage on the sender’s side. And because DKIM2 is expected to increase the share of asynchronous bounces, anyone operating sending infrastructure should plan for handling them.

Where things stand

DKIM2 is still a draft at the IETF, currently at version 04, with interoperability testing already underway between multiple independent validator implementations. Kieran Cooper noted that with two large mailbox providers involved as co-authors of the draft, he expects adoption to follow relatively quickly once the specification is finalized. As Bron Gondwana put it during the Q&A, the real value of DKIM2 is that it removes the need to simply trust what other parties claim to have done to a message, and instead makes it possible to verify it directly.

What could DKIM2 mean for CSA certification?

During the Q&A, Sebastian Kluth also addressed whether DKIM2 could become part of the CSA certification criteria. He made clear that DKIM2 will not become a mandatory requirement in the near term. CSA may first include it as a recommendation and then assess how widely it is adopted across the market. Any later move toward a mandatory criterion would depend in particular on support and implementation on the receiver side.

Key takeaways

• DKIM2 is designed to close authentication gaps around forwarding, message modification, replay and bounce handling, by making changes along the delivery path verifiable rather than simply trusted.
• No immediate DKIM2-specific DNS changes are required: existing DKIM keys can initially be reused, and DKIM1 and DKIM2 signatures are expected to coexist during the transition.
• The specification is still an IETF draft, but experimental implementations and interoperability testing are already underway, making this a good time for technically involved senders and ESPs to follow the discussion.

Watch the full session

The full recording, including the detailed technical walkthrough and audience Q&A, is available on our YouTube channel.