DKIM2 (in-progress IETF work)

If you sign mail with DKIM, a redesign called DKIM2 is on its way, and it is meant to fix replay and the damage that forwarders and mailing lists do to signatures. It is not ready to deploy, but it is worth tracking so that your signing systems can adapt when it is.

Status warning: this is standards work in progress, not a standard you can deploy. Everything below comes from active Internet-Drafts in the IETF dkim working group (WG), which was given a new charter, as retrieved on 2026-07-20. Internet-Drafts are working documents. Tag names, header names and meanings will change between revisions, and the effort may stall entirely. Do not build production systems that depend on these details; use them to follow the direction of the work. DKIM (RFC 6376, STD 76) remains the standard in force.

Why DKIM2 exists

DKIM v1 has two built-in weaknesses that the email ecosystem has spent 15 years working around:

1. Replay. A signature is valid for any recipient, forever (within x=). See DKIM Replay Attacks.
2. Breakage by intermediaries. Forwarders and mailing lists that modify messages destroy signatures, and DMARC then penalizes the mail. ARC records what an intermediary saw, but not what it changed, and it requires you to trust the intermediary.

DKIM2's answer is that every hop that handles the message signs it, each signature is bound to the SMTP envelope of that hop, and changes are recorded in a way that can be reversed, so the final receiver can rebuild and verify the message as it was first signed. As a side effect, bounces become fully authenticated, which eliminates backscatter.

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

The authors work at Yahoo, Google and Fastmail, which shows support from receivers, and receiver support is what has made or broken past email standards. The mailing list archive is at mailarchive.ietf.org/arch/browse/ietf-dkim/.

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

Two new headers

Message-Instance: one for each revision of the message, with these tags:

• m= the revision number (the originator's version is 1, and any hop that modifies the message increases it)
• h= the hashes for this instance, in the format sha256:<header-hash>:<body-hash>
• r= base64-encoded JSON "recipes" to rebuild the previous instance (see below)

DKIM2-Signature: one for each hop that handles the message, with these tags:

• i= the hop sequence number (the originator's is 1, and each signer increases it; a gap in i= or m= invalidates the chain)
• m= which Message-Instance this hop signed
• t= a Unix timestamp (reject timestamps in the future; MAY ignore signatures >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-paths used at this hop
• nd= "next domain", which links internal hand-offs where no real SMTP transaction takes place
• n= an optional nonce (≤64 characters), and f= flags
• d= and s=, the domain and selector as in DKIM1, with the signature value written as <selector>:<alg>:<sig>

Chain of custody and replay resistance

• Each hop records the envelope it used. Verifiers check that the mf= domain of hop i aligns with its d= (relaxed match), and that the rt= of the hop before it (i−1) links to the mf= of hop i.
• The recipient's server checks that the actual RCPT TO of the transaction that delivers the message matches the final rt=. A replayed message carries the original recipient in the signed rt=, so sending it to new RCPT TOs breaks the chain. This is the replay fix that DKIM1 has no way to express.
• Legitimate distribution from one sender to many recipients must be declared openly. f=exploded marks deliberate distribution to many recipients (mailing lists), f=donotexplode asks for delivery to a single recipient, and f=donotmodify forbids changes to the content (a violation is a FAIL and blocks further forwarding).

Recipes: records of changes that can be reversed

An intermediary that modifies a message (adding a list footer or a subject tag) increases m= and publishes in r= a JSON description of the difference, so that the previous instance can be rebuilt:

• "h" maps header names to steps, and "b" holds the body steps.
• Steps are either {"c":[start,end]}, which copies ranges (headers are numbered from the bottom up, and body lines from the top down starting at 1), or {"d":[...]}, which inserts literal values.
• "b": null declares a change to the body that cannot be reversed.

The final verifier works back through the recipes to instance 1 and checks the originator's signature. This solves the problem of mailing lists and DMARC without the blind trust that ARC requires.

The BCP raises a privacy concern: recipes can put back content that an intermediary deliberately removed, such as data loss prevention (DLP) redactions or malware attachments that were stripped. Null recipes are the way out, and guidance for jurisdictions under the GDPR is still an open item.

Simpler cryptography and canonicalization

• Hashing: SHA-256 is mandatory. Signing: rsa-sha256 (PKCS#1 v1.5, e=65537, ≥1024-bit keys; verifiers support 1024–2048) and ed25519-sha256 (RFC 8032 PureEdDSA). The BCP says to sign with both algorithms.
• A single canonicalization replaces DKIM1's choice between simple and relaxed. For the signature input, header names are lowercased, headers are unfolded, and all whitespace is deleted. The header hash sorts headers alphabetically (headers with the same name keep their order from the bottom up). The body hash works like simple canonicalization (trailing empty lines are reduced to one CRLF). Hashing is done on the form sent on the wire (after content-transfer-encoding, before dot-stuffing).
• These headers are left out of the header hash: Received, Return-Path, Delivered-To, DKIM-Signature, ARC-*, Authentication-Results, X-*, Message-Instance, DKIM2-Signature.
• There is no v= tag, because the new header name identifies the version. Key records live at the same location, <selector>._domainkey.<domain>, with k= matching the algorithm. DKIM1 and DKIM2 can therefore share key infrastructure and coexist on one message, in any order.

Verification results and authenticated DSNs

• Results (compatible with RFC 8601) are PASS, FAIL, PERMERROR and TEMPERROR, with standard error messages that people can read (for example, FAIL: Message Instance m=<x> body hash <value> mismatch).
• Delivery status notifications (DSNs) go to the mf= of the DKIM2-Signature with the highest number, which is the hop that actually handed you the message, never a forged stranger. No DSN is sent when mf=<>. Each forwarder passes the DSN back one hop, after checking that the embedded message matches what it signed earlier and removing its own DKIM2 headers.
• As a result, bounces are authenticated from end to end, and backscatter cannot happen for mail that stays within the DKIM2 ecosystem. The flags feedback and feedhere outline a channel for delivery feedback (details not yet defined).

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

• Senders: sign with both DKIM1 and DKIM2 "until deployment is effectively ubiquitous", with both RSA and Ed25519. Sign only at the point where mail leaves your systems, and rotate keys following M3AAWG practice.
• Forwarders: verify messages when they arrive, and sign every message when it leaves (modified or not) to keep the chain intact. Add your signature only to messages that arrived with a valid DKIM2 chain. Messages that arrive with only DKIM1 need to be checked against local policy before you add them to your chain.
• Receivers: for mail entirely within the DKIM2 ecosystem, a broken chain may be safely rejected, because the DSN is proven to reach a responsible party. For partial or missing chains, fall back to DKIM1 and local policy during the transition.
• The draft itself lists open questions: limits on the number of Message-Instance headers and signatures, the future role of DMARC and SPF, and the meaning of feedback. Several sections literally say "Need some text."

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

This individual draft, not adopted by the WG, argues that the full specification is too heavy for small operators and proposes a profile with two tiers. It stands out because it uses different header layouts (DKIM2-Sig-mf, DKIM2-Sig-rt and DKIM2-Mod) from the WG specification, which shows how unsettled the wire format still is:

• DKIM2-core (the mandatory tier): binding to the envelope, chain of custody, declarations of header changes and authentication of DSNs. All of it is stateless and can be implemented as a milter, with no changes to the core of the mail transfer agent (MTA). WG co-chair M. Kucherawy agreed, and a working prototype has been published. Limits: at most i≤20 hops (~15–16 in a realistic worst case), ≤500 recipients per hop, and relaxed domain matching limited to removing 2 labels.
• DKIM2-extended (optional): full body recipes and rebuilding from Message-Instance headers. It needs persistent state, will take longer to adopt, and carries a heavier privacy burden.
• Rule for several algorithms: if any one signature at a hop fails, the whole hop is invalid (this prevents downgrade attacks).

Realistic timeline and what an ESP should do

• No RFC exists yet, and the core specification is at -04 with substantial open issues. Even after it is published, DKIM2 delivers its guarantees only when every hop on a path takes part. Expect a transition lasting several years, during which signing with both DKIM1 and DKIM2 is the norm, and DKIM1 with DMARC remains what mailbox providers enforce. For comparison, ARC (RFC 8617, 2019) is still only partly deployed.
• What an email service provider (ESP) should do now: nothing in production. Follow the draft revisions and the ietf-dkim list. Make sure your signing pipelines can add a second type of signature and envelope data for each message, which is the main architectural demand of DKIM2. Keep using today's replay mitigations (oversigning, selectors for each stream).
• What to watch for: the WG last call on dkim2-spec, announcements of pilots on the receiving side at Gmail, Yahoo and Fastmail (the co-authors' employers), and whether the simplifications in the milter profile are merged.

Related articles

• DKIM, the current standard that DKIM2 would eventually replace
• DKIM Replay Attacks
• ARC, the interim mechanism for intermediaries that DKIM2 aims to make obsolete
• Backscatter & BATV