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

On 28 August 2026, the IETF DKIM Working Group posted draft-ietf-dkim-dkim2-spec-06, the seventh working-group posting (-00 through -06) of the DKIM2 specification since the adoption call closed on 16 March 2026. In between, the working group adopted the DNS and best-practices companions, an interop test matrix ran at the IETF 126 hackathon, and on 10 September 2026 Google’s Wei Chuang posted an individual draft that would wire DKIM2 into the DMARC record itself. On 29 September Fastmail’s Bron Gondwana sent the list a message that “was DKIM2 signed on the way out from Fastmail.” On the other track, the IESG rechartered the DMARC Working Group on 16 April 2026 for the sole purpose of moving RFC 8617 (ARC) to Historic — and that group’s charter runs out on 16 October 2026 with no Working Group Last Call issued and its own chair’s consensus call unresolved.

This article reads all eight active DKIM2 drafts (three working-group documents and five individual submissions), the ones that expired along the way, 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 mid-2027. DKIM2 is the term the spec, the motivation document, and every supporting draft use — the IETF chose it to mark a generational break from RFC 6376, and it is where the future of email authentication is being negotiated.

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 (now expired) explicitly noted that the literal string DKIM2-Signature was a placeholder; six working-group revisions later the name has not moved, and 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 pair is a DNS setup step 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-06 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 active DKIM2 drafts

The DKIM working group now carries three live documents — the spec, the DNS key specification, and the best-practices guide — while the motivation document that started the work has expired. Five individual submissions circle the core: a milter deployment profile, an Authentication-Results method registration, a localized-header extension, the sender-policy draft that reaches into DMARC, and a debug-header note written for the people testing implementations. Here is every draft with current standing, plus the dead and expired ones most often cited, with datatracker status flagged exactly.

Four notes on the table. Counting: eight drafts are active — rows 1 to 3 are working-group documents, rows 5 to 9 are individual submissions with no formal standing. Row 9 defines an X-DKIM2-Info header that implementations add while interop testing; its introduction says “Nothing in this document is normative,” and it changes nothing an administrator configures. Two more individual drafts, Allen Robinson’s bounce processing (-01) and R. Latimer’s recipient and next-domain signing (-00), expired in January and May 2026 and are not listed. 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 July 2025 (the working-group filename appeared 25 July 2025) and has been expired since 7 May 2026; the spec adoption call closed on 16 March 2026, and revision -06 of 28 August 2026 is the sixth revision since -00 of 24 March 2026. The DNS and best-practices adoption calls were resolved at the 17 June 2026 interim; the working-group filenames appeared on 18 June (BCP) and 20 July (DNS). 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-spec
• draft-ietf-dkim-dkim2-dns
• draft-ietf-dkim-dkim2-bcp
• draft-ietf-dkim-dkim2-motivation
• draft-moccia-dkim2-deployment-profile
• draft-chuang-dkim2-localized-header-fields
• draft-gondwana-dkim2-authres
• draft-chuang-dkim2-sender-policy
• draft-gondwana-dkim2-debug-header
• 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 has held across every working-group revision, but four encoding and ordering questions — and, since August 2026, one architectural question about DMARC — 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 “assists validators in distinguishing between messages that were intended to be sent to a particular email address and those that are being ‘replayed’ to that address” (draft-ietf-dkim-dkim2-spec-06 §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 §8.5–8.6 and §9.2). Revision -03 added the one exception: a hop that hands a message between domains inside the same system may carry an nd= tag naming the next signing domain instead of mf=/rt=, but any such run MUST end with a signature that carries both (§8.7).
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 §8.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 §11.3, motivation §3.1).
5. DNS reuse, not a new RR type. TXT records under the _domainkey namespace from RFC 6376 are reused; no new DNS resource-record type is introduced (draft-ietf-dkim-dkim2-dns-00 §3.4.2.1–3.4.2.2). The spec says it outright: the keys “are no different, and are stored in the same locations as those for DKIM1” (spec §3.6).

The five contested questions (still moving)

The ietf-dkim list since September 2025 has produced four cleanly verified two-party disputes over encoding and ordering, and since August 2026 a fifth that is architectural. 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) registered a preference for top-down on 17 March 2026, so that hashing and recipe execution stay consistent, while agreeing the draft as written means bottom-up.

Signing-input ordering — interleaved versus all-then-all. Gondwana, in his 14 March 2026 hackathon day-one report (which he notes was generated with help from Claude Code), 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 for the signature tags: the first working-group revision, draft-ietf-dkim-dkim2-spec-00 (24 March 2026), records in its change log that it “Removed JSON for hashes, signatures and SMTP parameters.” JSON survives inside Message-Instance recipes, and that is where the argument moved: on 8–17 September 2026 the list reopened it under the subject “base64+JSON on the critical path,” with Vittorio Moccia, Bron Gondwana, and Hannah Stern all posting. Still moving.

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. The working group’s answer so far is operational, not structural: draft-ietf-dkim-dkim2-bcp-01 §5.4 concedes that a forwarder relaying to a subscriber’s real address “will, as a side effect, expose that address” through rt=, and says such forwarders SHOULD deliver to “a per-subscriber, per-forward alias local part” instead. The tag stays; the mitigation moves to the BCP.

Where DKIM2 policy lives — in the DMARC record, or nowhere yet. This one is structural, and the working group had already declined to settle it: the IETF 126 minutes of 24 July 2026 record that the core spec “will remain silent on From alignment,” with guidance going into the BCP “and perhaps make updates to DMARC,” and the BCP itself (-01 §7.7) calls the question of where policy should live “an open architectural question that this document does not attempt to resolve.”

Wei Chuang forced it on 26 August 2026 with a list proposal to split per-message constraints (DKIM2 signature flags) from domain-level enforcement (the DMARC record). Todd Herr, author of the DKIM2 BCP, replied within hours that “Unless and until there’s an updated RFC 9989 published that acknowledges DKIM2 as an Authenticated Identifier, there is no world where DMARC alignment validation is applied corresponding to a DKIM2 signature.” John Levine, on the same thread on 2 September, agreed the policy work belongs in a separate draft but called the proposed unaligned flag redundant, since a receiver can compare d= to the From: domain itself. On 10 September Chuang posted the proposal as draft-chuang-dkim2-sender-policy-00 and revised it three times in the next eleven days; the sender-policy section below walks through the current -03.

The argument has since split in two. One half is moving toward the spec. Richard Clayton’s proposal that a From: domain must match the d= of the signature added when that From: was introduced or changed drew support on 17 September from Tobias Herkula (1&1 Mail & Media), who wants it “added directly to the DKIM2 specification,” and from Herr, who backed language saying “the DKIM2 signing domain MUST match the RFC5322.From domain whenever the domain is introduced or changed in a message.” “From header field authentication” was the first technical item on the agenda of the working group’s 23 September interim. The other half, DMARC itself, is where Herr still objects. In the same message he wrote that “adding DKIM2 as an authentication mechanism for DMARC will slow, rather than accelerate, adoption of DKIM2, because a DMARC pass will still be achievable with just SPF, or just DKIM.” No spec revision carries the From match yet; -06 is still current.

Who is championing DKIM2

Five named voices carry the public record.

Bron Gondwana (Fastmail) is the lead motivator. On the ietf-dkim list, 19 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 most prolific individual contributor: sole author of the WG-adopted DNS draft, the localized-header-fields draft, and the sender-policy draft, and a co-author of the spec and the motivation document. 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 with an update for more modern algorithms.”

Allen Robinson (Google) co-authored the now-expired message-examples draft. On the ietf-dkim list, 23 March 2025: DKIM2’s “two independent headers” mean DKIM1 verifiers “would observe no change.” At IETF 126 he argued for requiring From alignment at the first hop and for DMARC to recognize DKIM2.

Todd Herr (GreenArrow Email) authors the WG-adopted best-practices draft and holds the line on DMARC formality: DKIM2 cannot feed DMARC alignment until RFC 9989 §4.3 lists it as an authentication mechanism. His BCP (-01 §7.2) states that “Whether or not DMARC will be updated to include DKIM2 as an Authentication Mechanism is an open question at this time.”

The DKIM working group charter permits — but does not mandate — “a technology which supersedes existing technologies such as DKIM, DMARC, and ARC.”

DKIM2 vs ARC: how they differ under three real-world scenarios

The email authentication 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 MUST check the topmost mf=/rt= against the live MAIL FROM and RCPT TO of the inbound SMTP transaction and returns a PERMERROR on mismatch (spec §11.4). It SHOULD fail any signature whose timestamp is more than 14 days old (§11.3), and revision -06 added a further check: multiple copies of the same message arriving with no exploded flag SHOULD all be rejected as replay (§11.9). A captured DKIM2 message re-injected to a new recipient fails at the verifier without any reputation system involved. (Earlier revisions, and our May version of this page, said “PERMFAIL”; the -06 change log notes it “Corrected mentions of non-existent PERMFAIL” — the four output states are PASS, FAIL, PERMERROR, and TEMPERROR, §11.1.)

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 DKIM and ARC models. 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-ietf-dkim-dkim2-bcp-01 §3.5 is to publish new keys under a new selector rather than overwriting an existing one, “so that messages signed with the outgoing key continue to verify correctly until they have finished transiting the mail system,” and never to reuse a retired selector name. The BCP does not put a number of days on how long the old selector must stay published (our May version wrongly said it did); the outer bound is the spec’s 14-day timestamp window (§11.3), which BCP §3.6 restates. 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 §9.6). 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.

The DKIM2 sender-policy draft: what a DMARC auth= tag would change

On 10 September 2026 Wei Chuang posted draft-chuang-dkim2-sender-policy, titled “DKIM2 Sender Policy,” and revised it three times in eleven days: -01 on 12 September, -02 on 20 September, -03 on 21 September. Its boilerplate declares the Independent Stream and an intended status of Experimental; the datatracker lists it under Individual Submissions. It has not been adopted by the DKIM or the DMARC working group. It is the first draft to spell out how RFC 9989 and DKIM2’s forwarding model would fit together, and it makes four changes to DMARC plus one to DKIM2. Section numbers below are those of -03; -00 numbered everything under §1.

1. A new auth= tag in the DMARC record (§2.2.1). A comma-separated list of the authentication methods a domain supports “as both a SMTP MTA sender and receiver”: dkim, dkim2, spf. The tag is “completely optional”; if absent, “relying parties MAY assume that both DKIM and SPF are supported,” and DKIM2 is never assumed. The draft explicitly allows a domain to support DKIM2 without publishing the tag “during the bring-up period.” Since -02 it also says what a declared method buys: if a message arrives without it, “the mail receiver SHOULD apply the sender’s enforcement policy.”
2. The Author Domain comes from i=1 (§2.1). Because DKIM2 forwarders may rewrite From:, receivers SHOULD use the From: recovered at the first signature — the RFC 5598 author — rather than the newest one. Up to -01 the draft required that “the entire chain of custody MUST be successfully validated” to do so, and let local policy fall back to the From: at the highest i=. From -02 the MUST is a SHOULD and the fallback is gone; Chuang told the list on 19 September he would “remove support for i=n.”
3. DKIM2 becomes a DMARC authentication method (§2 and §2.2.2). Since -01 the draft says outright that it modifies RFC 9989 §4.3 to add DKIM2. A validated chain of custody is a DMARC “pass”; DKIM2 headers present but the chain not validating is “fail”; no DKIM2 headers is “neutral.” Alignment is relaxed, between the Author Domain and the d= of the Originator’s signature at i=1 (citing spec §9.4 and RFC 9989 §3.2.10.1), and is checked only on signatures that carry rt=/mf=, not on nd= ones.
4. p= and sp= are generalized (§2.1). Same values — reject, quarantine, none — but applied “for any failing domain owner’s constraint/validation subject to local policy, and not just for alignment.”
5. Per-message policy moves into DKIM2 signature flags (§3). donotmodify and donotexplode are constraints on downstream relays; exploded and a newly introduced unaligned flag are reports. A receiver that will not honor a constraint “MUST NOT relay the message outside of its control.” feedback and feedhere are marked “TBD.”

The practical piece is §3.3, the DKIM-only-hop story. A DKIM2 relay checks the next hop’s auth=; if the receiver is not DKIM2-capable it can bounce, strip the DKIM2 headers, or terminate the chain of custody by publishing an rt= tag with no addresses. Downstream DKIM2 receivers then know the recipient comparison “is unnecessary” and can apply anti-replay rules deterministically, while donotmodify and donotexplode survive the legacy hop. That mechanism is already contested: Bron Gondwana wrote on 1 October that he had disagreed with it at the 23 September interim, and proposed the opposite arrangement, in which the sender “does nothing special” and the final receiver looks up a DNS record on the intermediate’s domain to tell a legacy hop from a replay.

Five things an admin should weigh before treating this as a roadmap:

• No Security Considerations and no IANA Considerations sections. At -03 the document has five numbered sections — Introduction, the modifications to DMARC, to DKIM2 and to best current practices, and Normative References — and neither of those two. For a draft whose pitch is downgrade resistance, and which mints a new DMARC tag that would need IANA registration, both omissions are notable — and both are required before any IETF stream would publish it. In fairness, the core spec’s own IANA and Security sections (§15, §16) still read “TBA” at -06.
• auth= only protects domains that opt in. Absence means “assume DKIM and SPF,” so a man-in-the-middle stripping DKIM2 from a domain that never published the tag is still invisible. The draft blesses that gap for the bring-up period.
• The i=1 preference has a deliverability cost the draft does not analyze. With the fallback to the newest From: removed, one broken link anywhere in the chain makes the DKIM2 result “fail” (§2.2.2).
• Two of the flags it builds on may not survive. Richard Clayton, the spec’s lead author, wrote on 20 September that “a strong case has been made” for removing donotexplode, and on 26 September that there is “a strong case for removing ‘donotmodify’ from the DKIM2 spec itself” in favor of a separate header. Gondwana, who had defended donotmodify with an invoice-fraud example, replied on 1 October that “removing it from DKIM2 seems right to me.” Tobias Herkula has asked for a rough consensus call; none has been issued.
• Three revisions in, it is still rough. The donotmodify validation text tells receivers to check for modification “after the donotexplode” (§3.2.3), one example uses an f=reporting flag the draft never defines (§4.2.2), another contains the truncated sentence “The intermediate relay also does not .” (§4.2.3), and the “without an intermediates” example shows a d=forwarder.example signature (§4.2.1). The running page header that read “Local Headers” through -02, inherited from Chuang’s localized-header draft, is fixed.

Where the working groups stand: the DKIM WG has scoped DMARC changes out of the core spec (IETF 126 minutes), and the DMARC WG’s current charter says it “will adopt no other documents or work items” beyond ARC-to-Historic. On the list the draft has been engaged with rather than dismissed. Todd Herr’s 10 September objection — “unless section 4.3 in RFC 9989 is updated, I don’t see how DMARC alignment can be checked with DKIM2” — was met two days later in -01, whose acknowledgements thank him “for clarifying how to update RFC9989.” Richard Clayton, after questioning the tag, concluded on 16 September that “the DMARC record is exactly the place to put auth=dkim2.” Herr’s remaining objection is strategic (quoted above), and Chuang has floated splitting the document in three, with two parts absorbed into the adopted DKIM2 drafts and only the RFC 9989 update “potentially introduced to the DMARC WG.” “Modifying DMARC to support DKIM2” was an agenda item at the DKIM WG’s 23 September interim. The draft is a watchlist item, not a plan.

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.” The charter (charter-ietf-dmarc-04) also sets a hard clock: the task “is to be completed no later than six months from working group rechartering. If this working group fails to meet this deadline, the group will close at that time.” Six months from 16 April 2026 is 16 October 2026. 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; the datatracker now marks it Replaced. 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. That -00 is still the only revision. It carries “Obsoletes: 8617 (if approved)” with an intended status of Informational, and it expires on 24 October 2026 — eight days after the charter deadline.

The working-group voices lined up clearly at the start. 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), who did not oppose the move but asked for a documented exit plan and a provider turn-off timeline before ARC is shuttered; and Alessandro Vesely on 9 February 2026.

Then the chair tested consensus, and it did not hold. On 3 July 2026 Barry Leiba, as chair, asked anyone opposed to making ARC Historic to say why, concisely, by 17 July. The decisive objection came within the hour from Seth Blank — comfortable moving first back in February, now posting as a participant rather than chair (the WG page lists Leiba as sole chair): “I think we should NOT make ARC historic, yet,” because “ARC is actively deployed and utilized” and “No interoperable replacement is yet published.” DKIM2, in his view, “should obsolete / make ARC historic when it publishes, so there’s a clear upgrade path.”

That objection became the bar. On 18 July Leiba wrote that “we seem to have clear consensus on Seth’s objection, among those objecting,” asked proponents to answer it with data — “That probably means that we need to hear from some of the major email services” — and set 7 August as the date to “see where we are.” The proponents’ case did not change: Murray Kucherawy found it “curious that consensus appears to have swung towards ‘do nothing’ when, during chartering … consensus was clearly ‘Trent’s right, we should do this’,” and Trent Adams answered on 20 July that ARC is deployed “but not for what it was intended” — “only the last hop signature appears to be utilized to any measurable extent with all earlier signed hops being ignored” — while pointing to “at least three interoperable implementations” of the DKIM2 drafts.

Two operators answered the chair’s request for data, and both answered against ARC. Comcast’s Alex Brotman replied on 20 July: “While others have found value in ARC, I found the opposite.” Then on 30 July 2026 Richard Clayton relayed an official Yahoo statement to the list. Yahoo does not seal: “We have not been applying ARC headers to any email and we will not be doing so in the future.” Trusting other people’s seals made things worse: accepting ARC “has DECREASED our ability to identify email that our users do not wish to receive,” it has taken “several large senders” off its trusted list, and it “will not be spending any effort in adding any new senders to our (now extremely short) list.” Adoption is thin: “about 12,000 users of ARC — which may sound a lot but it is rather less than half of one percent of the domains sending us email each day.” Its advice to senders is to “engage with the DKIM2 initiative” instead.

Earlier in the thread, on 6 July, Internet Initiative Japan (“It is too early to make ARC Historic at this point”) and Zone.ee (“We use it in a limited scope with good results”) had argued to keep it. No statement from Google or Microsoft has appeared on the list, the 7 August checkpoint passed without a chair determination being posted, the August threads (“ARC for internal use,” “Whose reputation matters in an ARC chain?”) were still arguing the merits, and the DMARC WG held no session at IETF 126.

In May we wrote that admins should “watch the dmarc list for the WG Last Call announcement, likely in Q3 2026.” It did not come. The quarter closed on 30 September with no Working Group Last Call and no revised draft; the dmarc list carried one message in the whole of September, an RFC 9989 erratum notice. The charter closes the group on 16 October 2026 if the task is not done. Two outcomes are live: the chair declares rough consensus and the document moves before 16 October, or the group closes and RFC 8617 stays Experimental until DKIM2 — or a future recharter — takes it up. Either way the IETF action, if it comes, is reclassification, not deprecation. It imposes no date on operators.

For an admin today: ARC is a local policy choice with a fading endorsement, not a deprecated protocol — and one major mailbox provider has now said in writing that it neither seals with ARC nor trusts it much. 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 how soon each item can change your configuration, is below.

The DKIM WG’s own four charter milestones — the last, “All documents submitted to the IESG,” was due 31 December 2025 — are all past due and none is marked resolved on the datatracker. The virtual interim the chairs promised at IETF 126 was held on 23 September 2026, a second is scheduled for 21 October, and the chairs have requested a session at IETF 127.

The DMARCbis cluster published as RFC 9989, 9990, and 9991 in May 2026 — promoting DMARC from Informational to Proposed Standard for the first time. RFC 9989 obsoletes RFC 7489 and RFC 9091, retiring the 2015 Informational DMARC base spec and folding the 2021 Experimental PSD extension into the new core. See our day-one DMARCbis analysis for the full mapping.

The five sender-side changes admins should plan for, sourced from RFC 9989:

• 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, the Domain Owner is asking receivers to apply policy one level lower than declared (reject becomes quarantine, quarantine becomes none) — a request, not a SHOULD.
• 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.

One post-9989 tag proposal exists in the wild — auth=, from the unadopted individual draft covered in the sender-policy section above — and RFC 9989 §4.8 (“Unknown tags MUST be ignored”) is why publishing it today changes nothing at any receiver.

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. Six concrete actions are defensible.

1. Treat ARC as a local policy choice, not a deprecated protocol. Microsoft still documents an admin-managed trusted-sealer list (Set-ArcConfig). Google still publishes a help page explaining ARC, but gives Workspace admins no ARC setting, and its sender guidelines no longer mention ARC. Yahoo has said it does not seal and keeps its trusted-sealer list “extremely short.” Honoring ARC seals from forwarders you trust is still the right answer for forwarded mail today — and Yahoo’s experience is the argument for keeping that list short.
2. Run a baseline ARC chain audit now. If forwarded mail is failing today, fix it under the existing model. Reclassification changes a document’s status, not the protocol — nothing in the IETF process changes how ARC is evaluated at your receivers.
3. Do not publish an auth= tag in your DMARC record. It exists only in draft-chuang-dkim2-sender-policy, an unadopted individual draft with no IANA section that was revised three times in its first eleven days. Receivers ignore it today, and if the draft changes its syntax a published record becomes a stale commitment.
4. Do not deploy DKIM2 in production yet. The IETF 124 hackathon report from November 2025 stated that specifications “were woefully incomplete for actual implementation.” By IETF 126 (July 2026) the minutes record Go and Rust implementations being cross-tested in a Docker matrix, with a weekly interop call. Fastmail went further on 29 September 2026: it signs outbound mail for “a handful of domains” and validates DKIM2 inbound for all its customers, using the Perl library from the interop repository. Asked on the list whether the format is stable enough for that, its CEO and spec co-author Bron Gondwana answered “Meh, code can be changed.” One provider that writes the spec running it is not the format settling: the spec has been revised six times since the March adoption call, and the list is still debating which flags stay in it.
5. Rotate DKIM keys by adding a selector, never by overwriting one. draft-ietf-dkim-dkim2-bcp-01 §3.5 asks signers to publish new keys under a new selector, keep the outgoing key resolvable until in-flight mail has cleared, and never reuse a retired selector name. That is DKIM1 discipline too, and it improves your deliverability today.
6. Bookmark the five watchlist drafts. arc-to-historic, dkim2-spec, dkim2-bcp, dkim2-dns, and sender-policy are the five 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 its verifiers SHOULD fail 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-06, 28 August 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-06, 2026) signs every hop, indexes signatures with i=, binds the SMTP envelope into each signature via mf= and rt=, and verifiers SHOULD fail signatures older than 14 days. DKIM2 is a parallel-track successor — no current draft formally obsoletes RFC 6376.

Is ARC being deprecated?

Formally proposed, not decided. The IETF DMARC Working Group was rechartered on 16 April 2026 solely to move RFC 8617 to Historic, with a six-month charter deadline of 16 October 2026. There is no Working Group Last Call, the chair’s July consensus call stalled, and Yahoo has stated it does not apply ARC seals. No mailbox provider has committed to a date for ceasing to honor ARC.

Is Microsoft’s DKIM2 the same thing?

No. In Azure Communication Services, DKIM2 is the UI label for the second of two DKIM selector CNAME records the service asks you to publish (selector2-azurecomm-prod-net._domainkey). 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. The IETF 126 minutes (24 July 2026) record Go implementations from Bron Gondwana and Steve Atkins and a Rust implementation in the mail-auth library and Stalwart server being cross-tested in a Docker matrix. On 29 September 2026 Fastmail told the ietf-dkim list that it now signs outbound mail with DKIM2 for a handful of domains and validates DKIM2 on inbound mail for all its customers; it is the only mailbox provider to have said so on the list. The spec is still changing (revision -06, 28 August 2026) and the DKIM WG’s own milestones (last due 31 December 2025) are past due. Track draft-ietf-dkim-dkim2-spec revisions and the dkim WG mailing list for movement.

Will DKIM2 require new DNS records?

No new resource record type for keys. The WG-adopted draft-ietf-dkim-dkim2-dns-00 §3.4.2 keeps DKIM2 keys in TXT records under the existing _domainkey namespace from RFC 6376, and spec-06 §3.6 says the keys are no different from DKIM1’s. The only new DNS proposal in any draft is an optional auth= tag in your existing _dmarc record, from the unadopted individual draft draft-chuang-dkim2-sender-policy. Do not publish it yet.

What is the proposed DKIM2 auth= tag in DMARC?

A proposal in draft-chuang-dkim2-sender-policy (first posted 10 September 2026, revised to -03 on 21 September; individual submission, intended status Experimental) to add an optional auth= tag to the DMARC record listing the authentication methods a domain supports as sender and receiver: dkim, dkim2, spf. If the tag is absent, receivers may assume DKIM and SPF. It is not in RFC 9989, has no IANA registration, and is not adopted by any working group. RFC 9989 §4.8 makes receivers ignore unknown tags, so publishing it today changes nothing.

Conclusion

Five things stand out from the full DKIM2 record. DKIM2 is real, WG-adopted, signed on live mail at one provider, and still moving — six working-group revisions in five months — and it is where email authentication is heading, not yet where it is. Its architectural spine — per-hop chained signatures, envelope binding, the 14-day timestamp window — has held through all of them. Encoding details, header recipe numbering, the rt= data-leakage objections, and now whether DKIM2 policy belongs in the DMARC record at all are still open on the ietf-dkim list. ARC’s runway to Historic has stalled at the consensus stage with the DMARC WG’s charter running out on 16 October 2026, and Yahoo has said in writing that it neither seals with ARC nor trusts it much. Email admins in 2026 should run a baseline ARC chain audit, leave auth= out of their DMARC record, and bookmark the five watchlist drafts.

We read every RFC and every draft as it posts, and we update this page when the record changes. It cites every active draft 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 7 protocols free (all 9 on Pro), no credit card required.

---

Related Posts

Apr 29, 2026 19 min read

ARC Email Authentication: Forwarded Mail in 2026

ARC email authentication carries SPF, DKIM, and DMARC verdicts across forwarding hops. Real headers, cv=fail debugging, trusted-sealer fixes, IETF status.

arcemail-authenticationdmarc

Mar 13, 2026 21 min read

DKIM Fail: How to Fix Alignment and Verification Errors

DKIM failing? Learn why DKIM alignment breaks, how to fix body hash errors, and how to configure third-party senders. Step-by-step guide with CLI commands.

dkimtroubleshootingemail-authentication

Jul 9, 2026 15 min read

How to Set Up DKIM: Selectors, Keys & Records (2026)

Set up DKIM the right way: how signing works, choosing 2048-bit keys, finding your selector, and publishing the record. A 2026 guide — check yours free.

dkimdkim-recordselector

Feb 25, 2026 31 min read

DMARC Fail: 7 Causes & How to Fix Each (2026 Guide)

DMARC failed? Fix it fast: 7 causes (SPF/DKIM misalignment, third-party senders, forwarding) with diagnose steps, fixes, and a free DMARC checker.

dmarctroubleshootingemail-authentication