DKIM2 (draft-ietf-dkim-dkim2-spec-01): The 2026 Successor to ARC and DKIM, Explained

On 20 April 2026, the IETF DKIM Working Group published draft-ietf-dkim-dkim2-spec-01, the first revision of the DKIM2 specification posted under a working-group filename. Four days earlier, on 16 April 2026, the IESG rechartered the DMARC Working Group for the sole purpose of moving RFC 8617 (ARC) to Historic. The two events are not coincidences. They are the same standards-track decision, written in two documents.

This article reads all five active DKIM2 drafts, the WG-adopted ARC retirement vehicle, and the DMARCbis cluster, then explains exactly what is locked in, what is still contested, and what an email administrator should plan for between now and the first quarter of 2027. The primary keyword DKIM2 will recur because the spec, the motivation document, and four supporting drafts all converge on that term — the IETF has chosen it deliberately to mark a generational break from RFC 6376.

If you are new to ARC and need the working explainer for forwarded mail under the current rules, start with our companion piece on ARC email authentication and come back. ARC is not dead. The IETF has formally pointed at the exit and started a clock — but the clock is long, and the door is still open.

What DKIM2 is — and what it isn’t

DKIM2 (DomainKeys Identified Mail v2) is a per-hop chained-signature email accountability protocol that binds every SMTP envelope — MAIL FROM and RCPT TO — into a DKIM2-Signature header indexed by i=. Every system that handles a message adds a new signature at the next index, carrying the envelope addresses it observed plus a Unix-time stamp. A verifier can re-run the chain, match each hop to the next, and reject anything that does not link.

DKIM2 is not a version bump on the original DKIM specification. The new header will be called DKIM2-Signature rather than DKIM-Signature; v=2. Allen Robinson’s worked examples explicitly note that the literal string DKIM2-Signature is a placeholder, so the field name itself could move before publication — but the choice not to overload the existing header is settled. DKIM1 verifiers see no change to the messages they read today.

DKIM2 is also not the Microsoft selector2 label, despite the name collision that lands dkim2 microsoft searches on Microsoft Q&A pages. The selector convention is a DNS-rotation pattern in Azure Communication Services. The protocol is an IETF draft.

And DKIM2 is not yet a formal obsoletion of either RFC 6376 or RFC 8617. Neither draft-ietf-dkim-dkim2-spec-01 nor the motivation companion carries an Obsoletes: line. The original DKIM specification (RFC 6376) remains in force, and ARC is still the live answer for forwarded mail. The authors describe DKIM2 as a generational successor — Bron Gondwana called it “designed to replace DKIM … entirely replace DKIM eventually” on the ietf-dkim list in November 2024 — but the documentary record is more careful. DKIM2 runs as a parallel track in protocol terms. Coexistence comes first; obsoletion comes later, if it comes at all.

The five active DKIM2 drafts

The DKIM working group has produced two adopted documents — the motivation and the spec — and three individual submissions cover the DNS encoding, the modification-handling algebra, and worked examples. Here is the complete record the SERP currently lacks, with status accurately flagged.

Three notes on the table. Slug typo: the modification-algebra draft is misspelled alegbra on the IETF datatracker. The page reproduces the typo verbatim where we cite the slug because any other spelling will 404 — the word “algebra” itself is spelled correctly in prose. Dates: draft-ietf-dkim-dkim2-motivation was WG-adopted in September 2025; the spec adoption call closed on 16 March 2026 and revision -01 was posted 20 April 2026. Both dates matter — they apply to different documents. Author names: the message-examples draft is by Allen Robinson at Google, not “Robert Robinson” as some early references state.

External references for this section:

• draft-ietf-dkim-dkim2-motivation
• draft-ietf-dkim-dkim2-spec
• draft-chuang-dkim2-dns
• draft-gondwana-dkim2-modification-alegbra
• draft-robinson-dkim2-message-examples

What’s settled, what’s contested, who’s championing

Most public DKIM2 coverage skips this section. The protocol’s architectural spine is locked in across all five drafts, but four encoding and ordering questions are still moving on the ietf-dkim list. Separating settled from contested — with named voices on both sides — is what an admin needs to track DKIM2 honestly.

The five architectural commitments (settled)

These five design choices appear consistently across every draft and have not drawn substantive list opposition.

1. Per-hop signing. Every system that handles a message adds a new DKIM2-Signature header. The spec frames this as a “chain of custody” that lets validators distinguish messages intended for a specific recipient from messages being replayed at scale (draft-ietf-dkim-dkim2-spec-01 §1).
2. Source-and-destination binding. Every signature records the SMTP envelope via mf= (MAIL FROM) and rt= (RCPT TO). The receiver of a message checks for an exact match between the envelope values and the highest-numbered DKIM2-Signature (spec §7.5–7.6 and §8.2).
3. DKIM2-Signature header name and chained i= indices. The originator uses i=1. Every later forwarder adds a header one greater than the highest already present. Gaps in the numbering MUST be treated as making the whole message unsigned (spec §7.1).
4. Replay resistance via timestamps and chain of custody. Verifiers SHOULD return failure for signatures more than 14 days old. The motivation draft adds plainly that “DKIM2 headers will always have timestamps so that ‘old’ signatures have no value” (spec §10.3, motivation §3.1).
5. DNS reuse, not a new RR type. TXT records under the _domainkey namespace from RFC 6376 are reused unchanged; no new DNS resource-record type is introduced (draft-chuang-dkim2-dns-04 §3.4.2.1).

The four contested questions (still moving)

The ietf-dkim list since September 2025 has produced four cleanly verified two-party disputes. Each has named voices on both sides.

Header recipe numbering — bottom-up versus top-down. Bron Gondwana (Fastmail) defends bottom-up numbering so that recipes can read Authentication-Results: [1, 3] rather than [2, 4]. Hannah Stern (1&1 Mail & Media) objected on 17 March 2026, preferring top-down so that hashing and recipe execution stay consistent.

Signing-input ordering — interleaved versus all-then-all. Gondwana, in his 18 March 2026 hackathon review, argued interleaved ordering is the semantically correct interpretation: when signature i=1 was created, only Message-Instance v=1 existed. Stern defended the all-Message-Instance-then-all-Signature reading already in §11.5 of the predecessor Clayton spec.

Base64-of-JSON inside DKIM2-Signature tag values. Gondwana defended embedding JSON inside Base64 inside tag values for parser convenience. Wei Chuang (Google) objected on opacity grounds — special tooling would be required to read DKIM2 signatures. Chuang’s objection prevailed: the WG -01 spec explicitly removed JSON for hashes, signatures, and SMTP parameters.

Per-recipient binding mechanism — rt= header tag versus envelope or separate header. During the October 2025 Call For Adoption of draft-gondwana-dkim2-header-02, R. Latimer (Inveigle.net) objected on 18 October 2025 that the rt= mechanism itself carries data-leakage risk that header-only construction cannot fully mitigate.

Who is championing DKIM2

Four named voices carry the public record.

Bron Gondwana (Fastmail) is the lead motivator. On the ietf-dkim list, 20 November 2024: “DKIM2 is designed to replace DKIM … It’s supposed to entirely replace DKIM eventually.”

Richard Clayton (Yahoo) is the lead spec author. From the IETF 122 DKIM WG minutes, 21 March 2025: “It was not a design aim of DKIM2 to sweep up DMARC, ARC, greylisting, etc.; it’s meant to be a cleaner solution.”

Wei Chuang (Google) is the DNS draft’s sole author. On the ietf-dkim list, 10 July 2025: “DKIM2 intends to be compatible with the existing DKIM installed base of keys hence this part of the specification is essentially the same as RFC6376.”

Allen Robinson (Google) co-authored the message-examples draft. On the ietf-dkim list, 23 March 2025: DKIM2’s “two independent headers” mean DKIM1 verifiers “would observe no change.”

The DKIM working group charter permits — but does not mandate — superseding existing technologies under RFC 8617.

How DKIM2 differs from ARC under three real-world scenarios

The architectural debate matters most at three operational moments: replay, originator key rotation between send and forward, and the three-hop forwarder chain. Reading the behavior side-by-side is the fastest way to see where the new protocol earns its complexity.

Replay of a captured message

ARC explicitly admits the gap. RFC 8617 §9.5 acknowledges that ARC inherits DKIM’s replay weakness. The validator algorithm in §5.2 confirms structural integrity, verifies the most recent AMS, and verifies every AS back to i=1 — but it has no step that compares the message envelope, recipient, or timestamp against any state. A captured ARC-bearing message replayed to a new recipient validates as cv=pass because the algorithm never inspects RCPT TO.

DKIM2 makes replay structurally hard at the protocol layer. Every DKIM2-Signature carries mf=, rt=, and a Unix-time t=. The verifier checks the topmost rt= against the live RCPT TO of the inbound SMTP transaction and PERMFAILs on mismatch (spec §10.4). It also MAY PERMFAIL any signature whose timestamp is older than 14 days (§10.3). A captured DKIM2 message re-injected to a new recipient fails at the verifier without any reputation system involved.

Today’s operator mitigations — Google’s “DKIM replay” Postmaster Tools guidance plus the DKIM x= expiration tag, Microsoft’s tenant-scoped trusted-sealer list configured through Set-ArcConfig — sit on top of the ARC model. DKIM2 attempts to make them unnecessary.

Originator DKIM key rotation between send and forward

ARC captures, at receive time, the authentication results each sealer observed and writes them into the AAR for its instance. The AS at the same instance signs over that AAR. Downstream validators verify the most recent AMS and every AS — they never re-fetch the originator’s selector. So if the originator rotates between send and forward, the chain still validates. The trust shift is that the validator now trusts “the i=1 sealer attested the originator passed DKIM” rather than “the originator’s DKIM signature is verifiable now.”

DKIM2 keeps each hop’s signature independently verifiable: each DKIM2-Signature is checked against the public key fetched via that header’s own selector under that header’s own domain. The originator’s safe-rotation tool is the DKIM1 selector mechanism, unchanged (spec §3.5). Operational guidance in draft-herr-dkim2-bcp-01 §4.4 is to keep superseded selector keys live for at least two weeks — matching the 14-day staleness ceiling. Compared with ARC, DKIM2 keeps the originator’s signature cryptographically re-verifiable downstream rather than collapsing it into a textual assertion.

Three-hop forwarder chain

The everyday corporate scenario — user posts to a mailing list, list re-distributes to a subscriber, subscriber’s gateway delivers to the mailbox — is where the protocols differ most visibly. ARC adds three triplets sharing a contiguous instance-number sequence. DKIM2 adds three DKIM2-Signature headers and, when a hop modifies content, one Message-Instance recipe.

What each hop signs over differs in kind, not just notation. The ARC AMS covers headers, body, and pre-existing DKIM-Signatures; the AS covers all AAR/AMS/AS in strict order (RFC 8617 §4.1.2, §5.1.1). The DKIM2-Signature covers all Message-Instance and prior DKIM2-Signature headers in canonical order plus its own incomplete signature header (spec §8.5). Modifications are recorded as reversible recipes inside Message-Instance, so a verifier can walk the chain in reverse and re-verify each prior hop’s hashes.

What breaks each chain also differs. For ARC: missing or duplicate AAR/AMS/AS, instance gaps, the wrong cv= value, or the latest AMS failing — though an older AMS that fails because the list mangled the body does not by itself break the chain. For DKIM2: any hop’s mf= not aligning with the previous hop’s rt=, an expired t=, the topmost rt= not matching the live RCPT TO, or a signature failing on any hop the verifier elects to recompute. The DKIM2 verifier ends with cryptographic confirmation of every hop. The ARC verifier ends with a transcript of assertions.

For a deeper walk of how forwarded mail breaks DMARC today under RFC 8617, including the ARC chain validation walkthrough for the three-hop case, see our companion explainers.

ARC’s quiet runway to Historic at the IETF

The DMARC Working Group was rechartered on 16 April 2026 with one milestone and one milestone only: “Nov 2026 — Request approval of a status-change document moving ARC to Historic.” The rechartering rationale on the WG About page is unusually direct: the working group “is being chartered (again) to find consensus on a document that changes RFC 8617 to historical status.” If the WG misses October 2026, it closes. There is no other deliverable.

The vehicle began as an individual submission. Trent Adams (Proofpoint) and John Levine (Taughannock Networks) posted draft-adams-arc-experiment-conclusion-01 on 4 December 2025; it expires 7 June 2026. Six days after the IESG recharter, on 22 April 2026, the WG draft draft-ietf-dmarc-arc-to-historic-00 was posted. There was no standalone Call for Adoption — the rechartering itself functioned as the adoption marker. Both vehicles — draft-adams-arc-experiment-conclusion-01 (the individual submission) and draft-ietf-dmarc-arc-to-historic-00 (the WG-adopted successor, 2026-04-22) — remain valid references; an admin tracking the timeline should bookmark the WG draft for forward motion and keep the individual submission for archival rationale.

The working-group voices line up clearly. For moving RFC 8617 to Historic: Trent Adams, who kicked off the recharter thread on 30 January 2026 hoping to close the experiment after a decade of operational experience; Seth Blank (Valimail and DMARC co-chair), saying on 1 February 2026 he was “more comfortable now moving ARC to obsolete/historic prior to a successor like DKIM2 being published”; Alex Brotman (Comcast) the next day; and Murray Kucherawy, RFC 8617 co-editor, on 9 February 2026, arguing the industry “would actually benefit from an assertion, in the form of an RFC, that there’s nothing left of value down that road.”

Urging caution: Douglas Foster, who warned the proposed language “presupposes a consensus that has not been established through any IETF process”; Jeroen Massar (a PGP-remailer operator), asking the WG to leave RFC 8617 in place until DKIM2 marks it Historic; and Alessandro Vesely on 9 February 2026.

The conspicuous silence is the operator side. A search of the dmarc list archive from December 2025 through April 2026 surfaces no posts from @google.com, @microsoft.com, @yahooinc.com, @fastmailteam.com, @proton.me, or @apple.com stating a date for stopping ARC honoring. The largest ARC implementers have not put a date on the table. The standards signal that “ARC is over” will not be authoritative until the IESG approves the status-change document, realistic earliest in Q1 2027 — and even then, the IETF action is reclassification, not deprecation. It imposes no date on operators.

For an admin reading this in 2026: ARC is a local policy choice with a fading endorsement, not a deprecated protocol. Watch the dmarc list for the WG Last Call announcement, likely in Q3 2026, as the first real signal that operators can begin staging deprecation plans. The full vehicle lives at draft-ietf-dmarc-arc-to-historic.

The 2026-2027 transition timeline

DKIM2, ARC reclassification, and the DMARCbis cluster move on three tracks that touch each other only at the IETF document level. The single canonical view, ordered by realistic earliest action, is below.

The DMARCbis cluster sits in the RFC Editor’s EDIT state, gated by IANA author actions on the failure-reporting draft rather than queue depth. Once those actions clear, all three drafts publish together. DMARCbis obsoletes RFC 7489 and (if approved) RFC 9091, retiring the 2015 Informational DMARC base spec and folding the 2021 Experimental PSD extension into the new core.

The five sender-side changes admins should plan for, sourced from draft-ietf-dmarc-dmarcbis-41:

• pct= tag removed (Appendix A.6). Phased rollouts must use t=y test mode plus per-subdomain policy management. Senders lose the partial-deployment dial entirely.
• np= tag added (Section 4.7) for non-existent-subdomain policy. Domain owners can declare np=reject to harden the NXDOMAIN spoofing vector.
• t=y test-mode redefined (Section 4.7 with rationale in Appendix A.6). When set, receivers SHOULD apply policy one level lower than declared (reject becomes quarantine, quarantine becomes none).
• DNS Tree Walk replaces the Public Suffix List (Section 4.10). Receivers perform up to 8 DNS queries walking the namespace upward looking for a DMARC record carrying psd=y/n, eliminating the dependency on publicsuffix.org. Senders with deep-label sending domains must publish an explicit DMARC record at the Author Domain.
• psd= tag for Public Suffix Domains (Section 4.7, consumed by Section 4.10). Public Suffix Operators publish psd=y; large decentralized organizations may use psd=n.

For our point-in-time view of how these changes interact with current adoption, our 2026 scan of email authentication adoption includes the receivers and senders most affected by the Tree Walk change.

What email admins should actually do in 2026

The architectural narrative is satisfying, but the operational answer is shorter than the narrative suggests. As of May 2026, six concrete actions are defensible.

1. Treat ARC as a local policy choice, not a deprecated protocol. It will remain live at Google, Microsoft, and Yahoo well into 2027. Honoring ARC seals from trusted forwarders is still the right answer for forwarded mail today.
2. Run a baseline ARC chain audit now. If forwarded mail is failing today, fix it under the existing model. The transition timeline does not change anything about how ARC behaves between now and Q1 2027.
3. Track the failure-reporting IANA author-action item on draft-ietf-dmarc-failure-reporting. It is the single critical path for the entire DMARCbis cluster.
4. Do not deploy DKIM2 in production yet. No operator signs DKIM2 today. The IETF 124 hackathon report from November 2025 stated that specifications “were woefully incomplete for actual implementation,” and the WG -01 spec is the first revision shaped by hackathon feedback.
5. Keep DKIM1 selector keys live for at least two weeks after rotation regardless of DKIM2 status. This is the operational discipline DKIM2 will codify, but it improves your DKIM1 deliverability today.
6. Bookmark the four watchlist drafts. failure-reporting, aggregate-reporting, dmarcbis, and arc-to-historic are the four documents whose status changes in the next eighteen months will move the floor under every email administrator. You can also check your current DKIM record against RFC 6376 at any time.

The contrast dkim2 vs dkim is worth stating once. DKIM (RFC 6376, 2011) signs the originating message once and has a known replay weakness. DKIM2 signs every hop, indexes signatures with i=, binds the SMTP envelope via mf=/rt=, and rejects signatures older than 14 days. DKIM2 is a parallel-track successor; coexistence is the rule until the IETF says otherwise.

FAQ

What is DKIM2?

DKIM2 is an IETF Standards-Track Internet-Draft (draft-ietf-dkim-dkim2-spec-01, 20 April 2026) that proposes a per-hop chained-signature successor to RFC 6376 (DKIM) and RFC 8617 (ARC). Each forwarder adds its own DKIM2-Signature header binding MAIL FROM and RCPT TO, making replay attacks structurally harder.

What is the difference between DKIM and DKIM2?

DKIM (RFC 6376, 2011) signs the originating message once and inherits a known replay weakness. DKIM2 (draft-ietf-dkim-dkim2-spec-01, 2026) signs every hop, indexes signatures with i=, binds the SMTP envelope into each signature via mf=/rt=, and rejects signatures older than 14 days. DKIM2 is a parallel-track successor — neither current draft formally obsoletes RFC 6376.

Is ARC being deprecated?

Yes, formally — but slowly. The IETF DMARC Working Group was rechartered on 16 April 2026 for the sole purpose of moving RFC 8617 to Historic. The WG’s milestone is November 2026. Realistic earliest reclassification is Q1 2027. No mailbox provider has committed to a sunset date as of April 2026.

Is Microsoft’s “DKIM2” the same thing?

No. In Azure Communication Services, “DKIM2” is a UI label for the second DNS selector record (selector2._domainkey) used for zero-downtime key rotation. Microsoft’s Exchange and Defender documentation never uses the string. The IETF DKIM2 protocol is unrelated to either selector slot.

When can I deploy DKIM2 in production?

Not yet. As of April 2026, no operator signs DKIM2 — the IETF 124 hackathon report (November 2025) explicitly stated specifications “were woefully incomplete for actual implementation.” First production deployments are realistic in 2026 H2 to 2027. Track draft-ietf-dkim-dkim2-spec revisions and the dkim WG mailing list for movement.

Will DKIM2 require new DNS records?

No new RR type. draft-chuang-dkim2-dns-04 §3.4.2 commits DKIM2 to TXT-based keys under the existing _domainkey namespace from RFC 6376 — the same DNS records you publish for DKIM today. Selector mechanics carry over unchanged.

Conclusion

Five things stand out from the full DKIM2 record. DKIM2 is real, WG-adopted, and incomplete. Its architectural spine — per-hop chained signatures, envelope binding, the 14-day timestamp window — is locked in. Encoding details, header recipe numbering, and the rt= data-leakage objections are still moving on the ietf-dkim list. ARC is on a quiet runway to Historic, but no operator has named a sunset date. Email admins in 2026 should run a baseline ARC chain audit, track the DMARCbis failure-reporting block, and bookmark the four watchlist drafts.

DMARCguard reads every RFC and every draft. When the SERP fills with rushed DKIM2 coverage in late 2026 and 2027, this page remains the source that cites all five active drafts by name, separates settled commitments from contested questions, and tells admins what to do — not just what the IETF announced. Inspect any ARC chain in seconds — run the ARC chain analyzer — and start monitoring DMARC across all 9 protocols on the free plan, no credit card required.