DKIM2: what's new, what's changing and key dates

TL;DR — DKIM2 is a rewrite in progress within the IETF (Internet-Drafts) that aims to sign both the source and the destination of every SMTP hop, chain signatures (i=1, i=2, ...), document modifications introduced by intermediaries, and make bounces (DSN) traceable along the chain. DKIM2 is not a standard yet: it is moving fast, but the main building blocks are already there.

ℹ️ The terms DKIM replay and backscatter are defined in the glossary at the end of this article.

Why talk about DKIM2 now?

DKIM (STD 76, RFC 6376) is massively deployed to sign email content. But it shows its limits against DKIM replay, modifications performed by mailing lists/forwarders, and backscatter (bounces sent to third parties). DKIM2 proposes a model where each relay adds its own signature, numbered, and explicitly declares the source → destination pair of the next hop, which makes it possible to:

• detect and limit replays;
• route bounces and reports back along the authenticated path;
• describe and, when possible, undo body/header changes to validate the originating signature.

Key changes (compared to DKIM "v1")

1. New DKIM2-Signature header (no version field)

   • Numbering with i= (1, 2, ...). A gap in the sequence invalidates the chain.
   • Timestamp t=; a verifier may treat a signature as expired after a window (e.g. 14 days).
   • Algorithms: RSA-SHA256 and Ed25519-SHA256 are targeted, with planned crypto agility.
   • Keys in DNS: same as DKIM, under selector._domainkey.domain.

2. Chaining and alignment with the SMTP envelope

   • mf= (MAIL FROM) and rt= (RCPT TO) describe the envelope used on the signed hop.
   • Each new hop must match the previous destination (or be "proxy-signed" via pp=).
   • The verifier validates the most recent signature first (highest i).

3. Modelling modifications

   • The draft introduces a MailVersion header to describe how to revert to the previous version (body/header recipes).
   • The signature carries mv= for the message version that is covered.
   • A f= (flags) field can signal modifiedbody, modifiedheader, exploded, donotmodify, feedback, etc.

4. Bounces and feedback

   • DSN and feedback are sent upstream through the chain to an involved actor, limiting backscatter.
   • Ability to specify feedback preferences (depending on the draft version).

5. Compatibility and coexistence

   • DKIM2 does not immediately obsolete DKIM (RFC 6376): coexistence is expected during a transition phase.
   • DNS records stay under _domainkey. Proxy signing (pp=) is planned, with alignment constraints and authorization proofs via DNS (e.g. dedicated record or MX relationship), depending on the drafts.

What disappears or changes significantly

• No v= in DKIM2-Signature (if a major break occurs, a future "DKIM3-Signature" would be created rather than bumping an internal version number).
• Simpler list of signed headers: a baseline of mandatory fields is defined; h= remains possible for specific cases.
• Simplified expiration handling: relies on t= and verifier-side recommendations rather than a strictly normative dedicated field.
• Parameters inherited from DKIM deemed too complex (e.g. z=) dropped in the early drafts.

⚠️ DKIM2 is being drafted: the exact syntax (tag names, flags, timelines) may still change. Check the draft versions cited below.

Sample headers (current drafts)

DKIM2-Signature: i=1; t=2025-10-24T08:01:02Z; d=example.com; s=sel2025;
  a=ed25519-sha256; bh=BASE64(...); b=BASE64(...);
  rt=user@dest.tld; mf=bounce@example.com; mv=2; f=modifiedheader,feedback

MailVersion: v=2; bh=BASE64(...);
  h.Subject=d:*,t:[Re] Special offer;
  h.From=d:*,b=am9obi5kb2VAZXhhbXBsZS5jb20=

Operational impact (summary)

• ESPs / relays: must sign every hop, manage mf=/rt=, record/undo simple modifications (recipes), and re-emit towards aligned target domains.
• Recipients: verify the latest signature first (i=Max), then walk back if required; reject early on hard failures.
• DNS: selectors and keys unchanged under _domainkey, plan "proxy" authorizations according to the DNS mechanism retained by the drafts.
• DMARC: as long as DMARCbis references DKIM (RFC 6376), DMARC keeps relying on DKIM. The DMARC→DKIM2 switchover is not immediate.

Timeline: recent milestones

• 5 Nov 2024: first public analysis posts on DKIM2 (e.g. Red Sift).
• 20 Nov 2024: announcement posts from DMARC vendors.
• 3 Sep 2025: IETF working group adopts the Motivation document (draft-ietf-dkim-dkim2-motivation-01).
• 17–20 Oct 2025: drafts published for -spec-02 (specification), -dns-03 (DNS), -header-04 (headers) and -modification-algebra-04 (MailVersion).

Readiness plan

1. Inventory where you already sign/verify DKIM (flows, hops, SRS/VERP, mailing lists).
2. Prototype on relays: compute mf=/rt=, add i=, choose algorithms (Ed25519 recommended), manage t=.
3. Track common modifications (ML footers, From: rewriting) and test reverting them through MailVersion.
4. DNS: normalize the key rotation cycle; prepare the "proxy" authorization mechanism if needed.
5. Verification: implement the "latest i= first" strategy, issue 5xx rejects during the SMTP exchange when the signature fails, 4xx on DNS TEMPFAIL.
6. Monitor the drafts (below) and plan feature flags to follow field changes.

Glossary

DKIM replay

• Definition: reuse (replay) of a message already signed with DKIM by a legitimate domain to re-send it at scale or to other targets without altering what is covered by the signature. The signature remains valid because DKIM signs the content (body/headers) but not the SMTP envelope nor the route.
• Why?: an attacker obtains a copy of a signed email (e.g. a newsletter) and redistributes it as-is; DMARC may still pass if the From: stays aligned.
• Symptoms: traffic spikes on the same signature (bh= identical), spam complaints, degraded reputation for the signing domain.
• Mitigations: rate limiting per selector, key rotation, short lifetimes, stricter DMARC (p=reject), behavioral filtering on the receiving side.
• What DKIM2 changes: the signature includes the envelope per hop (mf=/rt=) and chains the path (number i=), which makes replay detectable (inconsistent route) and enables targeted enforcement.

Backscatter

• Definition: unsolicited bounces (NDR/DSN) or auto-replies sent to an innocent third party whose address was spoofed in MAIL FROM/Return-Path.
• Why?: servers first accept the message, then generate a subsequent bounce; with a spoofed address, the bounce goes back to the victim.
• Symptoms: floods of DSN/auto-replies on a legitimate mailbox, damaged reputation, possible listings.
• Mitigations: reject during the SMTP exchange (not afterwards), strict SPF/DMARC, SRS/VERP to trace bounces, anti-auto-reply rules.
• What DKIM2 changes: DSN/feedback can be routed upstream through the signed chain, which reduces backscatter and reaches the actual actor involved.

Sources and further reading

• DKIM2 – specification: draft-clayton-dkim2-spec-02 (20 October 2025, expires 23 April 2026).
• DKIM2 – DNS: draft-chuang-dkim2-dns-03 (20 October 2025).
• DKIM2 – headers: draft-gondwana-dkim2-header-04 (20 October 2025).
• DKIM2 – modification algebra / MailVersion: draft-gondwana-dkim2-modification-algebra-04 (17 October 2025).
• Motivation (IETF working group document): draft-ietf-dkim-dkim2-motivation-01 (3 September 2025, replaces the individual versions).
• DKIM recap: RFC 6376; updates: RFC 8301, RFC 8463.

DKIM2 remains a work in progress. We will update this page as the drafts move toward an RFC.