In May the IETF wrote that nobody uses ARC

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: a chain of glass links, the last ones unlit and fading into darkness

There is a protocol that has been presented for seven years as the solution to the oldest problem in email authentication. It has a serious name, an RFC, and the backing of Google, LinkedIn and Valimail.

In May 2026 the IETF published the new DMARC standard. It devotes one paragraph to that protocol, and the paragraph is a verdict of failure.

The problem, which is real

A message that passes through an intermediary loses its guarantees. That is written in the very first lines of RFC 8617, in July 2019:

“The utility of widely deployed email authentication technologies such as Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) is impacted by the processing of Internet Mail by intermediate handlers.”

The mechanism is easy to understand. A mailing list receives your message, adds a prefix to the subject, appends an unsubscribe footer, then resends it from its own servers.

SPF fails, because the sending IP address has changed. DKIM fails, because the content was modified after signing. And DMARC, which rests on both, fails in turn.

RFC 8617 puts it this way: “Failures of authentication caused by the actions of intermediate handlers can cause legitimate mail to be incorrectly rejected or misdirected.”

What ARC proposes

ARC adds a chain of custody to the message. Each intermediary that handles the mail records the authentication verdict as it found it on arrival, and signs that record.

The abstract describes the intent without embellishment:

“The Authenticated Received Chain (ARC) protocol provides an authenticated ‘chain of custody’ for a message, allowing each entity that handles the message to see what entities handled it before and what the message’s authentication assessment was at each step in the handling.”

The final recipient can then choose to trust the verdict rendered upstream rather than its own, broken by the transit.

One point of status deserves noting, because it is rarely mentioned: RFC 8617 is classified Experimental. It was in July 2019, and it still is in September 2026. The document says so itself: “This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.”

What the IETF says in May 2026

The new DMARC standard, RFC 9989, handles the mailing list question in its section 7. It begins by describing what list operators have actually done, for want of anything better:

“In the ten years since large consumer mail systems started publishing p=reject policies, mailing list software has all adopted workarounds to make the From: header line DMARC aligned. […] While these workarounds are far from ideal, they are firmly established and list operators treat them as a fact of life.”

Then comes the paragraph that matters here:

“Mail developers have been trying for a decade to invent technical methods to allow mailing lists to continue to work without modifying the From: header line, with a prominent example being the Authenticated Received Chain (ARC) protocol described in [RFC8617]. While work continues, as of this document’s publication, none of the methods have become widely used.”

“None of the methods have become widely used.” That is not an observer’s opinion. It is the text of the standard governing email authentication, published by the same body that published ARC.

Who deployed it anyway

Microsoft, and in documented fashion. Its trusted ARC sealers page, updated on 3 August 2026, describes the use case precisely:

“Authenticated Received Chain (ARC) helps reduce inbound email authentication failures from message modification by legitimate email services. ARC preserves the original email authentication information at the email service. You can configure your Microsoft 365 organization to trust the service that modified the message.”

Note the direction of the manoeuvre. It is not the sender who enables ARC: it is the administrator of the receiving domain who declares trust in a named intermediary. Microsoft insists on restraint: “Add only legitimate, required services as trusted ARC sealers in your Microsoft 365 organization.”

ARC is therefore not a sender setting. It is a receiving decision, taken by someone else, about a third party.

What Google says, and what it does not

Google publishes no documentation page dedicated to ARC. Not in the admin help, not in the developer documentation, not in its sender guidelines, where the word does not appear.

The only normative mention sits in a user help page about message authentication, and it points in a direction nobody expects:

“ARC checks the previous authentication status of forwarded messages. If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated.”

At Google, ARC can therefore downgrade a verdict, not only rescue one. A message that would pass SPF or DKIM on arrival is treated as unauthenticated if the chain reveals an upstream failure.

And on the Google Workspace side there is no equivalent of Microsoft’s trusted ARC sealers. Nothing to configure, nothing to declare.

The sentence that settles it for the sender

It sits in the sender guidelines FAQ, and it is worth framing:

“DMARC alignment isn’t required for forwarded or mailing list messages, which are sometimes referred to as indirect messages.”

In other words: the case ARC claims to solve is not, for Google, a case held against you. Your forwarded messages that fail alignment do not count against you.

That completely reorders the priorities. ARC is a fascinating subject for anyone running a mailing list, a security gateway or a forwarding service. For a sender pushing out a newsletter, it is a subject other people handle on their behalf.

What to do tomorrow morning

If you are a sender, nothing. Just make sure your DMARC reports do not send you into a panic over indirect flows: a forward that breaks alignment is normal behaviour, documented as such by Google, and it is not fixed by anything on your side.

If you run a mailing list, the proven solution is not ARC. It is rewriting the From header, which RFC 9989 describes as universally adopted and treated by list operators as a fact of life.

If you administer a Microsoft 365 tenant and legitimate mail arrives broken after passing through an identified provider, then the trusted ARC sealers page genuinely concerns you. It is the only one of the three cases where anything gets configured.

One broader lesson remains. Seven years after publication, a protocol backed by the largest players in email is still experimental and barely deployed. That is not an anomaly: it is the normal pace of this ecosystem, and it should temper enthusiasm for the next definitive solution.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.