RFC 8619 was published in July 2019 with the status of Experimental and describes the Authenticated Received Chain (ARC) protocol. On 16 April 2026 the DMARC Working Group (who originated ARC) voted to re-charter the group for the sole purpose of changing the status of the RFC to Historic and declaring the ARC experiment concluded. I was one of those who voted in favor.
The WG has six months to agree on actually doing this. If successful then there will be no further updates to the specification and deployment will not be recommended.
The reason for wanting to conclude the experiment is very simple: adoption was extremely low and those who did adopt it at scale did not find it useful.
Background
ARC tried to solve the “indirect email flows” problem. This is also informally referred to as the “mailing list” problem as they are the main originators of these flows.
Mailing lists are email based discussion groups. The flow works like this: an author replies to a message on a list that they are subscribed to, the reply goes to the Mailing List Manager (MLM) software which then resends the message to the other people on that list, preserving the author’s From address.
You can see the problem. For context, mailing lists worked fine for 30 plus years and pre-date all email authentication protocols. They also form the backbone of how the IETF gets work done.
If the MLM modifies a message, for example, by adding a footer or prefixing the subject line with the list name, then DKIM is invalidated which will cause deliverability problems. If the author’s domain has an enforcing DMARC policy then the message is guaranteed to get into widespread difficulties.
Many MLMs use workarounds such as setting the From address of all messages to the list address. This degrades the mailing list experience for many as it can break searches.
Another example of an indirect flow is alumni mail forwarding arrangements where mail sent to the old address of the student is forwarded on to their current address all while preserving the From address. This type of flow also pre-dates all authentication protocols.
What ARC does
ARC attempts to create a “chain of trust” by cryptographically signing the authentication evaluation (SPF, DKIM, and DMARC status) each time a message passed through an ARC-aware email system. So in a three-hop flow of A -> B -> C, C could use ARC to tell if the message from A to B passed authentication before B sent it on with a preserved “spoofed” From address.
In theory this allowed originators of indirect mail flows to use ARC to continue to operate as the always did but in a post-authentication world. The reality was a little different.
Weaknesses with ARC
ARC has no protections against forgery since it does not require that ARC signatures from previous hops verify. That means that anyone can build an ARC chain that contains incorrect information. This severely limited ARC’s usefulness since it needs the receiver to trust the sender - and if you trust the sender then why do you even need ARC? Closely connected to this is that ARC allows messages that would normally fail DMARC tests to land in inboxes but provides no assurances that the message are not forged.
What’s next?
The main focus on email authentication in 2026 is DKIM2 which incorporates learning from ARC.