DKIM2 (in-progress IETF work)

Status warning — this is IN-PROGRESS standards work, not a deployable standard. Everything below is extracted from active Internet-Drafts in the re-chartered IETF dkim working group, as fetched 2026-07-20. Internet-Drafts are working documents: tag names, header names, and semantics will change between revisions, and the effort may stall entirely. Do not build production dependencies on these details; do use this to track the direction of travel. DKIM (RFC 6376, STD 76) remains the operative standard.

Why DKIM2 exists

DKIM v1 has two structural failures the ecosystem has spent 15 years patching around:

1. Replay — a signature validates for any recipient forever (within x=); see DKIM Replay Attacks.
2. Intermediary breakage — forwarders and mailing lists that modify messages destroy signatures, which DMARC then punishes; ARC attests to what an intermediary saw but not to what it changed, and requires trusting the intermediary.

DKIM2's answer: every handling hop signs, each signature is bound to the SMTP envelope of that hop, and modifications are recorded reversibly so the final receiver can reconstruct and verify the originally signed message. A side effect is fully authenticated bounces, eliminating backscatter.

Working group status (as of 2026-07-20)

Document	Version / date	State
draft-ietf-dkim-dkim2-spec	-04, 2026-07-05, 43 pp	WG document, Standards Track intent. Authors: R. Clayton (Yahoo), W. Chuang (Google), B. Gondwana (Fastmail). Expires 2027-01-06.
draft-ietf-dkim-dkim2-bcp	-00, 2026-06-18, 16 pp	WG document. Author: T. Herr (GreenArrow). Replaces individual draft-herr-dkim2-bcp (-01, expired). Expires 2026-12-20.
draft-ietf-dkim-dkim2-dns	-00, 2026-07-20, 13 pp	WG document (DNS specification for DKIM2). Adopted from the individual draft-chuang-dkim2-dns.
draft-moccia-dkim2-deployment-profile	-06, 2026-07-19	Individual submission, not WG-adopted — a milter-deployability profile (below).
draft-ietf-dkim-replay-problem	-00, 2023-07-28	Expired problem statement that motivated the rechartering.

Author affiliations (Yahoo, Google, Fastmail) signal receiver-side buy-in, which is what killed or carried past email standards. Mailing list archive: mailarchive.ietf.org/arch/browse/ietf-dkim/.

The mechanism (per draft-ietf-dkim-dkim2-spec-04)

Two new headers

Message-Instance — one per revision of the message, tags:

• m= revision number (originator = 1, incremented by any modifying hop)
• h= hashes for this instance, formatted sha256:<header-hash>:<body-hash>
• r= base64 JSON "recipes" to reconstruct the prior instance (see below)

DKIM2-Signature — one per handling hop, tags:

• i= hop sequence number (originator = 1, incremented per signer; gaps in i= or m= invalidate the chain)
• m= which Message-Instance this hop signed
• t= Unix timestamp (reject future; MAY ignore >14 days old)
• mf= base64 of the RFC 5321 MAIL FROM reverse-path used at this hop (<> for DSNs)
• rt= base64 of the RFC 5321 RCPT TO forward-path(s) at this hop
• nd= "next domain" — bridges internal hand-offs with no real SMTP transaction
• n= optional nonce (≤64 chars), f= flags
• d=, s= domain and selector as in DKIM1; signature value as <selector>:<alg>:<sig>

Chain of custody and replay resistance

• Each hop records the envelope it used; verifiers check that hop i's mf= domain aligns (relaxed match) with its d=, and that hop i−1's rt= links to hop i's mf=.
• The recipient's server checks that the actual RCPT TO of the delivering transaction matches the final rt=. A replayed message carries the original recipient in the signed rt=; blasting it to new RCPT TOs breaks the chain — this is the replay fix DKIM1 cannot express.
• Legitimate one-to-many expansion is declared, not smuggled: f=exploded marks intentional multi-recipient distribution (mailing lists); f=donotexplode requests single-recipient delivery; f=donotmodify forbids content changes (violations = FAIL and block onward forwarding).

Recipes: reversible modification records

A modifying intermediary (list footer, subject tag) increments m=, and publishes in r= a JSON diff to reconstruct the previous instance: "h" maps header names to steps, "b" is body steps; steps are {"c":[start,end]} (copy ranges — headers numbered bottom-up, body lines top-down from 1) or {"d":[...]} (literal inserted values); "b": null declares an irreversible body change. The final verifier unwinds recipes to instance 1 and checks the originator's signature — solving the mailing-list/DMARC problem without ARC-style blind trust.

Privacy flag raised in the BCP: recipes can re-embed content an intermediary deliberately removed (DLP redactions, stripped malware attachments). Null recipes are the escape hatch; GDPR-jurisdiction guidance is an open item.

Simplified crypto and canonicalization

• Hash: SHA-256 mandatory. Signing: rsa-sha256 (PKCS#1 v1.5, e=65537, ≥1024-bit; verifiers support 1024–2048) and ed25519-sha256 (RFC 8032 PureEdDSA). BCP: sign with both algorithms.
• One canonicalization replaces DKIM1's simple/relaxed matrix: for signature input, lowercase header names, unfold, delete all whitespace; header hash sorts headers alphabetically (same-name preserved bottom-up); body hash is simple-style (trailing empty lines collapsed to one CRLF). Hashing happens on the wire form (after content-transfer-encoding, before dot-stuffing).
• Excluded from the header hash: Received, Return-Path, Delivered-To, DKIM-Signature, ARC-*, Authentication-Results, X-*, Message-Instance, DKIM2-Signature.
• No v= tag — the new header name is the version. Key records live at the same location <selector>._domainkey.<domain> with k= matching the algorithm, so DKIM1 and DKIM2 can share key infrastructure and coexist on one message in any order.

Verification results and authenticated DSNs

• Results (RFC 8601-compatible): PASS / FAIL / PERMERROR / TEMPERROR, with standardized human-readable error strings (e.g., FAIL: Message Instance m=<x> body hash <value> mismatch).
• DSNs go to the mf= of the highest-numbered DKIM2-Signature — i.e., to the hop that actually handed you the message, never to a forged stranger; never sent when mf=<>. Each forwarder relays the DSN back one hop, verifying that the embedded message matches what it previously signed and stripping its own DKIM2 headers. Result: bounces are authenticated end-to-end and backscatter is structurally impossible for DKIM2-ecosystem mail. Flags feedback/feedhere sketch a delivery-feedback channel (details TBD).

BCP guidance (draft-ietf-dkim-dkim2-bcp-00)

• Senders: dual-sign DKIM1 + DKIM2 "until deployment is effectively ubiquitous"; both RSA and Ed25519; sign only at egress; rotate keys per M3AAWG practice.
• Forwarders: verify on arrival; sign every message at egress (modified or not) to keep the chain intact; only forward-sign messages that arrived with a valid DKIM2 chain — DKIM1-only arrivals need local-policy vetting before you lend them your chain.
• Receivers: for mail fully inside the DKIM2 ecosystem, a broken chain may be safely rejected (the DSN provably reaches a responsible party); for partial/absent chains, fall back to DKIM1 + local policy during transition.
• Open questions flagged in the draft itself: caps on Message-Instance/signature counts, DMARC's and SPF's future role, feedback semantics — several sections are literally "Need some text."

The deployment-profile debate (draft-moccia-dkim2-deployment-profile-06)

An individual (non-WG) draft arguing the full spec is too heavy for small operators and proposing a two-tier profile — notable because it uses different header layouts (DKIM2-Sig-mf/DKIM2-Sig-rt/DKIM2-Mod) than the WG spec, illustrating how unsettled the wire format still is:

• DKIM2-core (mandatory tier): envelope binding, chain of custody, header-modification declarations, DSN authentication — all stateless and implementable as a milter with no MTA core changes (concurred by WG co-chair M. Kucherawy; working prototype published). Limits: hops i≤20 (~15–16 realistic worst case), ≤500 recipients per hop, relaxed domain match capped at removing 2 labels.
• DKIM2-extended (optional): full body recipes / Message-Instance reconstruction; requires persistent state, longer adoption cycles, heavier privacy burden.
• Multiple-algorithm rule: failure of any one signature at a hop invalidates the whole hop (downgrade-attack prevention).

Realistic timeline and ESP posture

• No RFC exists; the core spec is at -04 with substantive open issues. Even after publication, DKIM2 delivers its guarantees only when every hop of a path participates — expect a multi-year transition in which dual-signing (DKIM1+DKIM2) is the norm, and DKIM1+DMARC remain what mailbox providers enforce. For calibration: ARC (RFC 8617, 2019) is still only partially deployed.
• What an ESP should do now: nothing in production; track draft revisions and the ietf-dkim list; ensure signing pipelines can add a second signature type and per-message envelope data (the architectural ask of DKIM2); keep using today's replay mitigations (oversigning, per-stream selectors).
• What to watch for: WG last call on dkim2-spec, announced receiver-side pilots at Gmail/Yahoo/Fastmail (the co-authors' employers), and whether the milter-profile simplifications get merged.

Related

• DKIM — the current standard DKIM2 would eventually succeed
• DKIM Replay Attacks — the problem driving the redesign
• ARC — the interim intermediary mechanism DKIM2 aims to obsolete
• Backscatter & BATV — the bounce problem DKIM2's DSN chain solves