Email · 8 min read

DKIM2: The Biggest Change to Email Authentication Since DMARC

DKIM DKIM2 email authentication email infrastructure IETF

If you work in email infrastructure, you need to know about DKIM2. It’s not a minor revision. It’s a ground-up replacement for DKIM — the signing protocol that’s been largely unchanged since RFC 6376 in 2011. The IETF working group adopted the motivation document last September, the spec is at its second revision, and the drafts are moving fast.

Here’s what’s happening, why it matters, and what it means for your infrastructure.

What’s Wrong With DKIM1

DKIM has been a pillar of email authentication for fifteen years. It works — mostly. But it has three structural problems that have gotten worse as email infrastructure has gotten more complex.

Problem 1: Intermediaries break signatures. When a mailing list adds a footer, or a security gateway rewrites a URL, or a forwarder modifies a header — the original DKIM signature fails verification. The message was legitimately sent, legitimately processed, and legitimately delivered. But the math doesn’t check out anymore because the content changed after signing. This is the single biggest operational headache with DKIM1, and every email engineer has dealt with it.

Problem 2: Replay attacks. A DKIM1 signature proves that a domain signed a message. It does not prove who the message was intended for. The signature contains no recipient information. That means a bad actor can take a legitimately signed message and resend it — to thousands of different recipients — and the signature validates every time. The domain’s reputation takes the hit for messages it never intended to send to those addresses. This is not a theoretical attack. It happens at scale, constantly.

Problem 3: Backscatter. When a message can’t be delivered, the bounce notification goes to the envelope sender. But if the envelope sender was spoofed — which DKIM1 doesn’t prevent — the bounce goes to an innocent third party. This creates backscatter: unsolicited bounce messages flooding mailboxes that had nothing to do with the original send. It’s been a problem for decades, and DKIM1 doesn’t solve it.

DMARC helped with some of this by tying DKIM and SPF to domain alignment. But DMARC is a policy layer on top of broken fundamentals. DKIM2 fixes the fundamentals.

What DKIM2 Changes

The core architectural shift is this: DKIM2 moves from single-signature verification to a chain-of-custody model. Every system that handles a message adds its own numbered signature. The result is a verifiable record of every hop the message took from origin to destination.

Chain of Custody

In DKIM1, the originating domain signs the message once. That’s it. If anything changes downstream, the signature breaks and there’s no recovery.

In DKIM2, each hop adds a DKIM2-Signature header with a sequential index:

  • The originator signs at i=1
  • A mailing list that processes the message signs at i=2
  • A security gateway signs at i=3
  • The receiving MTA can verify the entire chain

This is conceptually similar to a blockchain — not in the cryptocurrency sense, but in the literal sense of a chain of signed blocks where each one references the previous. Every system that touches the message documents its involvement cryptographically.

Envelope Binding

This is the replay attack killer. Every DKIM2 signature includes two fields that DKIM1 never had:

  • mf= — the SMTP MAIL FROM at the time of signing
  • rt= — the SMTP RCPT TO at the time of signing

Each hop records who it received the message from and who it’s sending it to. The next hop in the chain verifies that its incoming MAIL FROM matches the previous signature’s RCPT TO. If someone takes a signed message and replays it to a different recipient, the chain breaks — the envelope doesn’t match.

This is simple and devastating. It solves replay attacks at the protocol level, not the policy level.

Modification Algebra

This is the most ambitious part of the spec — and the most operationally significant for anyone running mailing lists, security gateways, or any system that legitimately modifies messages in transit.

DKIM2 introduces a formal system for documenting modifications. When an intermediary changes a message — adds a footer, rewrites a URL, modifies a header — it records the change using a reversible algebra. The receiving system can then “undo” the documented modifications and verify the original signature.

The spec defines several modification types:

  • nomodify — the signer declares the message must not be altered
  • header — documents header changes with reversible operations
  • body — documents body changes with reversible operations
  • complex — substantial changes (like security gateway filtering) that require implicit trust

This means a mailing list can add [LIST-NAME] to the subject line, document that change in its DKIM2 signature, and the receiving MTA can verify both the list’s signature and the original sender’s signature by reversing the documented modification. In DKIM1, that subject line change would have broken the original signature permanently.

Bounce Routing

DKIM2 routes delivery status notifications backward along the authenticated chain. Instead of bouncing to whatever address is in the envelope sender — which may be spoofed — the bounce travels back through the verified hops. This eliminates backscatter by design.

Timestamps and Expiration

Every DKIM2 signature includes a t= timestamp. The spec recommends verifiers treat signatures older than about a week as suspicious. This limits the window for replay attacks even further — a captured signature becomes useless after a short period.

What Stays the Same

Not everything changes. A few important things carry over from DKIM1:

  • DNS key storage — Keys still live at selector._domainkey.example.com. Same location, same lookup mechanism.
  • Cryptographic algorithms — RSA-SHA256 is still supported. Ed25519-SHA256 is added and recommended. Both are mandatory for verifiers.
  • Coexistence — DKIM2 messages can carry both DKIM1 and DKIM2 signatures simultaneously during the transition period. You don’t have to rip and replace overnight.

What This Means for Your Infrastructure

If you run email infrastructure — MTAs, relays, mailing lists, security gateways — here’s what you need to start thinking about:

Every hop needs to sign. In DKIM1, only the originating domain signs. In DKIM2, every system that processes the message adds a signature. That means your relay, your mailing list manager, your outbound gateway — they all need signing keys and the logic to add DKIM2 headers. This is a significant operational change.

Verification gets more complex. You’re no longer checking one signature. You’re validating a chain — checking sequential indexes, verifying envelope binding between hops, potentially reversing documented modifications. Your inbound verification logic needs to understand chain validation, not just single-signature checks.

Key management scales up. More signing points means more keys to manage, rotate, and publish in DNS. If you were already struggling with key rotation for DKIM1, DKIM2 will amplify that problem.

Mailing list operators get the biggest win — and the biggest lift. The modification algebra means mailing lists no longer break authentication. That’s huge. But implementing it requires the list software to formally document every change it makes using the specified algebra. That’s new code for every mailing list implementation.

SMTP negotiation changes. DKIM2 capability is discovered at the SMTP level — clients query support using RCPT TO: <address> DKIM2. If the receiving system doesn’t support DKIM2, the sending system falls back to DKIM1. This means your SMTP implementation needs to handle the negotiation.

Where It Stands

DKIM2 is currently in the Internet-Draft phase at the IETF. The key documents:

This is not an RFC yet. It’s not a standard you need to implement tomorrow. But it’s moving — the working group is active, the drafts are iterating, and the problems it solves are real enough that major providers have incentive to adopt.

If you’re planning email infrastructure work in the next 12–18 months, you should be reading these drafts. The chain-of-custody model is a fundamental architectural shift, and the sooner you understand it, the better positioned you’ll be when the big providers start rolling it out.

The Bottom Line

DKIM has been showing its age for years. The workarounds we’ve built — ARC for forwarding chains, DMARC for policy alignment, reputation systems for replay mitigation — are patches on a protocol that didn’t anticipate how email would actually be processed in 2026. DKIM2 doesn’t patch. It replaces.

The chain-of-custody model, envelope binding, and modification algebra together solve the three biggest problems in email authentication. And they do it at the protocol level, which means the fixes are structural, not heuristic.

Keep an eye on this one. It’s the most significant change to email authentication infrastructure since DMARC — and arguably more important, because it fixes the layer that DMARC was built on top of.