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 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 is now five weeks from its charter deadline with no Working Group Last Call issued and its own chair’s consensus call unresolved.

This article reads all seven active DKIM2 drafts (three working-group documents and four 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 (September 2026)

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. Four individual submissions circle the core: a milter deployment profile, an Authentication-Results method registration, a localized-header extension, and the sender-policy draft that reaches into DMARC. 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: seven drafts are active — rows 1 to 3 are working-group documents, rows 5 to 8 are individual submissions with no formal standing. 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-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–11 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; the sender-policy section below walks through it.

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 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-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-00, titled “DKIM2 Sender Policy.” 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.

1. A new auth= tag in the DMARC record (§1.2.2). 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.”
2. The Author Domain comes from i=1 (§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, and to do so “the entire chain of custody MUST be successfully validated.” Local policy MAY fall back to the From: at the highest i=.
3. DKIM2 becomes a DMARC authentication method (§1.2.2). 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 d= on the signature that carries rt=/mf= and the Author Domain (§1.3.1 and §1.2.2, the latter citing spec §9.4 and RFC 9989 §3.2.10.1).
4. p= and sp= are generalized (§1.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 (§1.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 §1.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.

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

• No Security Considerations and no IANA Considerations sections. The document has two numbered sections: Introduction and Normative References. 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. One broken link anywhere in the chain and the receiver falls back to the forwarder’s identity and the forwarder’s policy.
• It is a rough -00. The donotmodify validation text tells receivers to check for modification “after the donotexplode” (§1.3.2.3), one example uses an f=reporting flag the draft never defines (§1.4.2.2), another contains the truncated sentence “The intermediate relay also does not .” (§1.4.2.3), the “without an intermediates” example shows a d=forwarder.example signature (§1.4.2.1), and the running page header still reads “Local Headers,” inherited from Chuang’s localized-header draft.

Where the working groups stand: the DKIM WG has scoped DMARC changes out of the core spec (IETF 126 minutes), the DMARC WG’s current charter says it “will adopt no other documents or work items” beyond ARC-to-Historic, and 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” — had not been answered on the list. 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 has not come. With under three weeks left in the quarter there is no Working Group Last Call, no revised draft, and a charter that closes the group on 16 October 2026 if the task is not done. Two outcomes are now live: the chair declares rough consensus and the document moves in the remaining five weeks, 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 reading this in September 2026: 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 IETF 126 minutes say the chairs “will coordinate a virtual interim meeting” before the next face-to-face meeting.

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. Google and Microsoft still document ARC handling (the Postmaster Tools guidance and Set-ArcConfig referenced above), while 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-00, an unadopted individual draft with no IANA section. 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 — that is test code, not production signing, and the spec has been revised six times since the March adoption call.
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. DKIM2 exists as interoperability-test code: 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, not production signing at any mailbox provider. The spec is still changing (revision -06, 28 August 2026), no mailbox provider has announced a production date, 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 is an optional auth= tag in your existing _dmarc record, from the unadopted individual draft draft-chuang-dkim2-sender-policy-00. Do not publish it yet.

What is the proposed DKIM2 auth= tag in DMARC?

A proposal in draft-chuang-dkim2-sender-policy-00 (10 September 2026, 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, 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 five weeks left on the DMARC WG’s charter, 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 — this revision is dated 11 September 2026. 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