ARC Is Being Retired

Big news out of the IETF DMARC working group on April 22, 2026. A new draft proposes to reclassify the Authenticated Received Chain (ARC) protocol. draft-ietf-dmarc-arc-to-historic-00 is titled "Reclassifying ARC as Historic", and it is authored by J. Trent Adams of Proofpoint and John Levine of Taughannock Networks. If the draft advances, RFC 8617 (the 2019 Experimental spec that defined ARC's header fields, chain validation, and signing procedures) gets marked Historic to steer people away from new deployments.

If you have spent the last seven years deploying, evaluating, or recommending ARC, now is the time to take stock. Here is what the draft actually means in practice.

A Short Refresher on What ARC Was For

DMARC works when SPF or DKIM authenticate and align with the author domain. The real world breaks that model constantly. Mailing lists tack on footers. Forwarders relay from IPs the sender's SPF record has never heard of. Subject tags get prepended. Any of these actions can invalidate DKIM or bust SPF, so a message that was perfectly legitimate at origin arrives looking unauthenticated.

ARC shipped in 2019 as an experiment (RFC 8617) to fix exactly this. The design was straightforward and pretty clever. Every intermediary records the authentication results it saw, signs that record, and passes it along. A downstream receiver then reconstructs the chain and trusts the upstream result, even after modification.

How the Three Headers Fit Together

ARC works by stamping three header fields at every hop that chooses to participate:

• ARC-Authentication-Results (AAR) captures the authentication assessment the intermediary saw on input, typically the DMARC, SPF, and DKIM results from the previous hop.

• ARC-Message-Signature (AMS) is a DKIM-like signature covering the message headers and body as the intermediary received them, so a later verifier can check whether the message still matches what this hop observed.

• ARC-Seal (AS) signs the prior ARC headers themselves, chaining each new hop's contribution to everything that came before.

Each triple is tagged with an instance number (i=1, i=2, ...) so the chain can be read in order, and each ARC-Seal carries a chain validation status: cv=none on the first hop, cv=pass if the prior chain verified, cv=fail if any prior link was broken. A single cv=fail on any seal poisons the rest of the chain, which is one reason real world chains break easily: any hop that mis-signs, or any downstream bug that fails to preserve header order or whitespace, invalidates everything downstream of it.

That was the design. Here is why it did not scale to the open Internet.

Why the IETF Wants to End the Experiment

The draft's analysis comes down to five observations, all drawn from years of operational experience.

1. Signatures Are Not Trust

This is the central lesson, and the draft says it straight: "Verifiable history without reputation does not enable safe override of DMARC." ARC proved intermediaries can publish a verifiable handling history, and that part works fine. What it could not prove is that the history is safe to act on by itself. Without a scalable reputation system for signers, a valid chain just tells you someone signed something. It does not tell you whether that someone deserves to override DMARC.

2. A Global Reputation Layer Never Arrived

The draft does not mince words: "Operating, sharing, and refreshing reputation for potentially thousands of intermediaries is expensive and complex." No Internet-scale reputation system for ARC signers ever got built. Deployers fell back on allow lists instead: big mailbox providers and a handful of known mailing list operators. That approach is fine for bilateral deals and consortiums. It just does not work for the open Internet, and nobody has a plan to change that.

3. No Visibility Into What Changed

A valid ARC chain shows you which intermediaries touched the message. It does not show you what they changed. The draft names the gap directly: ARC headers "indicate that some transformation happened but not what changed." So an evaluator sees a signed chain and a broken DKIM signature, and still has to guess. Was it a harmless footer, or something malicious? The signal just is not rich enough to replace DKIM's original trust.

4. Receiver Policy Fragmented

Every receiver had to answer the hard questions alone. How many hops to honor? How to treat a partial chain? What about two links that disagree? When should ARC override DMARC enforcement? Different answers at different receivers meant unpredictable behavior across the ecosystem. And that, in turn, scared senders off relying on ARC at all.

5. Forwarding Is Still the Dominant Breakage

ARC was supposed to close the forwarder gap in DMARC. But the draft notes that early effective use "occurred inside single administrative domains or tightly controlled data centers" — not across the open forwarding ecosystem. Forwarders are too numerous, too dynamic, and too diverse to enumerate. Mailing lists, sure, you can catalog those. Consumer auto-forward rules, corporate relays, and one-off redirects? No chance. A mechanism that requires knowing and trusting each forwarder simply cannot cover real forwarding traffic.

The Path Forward Is DKIM2

Retiring ARC is not the end of the story, it points straight at the next chapter. The DKIM working group is hard at work on DKIM2, and the work has picked up serious pace. The motivation document, draft-ietf-dkim-dkim2-motivation-02, landed on November 3, 2025. Then the full 39-page protocol spec, draft-ietf-dkim-dkim2-spec-01, followed on April 20, 2026, just two days before the ARC retirement draft dropped. A best-practices document and a Milter deployment profile are shipping alongside it. DKIM2 signs the source and destination of every message, closes the DKIM replay gap that ARC never touched, and folds in the useful parts of ARC without building a parallel trust fabric. The motivation draft puts it nicely: "incorporating ARC's useful elements (for example, signed assertions about handling) into DKIM2 avoids a parallel chain or signature stack."

Concretely, DKIM2 proposes three structural changes that directly answer the ARC failure modes above. First, every hop adds its own DKIM2 signature in an ordered chain, so the chain lives inside DKIM itself instead of a parallel header stack. A forwarder has to re-sign with a key aligned to the previous hop's recipient domain. Second, the signature binds to the envelope (the MAIL FROM and RCPT TO addresses), so a message replayed to a different recipient is detectable with zero reputation lookup, which is the replay gap ARC never touched. Third, intermediaries that modify a message are expected to record the exact change in a structured way. A verifier can then reverse the modification, rebuild the original, and re-validate the upstream signature, the "no visibility into what changed" problem that sank ARC. The motivation draft sketches these properties, and the spec draft nails down the tag names and header formats. For a fuller side-by-side of the mechanics, check out DKIM2 vs DKIM.

So the ARC experiment did produce real insights. Those insights are getting absorbed into DKIM2, rather than propped up as a separate protocol with its own deployment and reputation burden.

What This Means for DMARC

The draft change the story around DMARC's best-known weakness: forwarding. "Forwarding remains one of the most pervasive sources of broken authentication results," and "broken authentication at forwarders represents a structural gap in DMARC deployment." That gap was exactly what ARC tried to patch. With ARC heading for Historic, the patch is coming off, and the gap stays open until DKIM2 lands in production.

So what do DMARC operators actually do in the interim? A few concrete things:

Keep reading ARC headers, but stop trusting them for delivery. The draft is explicit: "Receivers...may continue to verify them for forensic or intra-domain purposes, but should not make delivery decisions based on ARC chain validity without robust reputational trust signals." If you were tempted to soften DMARC policy on the strength of a valid ARC chain, now is the time to stop.

Double down on DKIM, because DKIM2 builds on it. DKIM2 is a successor, not a replacement of fundamentals. Strong keys, regular rotation, aligned signing on every outbound path, and clean relaxed-vs-simple canonicalization choices all carry forward. Messy DKIM today means messy DKIM2 tomorrow.

Watch your forwarder-driven DMARC failures closely. Your aggregate reports already show them, they are the ones that fail DMARC but look legitimate on inspection. Those messages are exactly what DKIM2 is designed to rescue, so the volume is a useful signal for sizing the eventual migration.

Do not pitch ARC signing as a forward-looking investment. That framing is gone. Put that budget into DKIM hygiene, replay hardening, and DKIM2 readiness instead.

The draft sits at version 00, dated April 22, 2026, with an October 24, 2026 expiration if no revision lands first. It will get debated, revised, and either advanced or replaced over the coming months. But the direction is clear, and the working group rarely publishes a draft this specific without consensus behind it.