On April 22, 2026, the IETF DMARC working group published draft-ietf-dmarc-arc-to-historic-00, calling for RFC 8617 to be reclassified as a Historic standard. The working group had been rechartered less than a week earlier, on April 16, 2026, with a specific mandate to produce a status-change document for ARC by November 2026.
The experiment that was ARC is, in the IETF’s formal language, over.
That matters to anyone running a DMARC policy at p=quarantine or p=reject. ARC was the mechanism that was supposed to keep legitimate forwarded mail from breaking when it hit your enforcement policy. Understanding what is being retired, why it did not work, and what is coming next tells you exactly what you need to do today.
What ARC Was Designed to Solve
DMARC has a well-known structural problem with email that passes through intermediaries.
Consider a message your customer sends from Gmail to a mailing list. The list manager’s server receives the original message, adds a list header, modifies the footer, and redelivers it to all subscribers. By the time that message arrives at a subscriber’s mailbox, two things have happened:
- SPF has broken. The original envelope sender passed SPF, but the mailing list is now sending from its own IP, which is not in your SPF record.
- DKIM may have broken. If the list manager modifies the message body or certain headers, the DKIM signature over those parts no longer validates.
A DMARC policy of p=reject looks at SPF alignment and DKIM alignment. If both fail, DMARC fails. The receiving server is now in the position of rejecting a message that was entirely legitimate when it entered the email chain.
Email forwarding (the kind a user sets up to redirect mail from one address to another) creates the same problem. The forwarder is not in your SPF record, it may modify the message, and the result is a DMARC failure at the final destination.
ARC, Authenticated Received Chain (RFC 8617, published July 2019), was the proposed fix. Each intermediary server that touched the message would add three headers: ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. Together they created a cryptographically verifiable record of what the message’s authentication state was at each hop. A receiver at the end of the chain could read the ARC headers, decide whether to trust the intermediary’s signature, and apply that trust to override the apparent DMARC failure.
Gmail adopted it. Microsoft adopted it. A handful of large providers followed. The theory was sound.
Why the Experiment Failed
The IETF’s conclusion, documented in the draft, is blunt: ARC has “enjoyed neither noteworthy uptake nor sufficient impact” despite years of development.
The core problem was the trust model. For ARC to work, a receiver at the end of the chain has to decide whether to honor the ARC seals left by the intermediary. That decision requires trusting the intermediary. But the IETF was never able to establish consensus on whose ARC signatures should actually be trusted across the internet.
There is no ARC trust registry. There is no globally accepted mechanism for a receiver to determine whether a mailing list server it has never seen before is operating legitimately. Without that, the trust decision defaults to a receiver-specific policy: Google trusts certain intermediaries it has learned about; Microsoft trusts its own set. The chains left by a smaller or less-known mailing list server may or may not be honored, depending entirely on where the final recipient’s mailbox lives.
In practice this meant that mailing list operators were publishing ARC seals, domain owners were relying on them, and the protection was partial, inconsistent, and invisible to both parties. The draft is explicit: “ARC no longer be deployed or relied upon between disparate senders and receivers.”
Major providers that already process ARC chains, specifically Gmail and Microsoft 365, will continue to do so for chains they trust. The IETF is not forcing them to remove existing code. But the guidance to implementers is to stop adding new ARC reliance, and for new intermediaries, not to deploy it at all.
What DKIM2 Changes
The lesson from ARC is informing the next generation of email authentication: DKIM2.
DKIM2 is an active IETF working group project, adopted by the DKIM working group, with an initial motivation document published May 4, 2026. It is designed to replace the current DKIM standard (RFC 6376) rather than layer on top of it.
The forwarding and intermediary problem is addressed differently in DKIM2. Instead of having intermediaries add their own trust assertions (the ARC approach), DKIM2 defines an algebra for undoing common message modifications. An intermediary that alters headers is expected to record the previous header value in a machine-readable way. A receiver can then reverse the modifications to compare the eventual message against the original, and verify signatures at multiple points in the chain without a separate trust fabric.
Other improvements in the DKIM2 proposal include defense against replay attacks (a long-standing weakness in DKIM1), stronger cryptographic requirements, and streamlined key rotation practices that make regular key changes operationally feasible.
Timeline: the current working document expires in October 2026, requiring a new iteration before that date. Major providers are expected to have working DKIM2 implementations before the end of 2026. Backward compatibility is a deliberate design choice, meaning existing DKIM1 keys continue to work as the transition begins.
What DMARC Teams Need to Do Right Now
The ARC retirement and DKIM2 development create a practical gap period. Here is what to act on today.
If your domain is at p=quarantine or p=reject: Check whether your legitimate mail flows include mailing list subscriptions or email forwarding paths where your own users are the senders. A newsletter subscription where you receive copies, a support alias that fans out to multiple agents, a customer community where replies flow through a list server, all of these are ARC-dependent if they involve your domain appearing in the From header.
Audit with aggregate reports. Your DMARC aggregate reports (RUA) show you every source sending email that claims to be from your domain, including forwarded paths. If you see sources you cannot explain, some of them may be legitimate forwarding infrastructure where ARC was doing the work of passing authentication. As ARC stops being the universal fix, those paths need direct attention: either get DKIM signing at the list manager level, or accept that some forwarded mail will fail DMARC and adjust accordingly.
Do not wait for DKIM2. The operational answer for forwarding problems today is DKIM alignment at the source. If you run a mailing list, sign outgoing messages with a DKIM key from your list’s own domain (not the original sender’s domain), and configure a From: alignment that the list controls. This sidesteps both the broken SPF problem and the ARC trust problem at once.
Track provider-specific behavior. Until DKIM2 is deployed, Gmail and Microsoft will continue honoring ARC chains from intermediaries in their trust lists. If your users receive list mail at Gmail addresses, forwarded DMARC failures are less likely to be a problem there today. But “Gmail still honors it” is a transient policy fact, not a long-term architectural fix.
Do not add ARC seals to new deployments. The IETF guidance is unambiguous. If you are deploying a new mailing list manager, a forwarding service, or any intermediary infrastructure, do not implement ARC. Invest that engineering effort in DKIM2 readiness instead.
The Bigger Picture
The ARC retirement is a signal that the email authentication stack is maturing. The industry spent several years deploying a partial fix for a real problem. That fix turned out to depend on a trust model the internet was not ready to agree on. DKIM2 is a more fundamental redesign: rather than adding new trust assertions, it improves the core signing mechanism so forwarding and modification scenarios can be handled without a separate trust fabric.
The window between ARC’s retirement and DKIM2’s widespread deployment is the period where domain owners at enforcement need the sharpest visibility into their actual mail flows. Aggregate reports, source enumeration, and DKIM key inventory are the tools that close that visibility gap.
Need to see every source sending as your domain, including forwarded and list paths? Excello Mail parses your DMARC aggregate reports against the RFC 9989, RFC 9990, and RFC 9991 standards, surfaces every sending source with SPF and DKIM alignment status, and flags the paths where forwarding is most likely causing failures. Sign up for free to Excello Mail and get full visibility into your email authentication posture before the ARC transition creates gaps you cannot see.