---
title: "DKIM2 Explained: The 2026 Successor to ARC and DKIM"
description: "DKIM2 is the IETF's per-hop chained-signature successor to ARC and DKIM. Five drafts, four contested questions, and what email admins track in 2026."
publishedAt: 2026-05-04
tags: ["dkim2", "arc", "dkim", "ietf", "email-authentication", "future"]
faq:
- question: "What is DKIM2?"
answer: "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."
- question: "What is the difference between DKIM and DKIM2?"
answer: "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= and rt=, and rejects signatures older than 14 days. DKIM2 is a parallel-track successor — neither current draft formally obsoletes RFC 6376."
- question: "Is ARC being deprecated?"
answer: "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 working group's milestone is November 2026. Realistic earliest reclassification is Q1 2027. No mailbox provider has committed to a sunset date as of April 2026."
- question: "Is Microsoft's DKIM2 the same thing?"
answer: "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."
- question: "When can I deploy DKIM2 in production?"
answer: "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."
- question: "Will DKIM2 require new DNS records?"
answer: "No new resource record type. draft-chuang-dkim2-dns-04 Section 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."
---
"DKIM2" means two unrelated things in 2026. In Microsoft's Azure
Communication Services (ACS) portal, "DKIM2" is the UI label for the
**second DNS selector record** (`selector2._domainkey`) used for
zero-downtime key rotation — it is not a protocol. The IETF **DKIM2** is a
different thing entirely: a Standards-Track Internet-Draft proposing a
successor to RFC 6376 with per-hop signatures and replay protection. **This
article covers the IETF protocol.** If you landed here looking for ACS
selector setup, see Microsoft's Azure Communication Services email
troubleshooting guide instead.
# 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](/blog/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)](/learn/dkim/) 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.
| # | Draft | Status | Latest revision | Author(s) |
|---|---|---|---|---|
| 1 | `draft-ietf-dkim-dkim2-motivation` | WG draft | -02 (3 Nov 2025) | Gondwana, Clayton, Chuang |
| 2 | `draft-ietf-dkim-dkim2-spec` | WG draft (adopted 2026-03-16) | -01 (20 Apr 2026) | Clayton, Chuang, Gondwana |
| 3 | `draft-chuang-dkim2-dns` | Individual submission | -04 (18 Mar 2026) | Chuang |
| 4 | `draft-gondwana-dkim2-modification-alegbra` | Replaced by `draft-gondwana-dkim2-mailversion` | -04 (17 Oct 2025) | Gondwana |
| 5 | `draft-robinson-dkim2-message-examples` | Expired 1 Jan 2026 | -00 (30 Jun 2025) | Robinson, Herkula |
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](/blog/dmarc-forwarding-arc-fix/)
under RFC 8617, including the
[ARC chain validation walkthrough](/learn/arc/) 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.
| Document | Earliest realistic action | Who is most affected |
|---|---|---|
| `draft-ietf-dmarc-failure-reporting` (-24) | RFC publication likely 2026 H2 — IANA "Waiting on Authors" is the only block | Reporting consumers |
| `draft-ietf-dmarc-aggregate-reporting` (-32) | Publishes with the cluster | Reporting consumers, receivers |
| `draft-ietf-dmarc-dmarcbis` (-41) | Publishes with the cluster | Every sender, every receiver |
| `draft-ietf-dmarc-arc-to-historic` | WG Last Call ~Q3 2026; IESG Approved Q4 2026 to Q1 2027 | ARC implementers |
| `draft-ietf-dkim-dkim2-spec` | First implementations 2026 H2; broad operator deployment 2027 and beyond | Future-state planners |
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](/research/email-authentication/)
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](/tools/dkim-checker/)
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](/tools/arc-chain-analyzer/) — and start
monitoring DMARC across all 9 protocols on the free plan, no credit card
required.