DKIM2

DKIM has been the backbone of email authentication since 2007. Nearly two decades later, its limitations are becoming impossible to ignore: forwarded emails break signatures, replay attacks exploit signed messages at scale, and mailing lists routinely cause legitimate emails to fail authentication. DKIM2 is a ground-up redesign that aims to fix all of this — and it just got adopted by the IETF working group.

Why DKIM Needs a Successor

DKIM (RFC 6376) was designed for a simpler email landscape. It proves that a message was sent by a specific domain, but that's where its guarantees end. If you're unsure how your own records hold up, check your DKIM record — many of the weaknesses below are made worse by misconfigured keys. Over the years, three fundamental weaknesses have become clear.

Forwarding Breaks Signatures

When an email passes through a mailing list, a forwarding service, or a spam filter, the message often gets modified, a footer is appended, a header is tweaked, the subject line gets a prefix. Even minor changes invalidate the original DKIM signature. The receiving server sees a broken signature and may reject a perfectly legitimate email.

ARC (Authenticated Received Chain) was introduced as a patch for this problem, but it has its own issues. ARC lets intermediaries vouch for the original authentication, but it doesn't prevent them from making massive changes to a message and still claiming it was the original. There's no way for the receiver to know what was actually changed.

Replay Attacks

A signed DKIM message contains no information about who it was intended for. An attacker can take a legitimately signed email and replay it to millions of recipients. The signature validates every time because DKIM only proves the message came from the domain — not that it was meant for you. This is actively exploited for spam at scale.

Backscatter

When a spammer forges your domain in the bounce address, and their messages get rejected, you receive the bounce notifications. DKIM provides no mechanism to prevent this. Innocent domains get flooded with delivery failure notifications for emails they never sent. A properly configured DMARC policy helps receivers reject forged mail earlier, but it can't prevent the bounces from being generated in the first place.

What DKIM2 Changes

DKIM2 is not an incremental update. It introduces a fundamentally different model: instead of a single signature from the originating domain, DKIM2 builds a chain of signatures across every hop in the delivery path.

Signature Chaining

Every mail server that handles a DKIM2-signed message adds its own DKIM2-Signature header with an incremented sequence number (i=1, i=2, i=3, etc.). Each signature covers the current state of the message, creating an authenticated chain of custody from sender to recipient. Gaps in the numbering must be treated as making the entire message unsigned.

The verifier checks the latest signature first. If the message hasn't been altered, that's sufficient. If modifications were made along the way, it walks backward through the chain, applying reversal recipes at each step to verify earlier signatures. This means the receiving server doesn't just know who sent the message — it knows every server that handled it and what each one changed.

Envelope Signing

DKIM only signs message content. DKIM2 also signs the SMTP envelope via two new tags in every signature: mf= (the MAIL FROM address) and rt= (the RCPT TO addresses). Each hop cryptographically binds the envelope to the signature. The chain must link: the mf= of each new signature must match an rt= entry from the previous one.

This is what makes replay detection possible: if a message was signed for one recipient but shows up at a different address, the mismatch is immediately detectable.

Modification Tracking

When an intermediary modifies a message (adding a mailing list footer, rewriting a header), DKIM2 requires it to record exactly what changed using a Message-Instance header field. This header contains an r= tag with base64-encoded JSON "recipes" that describe the modifications in enough detail that a verifier can reverse them, reconstruct the original message, and verify earlier signatures in the chain.

The recipe algebra is defined in a companion specification called MailVersion. The originator can even request that intermediaries not alter the message by setting f=donotmodify — though compliance is voluntary.

Signing All Headers

DKIM requires signers to manually list which headers to sign via an h= tag. This leads to inconsistent signing where security-critical headers may be left unprotected. DKIM2 takes the opposite approach: all headers are signed by default, with only trace and legacy authentication headers excluded (Received, Return-Path, X--prefixed headers, DKIM-Signature, and ARC- headers). The canonicalization process sorts headers alphabetically, making the signing deterministic regardless of header order.

Bounce Routing

In DKIM2, bounces travel back along the same signed chain. A delivery status notification can only go to a domain that actually sent the message, and can only be sent from a domain that received it. This eliminates backscatter entirely.

Timestamps and Expiration

Every DKIM2 signature includes a mandatory timestamp (t=). Verifiers can treat old signatures as expired (e.g., after 14 days), which limits the window for replay attacks. An old signed message has no lasting value to attackers.

Dual Signatures and Crypto Agility

Each DKIM2-Signature can carry multiple independent signatures using different algorithms within a single s= tag. Each entry contains a selector, algorithm name, and signature value (e.g., s=sel1:rsa-sha256:abc...,sel2:ed25519-sha256:xyz...). A signer might use RSA-SHA256 as one signature and Ed25519-SHA256 as the other. This built-in redundancy allows the ecosystem to migrate away from an algorithm without a flag day — if one algorithm is compromised, the other still validates. Verifiers must support both RSA-SHA256 and Ed25519-SHA256.

Same DNS Namespace

DKIM2 public keys are stored under the same selector._domainkey.domain DNS namespace as DKIM. The keys themselves are no different. This means organizations don't need separate DNS infrastructure for DKIM2 — existing key management and rotation practices carry over directly.

What a DKIM2-Signature Looks Like

Here's a simplified example of two chained signatures — the original sender and a mailing list forwarder:

DKIM2-Signature: i=1; d=sender.example; t=1711497600; mf=alice@sender.example; rt=list@mailinglist.org; s=sel1:ed25519-sha256:xyz789...; bh=abc123...DKIM2-Signature: i=2; d=mailinglist.org; t=1711497660; mf=list@mailinglist.org; rt=bob@receiver.example; s=sel2:rsa-sha256:uvw321...; bh=def456...

The i=2 signature tells the receiver: this message originated at sender.example (i=1), was forwarded through mailinglist.org (i=2), and was delivered to bob@receiver.example. Each mf= matches the previous rt=, forming an unbroken chain.

DKIM vs. DKIM2 Comparison

Feature	DKIM	DKIM2
Signatures	Multiple allowed, independent	Chained per hop (i=)
Envelope	Not signed	mf= and rt= signed
Forwarding	Breaks on change	Recipes reverse modifications
Replay	Vulnerable	Recipient bound per hop
Backscatter	No protection	Chain-routed bounces
Headers	Manual h= list	All signed by default
Canonicalization	Simple or relaxed	Single mode, sorted
Algorithms	RSA-SHA256, Ed25519 (RFC 8463)	Both mandatory via s=
Verification	Each sig evaluated independently	Latest first, walk back
Timestamps	Recommended (t=)	Mandatory (t=)
DNS keys	_domainkey	Same _domainkey
Flags	DNS key flags only (t=y, t=s)	f= per-signature advisory flags
Version	v=1 in signature	No v= tag

The Specification Suite

DKIM2 is defined across several companion documents progressing through the IETF. Three have been adopted by the working group (indicated by the draft-ietf-dkim prefix):

• Core specification

  Defines signature format, chaining, verification, and bounce handling. Authored by Richard Clayton (Yahoo), Wei Chuang (Google), and Bron Gondwana (Fastmail).

• Motivation document

  Explains why DKIM2 is needed and what problems it solves. Adopted by the working group in September 2025.

• Header definitions

  Defines the DKIM2-Signature header field structure, tag formats, and flag values.

• DNS specification

  DNS record format for DKIM2 public keys. Individual submission, not yet WG-adopted.

• MailVersion

  The modification algebra for describing and reversing changes made by intermediaries.

Timeline

Date	Milestone
October 2024	Motivation and modification algebra drafts published
August 2025	Core specification first draft published
September 2025	WG adopts Motivation document
November 2025	IETF 124 hackathon interop testing (Montreal)
March 2026	WG adopts core specification

Active Debates and Challenges

DKIM2 has strong momentum, but it also faces substantial criticism on the IETF mailing list. These are not minor issues — they reflect real deployment concerns.

Deployment Complexity

DKIM2 requires every server in the delivery chain to participate: MTAs, forwarders, mailing list managers, spam filters, antivirus gateways — anything that adds or modifies headers or message bodies. Critics point out that much of the internet's email infrastructure is operated by small ISPs, universities, and businesses who cannot upgrade their entire mail stack on the timeline a new standard demands.

DKIM was adopted largely through milter plugins (like OpenDKIM) that bolt onto existing MTAs without modifying their core code. DKIM2's envelope binding and per-hop signing may require native MTA support rather than plugin-based implementation, creating a hard dependency on upstream MTA development timelines.

Privacy Concerns

The "body recipes" mechanism that enables modification tracking has raised privacy and legal questions. Recording what changes were made to a message body — and making that information available to downstream verifiers — could expose information about content filtering decisions, organizational processes, or user data in ways that conflict with privacy regulations.

Interoperability Issues

The IETF 124 hackathon in November 2025 revealed concrete ambiguities in the specification — the hackathon report noted that "specifications were woefully incomplete for actual implementation." Participants encountered disagreements about header ordering for signature input, confusion about null signature encoding, and JSON serialization problems where different valid encodings produce different hashes. These are being addressed in subsequent drafts, but they highlight the gap between specification text and working implementations.

The Simpler Alternative

Some participants argue that a lighter approach — extending ARC with explicit envelope binding (as proposed in draft-chuang-replay-resistant-arc) — could solve the replay problem with far less deployment complexity. That draft reached version 11 before expiring and was co-authored by Wei Chuang, who is also a DKIM2 co-author.

Conclusion

DKIM2 is not something you need to act on today. The specification was just adopted by the working group in March 2026 and has years of standardization work ahead before becoming an RFC. There is no production deployment yet.

However, there are things worth doing now:

• Get your DKIM house in order.

  Ensure your current DKIM signatures use 2048-bit RSA keys at minimum. Rotate keys regularly. Check your DKIM records to verify they're correctly published and using strong algorithms.

• Monitor the standards process.

  The IETF DKIM working group publishes all drafts and discussions publicly.

• Watch your MTA vendors.

  When Postfix, Exim, or your email provider announces DKIM2 support, that's when transition planning begins.

• Keep DMARC enforcement active.

  DKIM2 complements DMARC — it doesn't replace it. Strong DMARC policies remain essential regardless of which DKIM version you use. If you haven't already, run a DMARC check to make sure your policy is correctly configured and aligned.

DKIM2 represents the most significant change to email authentication infrastructure since DMARC. The problems it solves are real, the engineering talent behind it is serious, and the working group adoption signals genuine industry commitment. The question is not whether email authentication will evolve — it's how smoothly the transition will happen.