April 2026 DKIM2 RFC Draft: What Changed

Email authentication standards move slowly - then sometimes all at once. The DKIM2 specification has been in draft for years, but the April 2026 revision is substantive enough that email administrators should understand what's in it and what it means for their environments.

This post breaks down the major changes in plain terms, explains what each one fixes, and gives you a realistic view of the timeline.

What Is DKIM2 and Why Does the Standard Need an Update?

DKIM - DomainKeys Identified Mail - has been in production since the early 2000s. It lets senders sign email headers with a private key, and receivers check the signature against a public key published in DNS. The goal is to prove the email wasn't modified in transit and that the sending domain genuinely authorized it.

DKIM1 works well in simple scenarios. It breaks down, however, when email passes through forwarding chains, mailing lists, or other intermediaries that modify headers or body. Each modification invalidates the original signature. DKIM1 has no mechanism to handle that gracefully.

DKIM2 is the working group's attempt to fix those gaps without breaking the core signing model. The April 2026 draft is mature enough to review, even if deployment is still years away.

What's New in the April 2026 Draft

The draft introduces several distinct mechanisms. Each addresses a specific failure mode that DKIM1 cannot handle.

Chain of Custody: Ordered Signatures Across Forwarders

The most significant change in DKIM2 is the chain-of-custody model. In DKIM1, a message has exactly one signature - the original sender's. Any forwarder that modifies the message, even innocently, breaks that signature.

DKIM2 introduces an ordered sequence of signatures. Each intermediate handler - forwarder, mailing list, rewriting agent - adds its own signature with an index number (i=1, i=2, ...). The receiver can trace the full path of the message and verify each link in the chain independently.

This is the direct replacement for what ARC tried to do. ARC was designed to solve the same problem - preserving authentication results through forwarding chains - but its implementation was fragile and inconsistent. DKIM2's chain-of-custody is built into the signing protocol from the start, not as a bolted-on layer.

Message-Instance Headers and Recipes

DKIM2 introduces a Message-Instance header containing a base64-encoded JSON structure - the working group calls it a "recipe." The recipe tells the verifier how to reconstruct the state of the message at the time each signature was added.

If a footer gets appended by a mailing list, the recipe describes that modification. When the verifier checks the downstream signature, it can reconstruct the message as it existed at that point, rather than comparing against the original unmodified message.

This solves the core DKIM1 problem where legitimate modifications invalidate signatures even when both parties are authorized.

Replay Defense: Binding Signatures to the SMTP Envelope

DKIM2 adds two new tags - mf= (mail from) and rt= (recipient) - that bind each signature to the SMTP envelope at the time of signing. If an attacker captures a legitimately signed message and forwards it to different recipients, the signature will fail because the envelope information doesn't match.

The draft also defines flags that make signer intent explicit: donotexplode, donotmodify, exploded, feedback. A mailing list that adds footers can flag its messages as modified in an expected way. A forwarder can indicate its intent. The protocol, rather than guesswork, decides what is legitimate.

This is the replay attack defense. DKIM1 signatures are reusable across recipients if you know the private key. DKIM2 signatures are not.

DSN Handling: Bounces Following the Chain

When a message fails DKIM2 verification somewhere downstream, the bounce needs to travel back through the same chain of handlers that handled the original message. The draft specifies how DSN (Delivery Status Notification) bounces should follow the signature chain.

This reduces backscatter - bounce messages sent to the wrong address because the original envelope information was lost or rewritten at some point in the chain.

Cryptographic Requirements: Ed25519 and SHA-256

The crypto requirements in DKIM2 are straightforward: SHA-256 is required (no SHA-1 for new signatures), and Ed25519-SHA256 is added as a permitted signing algorithm alongside RSA-SHA256.

Ed25519 keys are smaller than RSA keys at equivalent security levels, which matters for DNS record size. A 256-bit Ed25519 key offers roughly comparable security to a 3072-bit RSA key. For organizations hitting DNS record size limits with large RSA keys, Ed25519 is a practical improvement.

The spec does not include a version tag. DKIM2 identifies itself through the signature mechanism, not a v= tag.

What DKIM2 Doesn't Change

It's worth being clear about scope. DKIM2 is not a complete email security overhaul. It doesn't address SPF, DMARC alignment, or sender policy. It doesn't introduce new ways to discover authorized sending sources.

DKIM2 also isn't a replacement for DMARC or a reason to deprioritize DMARC adoption. The standards address different parts of the authentication pipeline.

ARC, which DKIM2 effectively supersedes, is being retired. The ARC working group has been closed. If you're currently relying on ARC for forwarding authentication, the retirement notice is real and you should plan accordingly.

The Timeline: When Does DKIM2 Become Real?

The honest answer is: not soon.

The working group has published a draft that reflects substantial consensus, but standards track progression takes time. Early estimates from people watching this closely suggest 2027 at the earliest for a final spec, with adoption following over subsequent years.

Email authentication infrastructure has long rollback cycles. Receiving systems need to understand the new signature format before senders can rely on it. The transition will be gradual.

Do not expect organizations to flip a switch. Plan for coexistence between DKIM1 and DKIM2 for years.

What Email Admins Should Do Now

DKIM2 is not an emergency. You don't need to change anything today.

What you should do:

Track the draft. If you manage email authentication for a large organization, subscribe to the IETF DKIM working group updates. The spec is still draft, and implementation details may change.

Maintain DKIM key rotation discipline. DKIM2 will require proper key management just like DKIM1. If your organization hasn't been rigorous about key rotation schedules, now is a good time to build that habit. DKIM2's replay defense especially punishes stale keys.

Monitor aggregate reports for authentication failures. As DKIM2 approaches finalization, you'll want clean baseline data on your DKIM pass/fail rates. DMARC aggregate reports give you that visibility. If your reporting is weak, the transition period is the time to fix it.

Review your mailing list and forwarding configurations. DKIM2's chain-of-custody and Message-Instance mechanisms mean intermediaries will need to participate in signing. If you run mailing lists or forwarders, understand what DKIM2 will require of you.

Don't rush to implement DKIM2 until receivers do. You can generate DKIM2-style signatures today if you want to experiment, but if receiving mail servers don't understand them yet, they're just noise. Watch the major mailbox providers - Google, Microsoft, Fastmail - for signals that they're ready to parse DKIM2 signatures.

The Bottom Line

DKIM2 is a meaningful upgrade to email authentication. The chain-of-custody model fixes the core fragility that has made DKIM1 unreliable through forwarding chains. The replay defense closes a real attack class that DKIM1 cannot address. Ed25519 support gives you better crypto with less DNS overhead.

But it's still a draft. Deployment is years away. The right move now is to understand what changed, maintain your current DKIM hygiene, and pay attention to when the major receivers start signaling readiness.

You don't need to act today. You do need to be watching.

FAQ

What is the difference between DKIM1 and DKIM2?

DKIM1 uses a single signature that breaks when any intermediary modifies the message. DKIM2 uses an ordered chain of signatures where each handler in the path adds its own signature, and Message-Instance headers let verifiers reconstruct the message state at each step.

Does DKIM2 replace ARC?

Yes, effectively. The ARC working group has been retired. DKIM2's chain-of-custody mechanism addresses the same problem ARC was designed for - preserving authentication results through forwarding chains - but as a native part of the DKIM protocol rather than a separate layer.

When will DKIM2 be finalized?

The earliest realistic timeline is 2027 for a stable spec, with broader adoption in 2028 and beyond. Email authentication infrastructure transitions slowly.

Should I implement DKIM2 now?

Not yet. Major receiving mail servers don't yet parse DKIM2 signatures in production. Implement it experimentally if you want, but don't rely on it for production email delivery until you see adoption signals from major mailbox providers.

What is Ed25519 in DKIM2?

Ed25519 is a digital signature algorithm. In DKIM2, it can be used instead of RSA-SHA256. Ed25519 offers equivalent security to RSA with much smaller key sizes - a 256-bit Ed25519 key is roughly comparable to a 3072-bit RSA key. This matters for DNS TXT record size limits.

What is the replay defense in DKIM2?

Replay defense binds each DKIM2 signature to the SMTP envelope (MAIL FROM and RCPT TO) at the time of signing using the mf= and rt= tags. If a signed message is captured and forwarded to different recipients, the signature will fail verification because the envelope values no longer match what was signed