ARC moves to "Historic" status at the IETF: should you still care in 2026?
By CaptainDNS
Published on June 8, 2026
- The IETF is reclassifying ARC (RFC 8617) as "Historic" via the draft
draft-ietf-dmarc-arc-to-historicfiled on 22 April 2026, after the DMARC working group was rechartered on 16 April 2026. - No, this is not "a tool removing ARC": the source is an IETF standardization decision, not a software vendor.
- "Historic" discourages new deployments and cross-domain trust. It does not invalidate RFC 8617 and forces no one to stop verifying existing chains.
- ARC stays required in practice in 2026: iCloud (bulk senders), Gmail forwarders (
arc=pass), Microsoft 365 (trusted sealers, reason code 130). - If you own a domain, you probably have nothing to do about ARC: strengthen SPF, DKIM and DMARC, monitor your reports, and keep an eye on DKIM2.
A headline has been circulating since late April 2026: "ARC is dead." On forums and in a few newsletters, you can already read that some diagnostic tool "removes ARC," that the protocol is being abandoned, that everything needs reconfiguring. Reality is calmer, and above all more nuanced. ARC is not disappearing overnight, and the news does not come from any software vendor.
The exact source is an IETF document: the draft draft-ietf-dmarc-arc-to-historic, filed on 22 April 2026 by J. Trent Adams (Proofpoint) and John Levine. It proposes reclassifying RFC 8617, which specifies ARC, to "Historic" status. This is a standardization process decision, made inside the freshly rechartered DMARC working group. Nothing to do with a provider switching off a feature.
This guide does not re-explain ARC's mechanics in depth (the sealing headers, the chain of results). For that, read our deep-dive article What is ARC (Authenticated Received Chain)?. Here, the goal is decisional: what "Historic" really changes, why the IETF made the call, and what you should do depending on your role. Most of the time, the answer fits in one word: nothing, at least nothing specific to ARC. This article is for mail administrators, DevOps teams and deliverability leads who read an alarming headline and want a clear decision.
Check your email authentication instead of adding ARC
The news, explained: ARC moves toward "Historic" at the standards body
Let us start by establishing the facts, because the rumor has already distorted the essentials. No tool is "removing" ARC. What is happening is a documentary status change at the IETF, the body that standardizes Internet protocols.
What does the draft draft-ietf-dmarc-arc-to-historic say?
The draft draft-ietf-dmarc-arc-to-historic is a short document whose sole purpose is to request the reclassification of RFC 8617 (the ARC specification, published in 2019) from its current status to "Historic" status. It was filed on 22 April 2026 by J. Trent Adams, from Proofpoint, and John Levine, two long-standing contributors to email standards.
Such a document does not modify ARC's technical content. It does not rewrite the protocol, nor add or remove a header. It is a "status-change document": it records a community judgment on the place ARC should now hold in the standards landscape. The motivation fits in one sentence: the adoption and cross-domain trust that ARC assumed never materialized at the expected scale, and the standardization effort is now focused elsewhere.
Timeline: DMARC working group recharter and deadline
This move is part of a reorganization. The IETF DMARC working group was rechartered on 16 April 2026, a few days before the draft was filed. A recharter redefines a group's scope and priorities; here, it signals that the community wants to close certain efforts and open others.
The reclassification draft then follows the usual process: discussion in the group, a last call, then review by the IESG. The targeted deadline to finalize the status-change is around November 2026. Until the process is complete, RFC 8617 formally keeps its current status; but the trajectory is clear and public.
What "Historic" really means (and does not mean)
The word "Historic" sounds like a death certificate. In IETF vocabulary (defined by the RFC 2026 process), it has a much more precise and far less dramatic meaning.
"Historic" describes a standard that is no longer recommended, usually because it has been replaced, because adoption did not follow, or because experience revealed its limits. Concretely, Historic status means this:
- it discourages new deployments of the protocol;
- it signals that the community no longer counts on this mechanism for the future;
- it advises against building any new cross-domain dependency on this protocol.
Conversely, "Historic" does not mean this:
- it is not an invalidation: RFC 8617 remains a published and readable document, its headers remain syntactically valid;
- it is not a ban: no one is required to stop producing or verifying existing ARC chains;
- it is not a switch: no server stops working because a draft was filed.
This distinction is the heart of the article. Deprecated on paper does not mean dead in practice. The rest shows why.
Why this reversal, and the IETF's reasoning
ARC was designed to solve a real and persistent problem: mail forwarding breaks authentication. The idea was elegant. So why is the community now filing it among historical standards? Three reasons combine.
Limited adoption and fragile trust
ARC rests on a strong assumption: that a receiver trusts the seal applied by an intermediary it does not control. Yet that trust cannot be decreed. In practice, only a handful of very large players published and maintained lists of "trusted sealers," and large-scale cross-domain coordination never took hold. A mechanism whose value depends on widespread trust loses its point when that trust stays confined to a handful of operators.
A fundamental gap that ARC does not close
ARC documents a chain of authentication results, but it does not protect against replay. A legitimately signed message can be captured and then mass re-sent without invalidating the signature, because neither DKIM nor ARC ties the signature to the envelope or to the message's actual route. ARC adds traceability, not end-to-end integrity. The community eventually concluded that investing further in ARC amounted to reinforcing a bandage rather than treating the wound.
Effort concentrating on the successor
The IETF prefers to steer the work toward a mechanism that tackles the root cause, rather than keep refining ARC. That successor is DKIM2, currently being standardized, which signs both the source and the destination of every hop and closes the replay gap. Reclassifying ARC as Historic is also a signal of direction: stop spending energy extending ARC, look toward DKIM2. We return to it at the end of the article.
The paradox: ARC stays required in practice in 2026
Here is what the alarming headlines forget. At the very moment the IETF files ARC among historical standards, the three largest mail providers in the world use it actively. For an inbox, ARC is very much alive.
Apple and iCloud: ARC for bulk senders
Since 25 February 2025, Apple has applied reinforced requirements for high-volume senders to iCloud. Its documentation explicitly describes the use of ARC to preserve authentication results when a message passes through an intermediary before reaching an iCloud inbox. In other words, a provider relaying mail to iCloud that correctly seals the ARC chain sees its traffic handled better than one that does not.
Google and Gmail: forwarders sign, Gmail reads arc=pass
Gmail is arguably the largest ARC user in the world. When a message is forwarded (automatic redirection, alias, mailing list passing through Google's infrastructure), Google's forwarders apply ARC headers. On receipt, Gmail reads the arc=pass result to recognize that the original authentication was valid before forwarding, and thus avoids failing DMARC on a legitimate message simply because it was relayed. Here ARC is a daily cog of deliverability, invisible but decisive.
Microsoft 365: trusted sealers and reason code 130
Microsoft 365 integrates ARC into its composite authentication verdict. When a message would have failed DMARC because of forwarding, but an ARC "trusted sealer" preserved the original results, Exchange Online Protection can rescue the message and writes reason code 130 in its compauth header. That code signals precisely that a trusted ARC seal replaced a DMARC failure. The mechanism of trusted sealers, reason code 130 and the oda=1 indicator is detailed in our guide Compauth=fail on Microsoft 365.
Deprecated on paper, not dead in the inbox
The contrast is stark. At the IETF, ARC becomes "Historic." In Apple, Google and Microsoft infrastructure, ARC stays a signal read and used every day. These two facts do not contradict each other. Historic status says "do not build new ARC dependencies and do not count on it for the future"; it does not say "immediately stop processing the ARC chains the big operators still produce." Conflating the two means reading a standardization draft as a service-shutdown announcement.
The underlying problem has not gone away: forwarding breaks SPF, DKIM and DMARC
If ARC is deemed insufficient, the problem it targeted remains entirely intact. Understanding that problem helps decide what you should do (or not do).
Why does a redirection or a mailing list break authentication?
Mail forwarding undermines the three pillars of authentication, each in its own way.
SPF fails because it checks the sending IP address against the envelope domain. When a forwarding server re-sends the message, it is its IP that presents itself to the recipient, and that IP is almost never declared in the original domain's SPF. The result: SPF no longer aligns.
DKIM fails as soon as the intermediary modifies the message. A mailing list that adds a footer, rewrites the subject with a [List] prefix, or tweaks a header breaks the signed hash. The DKIM signature, which covers the body and certain headers, becomes invalid.
DMARC, which relies on the alignment of SPF or DKIM with the From: domain, therefore fails in turn as soon as both break at once. A perfectly legitimate message ends up dmarc=fail after a simple forward. That common scenario is exactly what ARC tried to rescue, by carrying the proof that authentication was good before the relay.
ARC was a bandage, not a cure
ARC never repaired SPF or DKIM. It added a layer of testimony: "at the time I received this message, here are the authentication results I observed, and I seal them." Useful, but conditioned on the trust the receiver grants the sealer, and powerless against replay. That is precisely why the durable answer is not to pile on ARC, but to strengthen what you actually control: your own authentication. The upcoming DMARCbis standard, which we detail in the DMARCbis guide, also clarifies alignment and policy management, without making your compliance depend on a third-party mechanism.
Who does what: domain owner or intermediary?
This is the most important section for deciding. The most widespread confusion is believing that everyone "implements ARC." False. ARC is an intermediary mechanism. The vast majority of this article's readers have never had to, and never will have to, deploy it.
You own a domain: you do not implement ARC
If you manage outbound mail for your organization (a website, a shop, transactional notifications, a sales team), you are a domain owner, not an intermediary. You do not seal ARC chains, and Historic status asks no action of you on ARC. What you should do concerns your own authentication:
- Strengthen SPF. Declare all your sending sources, watch the 10 DNS lookup limit that triggers a
permerror, and move the final mechanism from~allto-allonce you control your sources. - Harden DKIM. Sign all your streams with a key aligned to your domain, and set up regular key rotation.
- Advance DMARC. Move from
p=none(observation) to an enforcement policy (p=quarantinethenp=reject) once your sources are under control. - Monitor your DMARC reports. Aggregate reports reveal precisely what breaks in forwarding and which sources fail. That is your dashboard.
- Do not add ARC as a patch. You cannot "enable ARC" to fix forwarding that happens downstream: that would be the intermediary's job to seal, not yours. Focus the effort on what you control.
To check the real state of your authentication and how your messages are received, a deliverability test beats a guess; our deliverability testing guide explains how to read the results.
You are an intermediary: keep sealing ARC
If you operate a service that relays mail on behalf of others (a forwarder, a mailing-list platform, a security gateway, a redirection provider), you are concerned by ARC, and your course of action is nuanced.
First, do not cut anything abruptly. Apple, Google and Microsoft still read ARC chains to rescue legitimate forwarded messages. Stopping sealing overnight would degrade the deliverability of the mail you relay to those recipients. Historic status in no way requires you to stop.
Next, read Historic as a directional instruction, not a stop order. Do not build any new ARC dependency that would assume widespread cross-domain trust, do not invest in ambitious ARC extensions, and prepare the transition toward the successor. Track the evolution of the IETF process and the announcements from the large receivers: they are the ones who, in practice, will set the real pace of ARC's exit.
What comes next? DKIM2, the successor
Reclassifying ARC as Historic only makes sense because a better tool is arriving. That successor is DKIM2.
What the DKIM2 successor fixes
DKIM2 changes the approach. Where DKIM signs the content and ARC adds a sealed testimony, DKIM2 makes each SMTP hop sign by tying the source and the destination of the message. Each relay adds its own numbered signature, and the envelope used at each hop is covered. The direct consequence: replay, the gap neither previous mechanism closed, becomes detectable, because a message re-sent off its signed route no longer matches the expected chain. DKIM2 treats the cause where ARC treated the symptom.
Timeline and what it changes for you
DKIM2 is still at the Internet-Draft stage at the IETF. The exact syntax of headers and parameters may shift, and the first deployments are only expected from late 2026. For you, as a domain owner, this requires no action today: there is nothing to publish or configure for DKIM2 for now. The right stance is to watch. Understand the principles, follow the drafts, and keep a healthy DKIM infrastructure, because DKIM2 will build on the same DNS foundations. Our article DKIM2: what's new, what's removed, and key dates details the new headers and the timeline of the drafts.
Conclusion: panic avoided, heading for DKIM2
The news is real but benign. The IETF is reclassifying ARC as "Historic": a signal of an ending cycle, not a service shutdown. Let us recap by role.
If you own a domain, you have nothing to do about ARC, neither yesterday nor today. Strengthen SPF, DKIM and DMARC, monitor your reports, and never add ARC as a patch.
If you are an intermediary, keep sealing ARC as long as Apple, Google and Microsoft read it, but stop building new dependencies on it and prepare the transition.
And for everyone, the heading is the same: the next step of email authentication is called DKIM2. Nothing to do today, everything to understand for tomorrow.
FAQ
Is ARC dead or abandoned in 2026?
No. The IETF is reclassifying ARC (RFC 8617) as "Historic" via the draft draft-ietf-dmarc-arc-to-historic filed on 22 April 2026. "Historic" discourages new deployments and signals that the community no longer counts on ARC for the future, but it does not invalidate the specification and forces no one to stop producing or verifying ARC chains. In practice, Apple, Google and Microsoft still use it actively.
Should you still implement ARC in 2026 if you have not already?
For the vast majority of organizations, no. ARC is an intermediary mechanism (forwarders, mailing lists, gateways), not a protocol that domain owners publish themselves. If you manage outbound mail for your organization, you never had to deploy ARC, and Historic status changes nothing about that. Focus on SPF, DKIM and DMARC.
I already deployed ARC on a forwarder or gateway: should I remove it?
No, do not cut anything abruptly. Apple, Google and Microsoft still read ARC chains to rescue legitimate forwarded messages. Stopping sealing would degrade the deliverability of the mail you relay to those recipients. Historic status only invites you to avoid building new ARC dependencies and to prepare the transition to DKIM2, not to stop immediately.
Should you keep verifying ARC headers on receipt?
Yes, if you operate a receiver that already relies on ARC. Historic status does not ask you to stop verifying existing chains. The large providers keep reading arc=pass to avoid failing DMARC on legitimate forwarded messages. As long as those chains circulate, ignoring them would penalize legitimate mail.
ARC versus DKIM2: what replaces ARC, and when?
The successor is DKIM2, currently being standardized at the IETF. Unlike ARC, which adds a sealed testimony without closing the replay gap, DKIM2 makes each hop sign by tying source and destination, which makes replay detectable. DKIM2 is still at the draft stage; the first deployments are only expected from late 2026. No action is required today, only watching.
Will RFC 8617 be removed or become invalid with Historic status?
No. "Historic" status in the IETF process sense does not remove or invalidate a document. RFC 8617 stays published, readable and technically valid: ARC headers remain syntactically correct and existing implementations keep working. Historic is a documentary signal that discourages new uses, not a withdrawal of the specification.
ARC solved the problem of forwarding breaking DMARC: is that problem solved another way?
Not completely yet. Forwarding breaks SPF (the relay's IP is not in the original SPF) and often DKIM (body or header modification), so DMARC fails. ARC was a bandage that carried the proof of authentication from before the relay. The durable answer is to strengthen your own SPF, DKIM and DMARC, monitor your reports, and follow DKIM2, which tackles the cause by signing each hop.
What does the "Historic" label at the IETF actually change for an admin?
For a domain administrator, in the short term: nothing. You do not implement ARC, so the status does not touch your configuration. What matters is the heading: do not bet on ARC for new projects, strengthen your own authentication, and get ready mentally for DKIM2. For an intermediary operator, the change is a trajectory instruction, not an order to stop immediately.
Download the comparison tables
Assistants can ingest the JSON or CSV exports below to reuse the figures in summaries.
📖 Glossary
- Historic (IETF status): a standardization process classification (RFC 2026) indicating that a protocol is no longer recommended for new deployments, without being invalidated or banned.
- RFC 8617: the specification of ARC (Authenticated Received Chain), published in 2019.
- ARC (Authenticated Received Chain): a mechanism by which an intermediary seals the authentication results it observed before relaying a message.
- Trusted sealer: an intermediary whose ARC signature is considered reliable by a receiver, for example Microsoft 365.
- Replay: the abusive reuse of a legitimately signed message, re-sent without invalidating the signature; a gap ARC does not close and that DKIM2 aims to fix.
- DKIM2: the successor being standardized at the IETF, which signs the source and destination of each hop to resist replay and forwarding.
