For years, the email industry has been trying to solve a stubborn problem: What happens to authentication when a legitimate email gets forwarded, modified, or passed through an intermediary?

That question led to the creation of ARC — the Authenticated Received Chain protocol — published as RFC 8617 as an experimental standard. ARC was designed to preserve authentication results as messages moved between systems, helping receivers make better trust decisions even after SPF, DKIM, or DMARC checks were impacted by forwarding or mailing lists.

Now, after years of real-world experience, the industry is reaching a clear conclusion: ARC is not the long-term solution for cross-domain email authentication. The recommendation is that ARC no longer be deployed or relied upon between independent senders and receivers, and that RFC 8617 be officially reclassified as Historic.

So, What Was ARC Trying to Do?

Traditional authentication technologies like SPF, DKIM, and DMARC work well when email travels directly from sender to recipient. But, things get complicated when messages are forwarded, routed through mailing lists, or processed by security gateways that modify content or headers along the way.

ARC attempted to solve this by allowing each third-party system to “vouch” for what it saw when the message passed through, similar to a blockchain. In theory, downstream receivers could look at that chain of custody and make smarter decisions about whether the message should still be trusted.

The goal made sense — preserve trust even when the email path becomes messy.

What Happened In the Real World?

As organizations began deploying ARC, the industry gained valuable operational experience. And while ARC worked in some environments, broader adoption exposed a number of challenges

Different providers interpreted ARC chains differently. Trust relationships between unrelated organizations proved difficult to establish consistently. Validation logic became increasingly complicated. And, perhaps most importantly, ARC never demonstrated enough practical value to become a universally trusted signal across the Internet.

In many cases, it added complexity without delivering the level of reliability the ecosystem needed.

ARC Helped Shape What Comes Next

ARC succeeded in showing the industry what works, what doesn’t, and where future authentication efforts should focus. One of the most important outcomes of the ARC experiment is that its lessons are already influencing future authentication work, particularly ongoing discussions around “DKIM2,” the proposed evolution of DKIM.

Rather than continuing ARC as a standalone mechanism, the industry is now looking at what can be folded directly into next-generation authentication standards in a cleaner and more interoperable way.

That’s how Internet standards are supposed to work. We experiment. We learn. We improve.

ARC played an important role in that process.

Why Reclassify ARC as “Historic”?

Reclassifying RFC 8617 as Historic helps remove ambiguity about ARC’s status moving forward.

It signals to the industry that ARC should no longer be viewed as a recommended long-term deployment strategy between disparate mail systems. Instead, it becomes part of the historical evolution of email authentication — an important steppingstone that informed future work, even if it didn’t become the final answer.

ARC, Remembered

ARC was created to solve one of the hardest problems in email authentication, and it pushed the conversation forward in meaningful ways. While the protocol itself is being retired, the knowledge gained from deploying and evaluating ARC continues to shape the future of trusted email delivery.

In many ways, ARC did exactly what experimental standards are meant to do: Challenge assumptions, uncover operational realities, and help the industry move toward something better.

If you need help setting up SPF, DKIM, DMARC, or BIMI, try MxToolbox Delivery Center for all of your email delivery needs.