What Is DKIM2 and What Changed in the April 2026 Draft?

What Is DKIM2 and What Changed in the April 2026 Draft?

DKIM2 is a proposed next generation of the DomainKeys Identified Mail standard,  still a working draft, not a production-ready standard. The April 2026 update is the most substantive revision in years, introducing features that directly address the problems that make current DKIM fragile in real-world email flows, especially forwarding, mailing lists, and multi-server relay chains.

The core change is a new signing model. Instead of one sender adding a single DKIM signature that breaks the moment anything modifies the message, DKIM2 lets each intermediate server add its own signature. The message accumulates a verifiable history rather than being invalidated by legitimate modifications.

If you run email infrastructure that involves forwarding, mailing lists, or multiple relay hops, this matters. Here’s what changed and what it means for you.

Why DKIM Needed an Upgrade

DKIM as it exists today signs a message at the point of origin. The signature covers the message body and a defined set of headers. Any intermediate server that modifies the body or adds headers,  a mailing list appending a footer, a relay adding unsubscribe headers, a forwarder rewriting addresses, breaks that signature. Receivers see the broken DKIM and often treat the message as untrusted.

ARC (Authenticated Received Chain) was introduced to solve this. It let forwarders and revisers add their own signatures in a chain, so that even if the original DKIM broke, the chain could be verified. It worked, but ARC had its own complications. It required careful sequencing, added header overhead, and never achieved universal adoption.

DKIM2 takes the core idea of ARC, intermediate signatures, chain verification, and builds it directly into DKIM, making ARC redundant for most forwarding scenarios.

What the April 2026 Update Adds

Chain of custody: Each intermediate MTA (mail transfer agent) that handles the message adds its own DKIM signature with an increasing sequence number (i=1, 2, 3…). The sequence makes it possible to verify the chain in order and reconstruct the message state at any hop. This replaces what ARC was doing, but built into the DKIM spec itself.

Message-Instance headers and "recipes": A new mechanism lets a signer encode instructions, called recipes - in a base64-encoded header. These instructions tell a verifier how to reconstruct the prior state of the body or headers before a modification happened. So a mailing list footer that was added after signing can be temporarily removed during DKIM verification, and the signature still checks out. This is the answer to the "mailing lists break DKIM" problem.

Replay defense: Two new tags, mf= (mailfrom) and rt= (recipient), bind each signature to the SMTP envelope, the actual MAIL FROM and RCPT TO values at time of signing. If an attacker captures a signed message and re-sends it to other recipients, the mf= and rt= values won’t match, and verification fails. Flags like donotexplode, donotmodify, exploded, and feedback make the signer’s intent explicit.

DSN bounce handling: Bounces must now follow the chain back through the MTAs that actually handled the message. This prevents backscatter,  bounce messages sent to addresses that never originated the message in the first place.

Crypto: SHA-256 is now required. RSA-SHA256 and Ed25519-SHA256 are the two approved signing algorithms. The old v= tag (used to version DKIM signatures) is removed, there’s no version negotiation in DKIM2.

Chain of Custody - The Core Innovation

The chain-of-custody model is the most important conceptual shift in DKIM2. Here’s why it matters in practice.

Today, when a message goes through multiple servers, say, your company’s mail gateway, then a mailing list server, then a third-party relay, only the first server’s DKIM signature is checked. If any server in the middle modifies the message, that signature breaks. The receiver has no way to verify that the modifications were legitimate.

With DKIM2, each server in the chain adds its own signature. The final receiver can trace the message through every hop: who sent it, who forwarded it, who modified it, in what order. The verification is not binary, it’s a sequence.

In practice, this means mailing lists can add footers without breaking signatures. Forwarding services can rewrite subject lines without invalidating the chain. Relays can add unsubscribe headers and still pass verification. The original DKIM from your mail server stays valid because it’s part of the chain, not the sole point of failure.

What This Means for Mailing Lists and Forwarders

Mailing lists have been a persistent DKIM pain point. The moment a list server modifies anything, even just adding a header, the original DKIM fails. SPF also fails in many forwarding scenarios because the forwarding server’s IP appears in the SMTP transaction, not your sending server’s.

ARC attempted to fix this, but it required both the original sender and the forwarder to support it. DKIM2’s chain-of-custody model is more robust because it’s designed into the signing mechanism itself, and the Message-Instance recipes let receivers reverse-engineer modifications so the chain still verifies cleanly.

For operators running mailing lists or forwarding infrastructure, deploying DKIM2 will mean fewer authentication failures from legitimate modifications. It will also mean more signatures per message in your aggregate reports — each hop adds a signature, so a message that passes through three servers generates three DKIM signature records where there was previously one.

Replay Defense - Blocking Captured-And-Replayed Attacks

One underappreciated attack vector is the captured-and-replay attack. An attacker intercepts a legitimately signed marketing email during transit. Later, they resend that same email to a different recipient list — the same body, the same subject, the same signatures. Because the original signatures are still valid, the message passes authentication checks even though it is now spam.

DKIM2 blocks this with mf= and rt= tags. These bind the signature to the original SMTP envelope (MAIL FROM and RCPT TO). When the attacker re-sends the captured message to different recipients, the rt= value doesn’t match the new recipients, and verification fails.

This is not theoretical. Replay attacks are used in credential-phishing campaigns where a legitimate internal memo or invoice is captured, then resent to a wider set of targets with spoofed headers. DKIM2 makes that attack substantially harder.

DSN Bounce Handling Changes

DSN (Delivery Status Notification) bounce handling in DKIM2 also changes. Currently, a bounce can be sent back to the original sender address even if that address didn’t actually originate the message, this is how backscatter spam works, where servers send bounces to addresses that never sent the original message.

DKIM2 requires bounces to follow the chain back through the MTAs that actually handled the message. The bounce goes to the last hop that actually sent, not to a fabricated Return-Path.

For operators, this means cleaner bounce logs and fewer false bounce notifications. It also reduces the risk of your mail server being used as an unwitting backscatter source.

Cryptographic Requirements -  What Changed

DKIM2 mandates SHA-256. This retires the optional SHA-256 / SHA-1 distinction in current DKIM. RSA-SHA256 remains valid, and Ed25519-SHA256 is added as a new option. Ed25519 offers smaller signature sizes and faster verification, if your infrastructure supports it.

The v= tag is gone. Current DKIM signatures include v=DKIM1; DKIM2 removes version negotiation from the signature format entirely.

The practical implication: if you run DKIM validators, you need to update them to handle the new signature format, the i= sequence tags, and the new required fields before you can process DKIM2 signatures.

What Email Operators Need to Know Now

DKIM2 is a draft standard. No major receiver supports DKIM2 verification in production. The realistic timeline for meaningful adoption is 2027–2028 at the earliest, and that assumes the IETF review process doesn’t surface major issues.

Here’s what to do in the meantime:

Monitor your DKIM infrastructure. Track the IETF draft as it moves through review. The signature format changes and new tags will require updates to your signing and verification software before you can handle DKIM2 in production.

Track aggregate report complexity now. DKIM2 will add more DKIM signature records per message in your reports, each intermediate hop adds a signature. A message passing through three servers generates three DKIM signature records where there was previously one. Your DMARC reporting tool needs to parse and display these multi-signature chains cleanly. To see this properly, aggregated reports are required from a monitoring provider, for example, DMARCFlow. DMARCFlow handles this automatically, making it much easier to identify which hop in the chain is failing when authentication breaks down across a forwarding path. If you’re relying on manual XML parsing or a tool that only shows the top-level result, the additional signature data from DKIM2 rollouts will be harder to interpret.

Watch the IETF draft. The canonical spec is at datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/. Check the changelog when revisions are published and track which features are marked as stable vs. still debated.

Do not migrate yet. Keep your existing DKIM1 records. Run both in parallel until major inbox providers announce DKIM2 verification support. There’s no forced migration, the transition will be gradual.

FAQ - Common Questions About DKIM2

Is DKIM2 backwards compatible with DKIM?

Yes. DKIM2 signatures are additional, they don’t replace DKIM1. You can publish both DKIM2 and DKIM1 records for the same domain during a transition period. Receivers that understand DKIM2 will verify the newer chain; receivers that only understand DKIM1 will fall back to the original signature.

Does DKIM2 replace ARC?

Effectively, yes. DKIM2 is designed to solve the same problem, intermediate server signatures in forwarding chains, but built into the DKIM spec itself. ARC will become redundant once DKIM2 is widely deployed. If you currently rely on ARC for forwarding authentication, DKIM2 will eventually replace it.

What happens to my existing DKIM records?

Nothing changes immediately. Keep your existing DKIM1 records. When your DKIM signing software adds DKIM2 support, you can add DKIM2 keys in parallel. There’s no forced migration, the transition will be gradual.

When should I start deploying DKIM2?

Wait until major inbox providers (Google, Microsoft, Yahoo) announce DKIM2 verification support. Until receivers can verify DKIM2 signatures, the security benefit is minimal. In the meantime, ensure your signing infrastructure is keeping up with the IETF draft so you’re ready when adoption starts.

Does DKIM2 fix SPF failures on forwarding?

No. SPF failures on forwarding happen because the forwarding server’s IP appears in the SMTP transaction, not your sending server’s. SPF doesn’t care about DKIM. DKIM2 helps with DKIM verification across multiple hops, but SPF and forwarding remain a separate problem. The solution for SPF on forwarding is still typically to use a subdomain with a strict SPF record, or to move to DMARC-based alignment.

Will DKIM2 change how I read my DMARC reports? 

Yes, significantly. A single forwarded message will generate multiple DKIM signature records in your aggregate reports, one per hop. If your current reporting tool only shows the top-level result, you'll miss which specific hop in the chain caused a failure. DMARCFlow visualizes , so you can see exactly where authentication breaks down. If you're still manually parsing XML or relying on a tool that wasn't designed for chain verification, the DKIM2 transition will expose those gaps fast