ARC: the Authenticated Received Chain, explained

The three ARC headers

Each ARC participant adds three header fields to the message, numbered by "instance" (i=1 for the first intermediary, i=2 for the next, and so on):

• ARC-Authentication-Results (AAR) — the snapshot of the authentication results (SPF, DKIM, DMARC) that the intermediary observed on arrival, before any modification. This is the testimony itself.
• ARC-Message-Signature (AMS) — a signature, very close to a DKIM signature, computed over the message (headers and body) as the intermediary forwards it. It captures the message's state at that specific link.
• ARC-Seal (AS) — a signature that covers all the ARC header fields of the previous instances plus the current AAR and AMS. It's the seal that locks the chain: it protects its integrity and order, so a link can't be removed or reordered without it showing.

Each ARC-Seal carries a chain-validation tag, cv= (chain validation), which is none, pass or fail. It indicates whether the chain, up to that link, held together. The most recent seal summarizes the overall state: a chain at cv=pass is intact end to end.

How a receiver uses it

When a message arrives with an ARC chain, the final receiver proceeds in two steps. First, it validates the chain: are the seals cryptographically correct, in the right order, unaltered? If so, the chain is at cv=pass.

Then — and this is where it all plays out — it decides whether it trusts the intermediaries that sealed the chain. If it does, it can apply a local policy override: instead of rejecting the message because it fails DMARC here and now, it consults the oldest AAR, sees that the message passed authentication at the source, and delivers it anyway. The mailing list's legitimate mail is saved.

That decision remains entirely in the receiver's hands. ARC forces nothing: it supplies usable evidence, and the receiver chooses whether to act on it. The major mailbox providers — Google, Microsoft and others — apply and honor ARC at scale, which makes the mechanism genuinely useful in practice, even though it remains formally experimental.

A concrete example

Here is a message written to a professional mailing list. It leaves the sender's server perfectly authenticated: SPF and DKIM aligned for the sending domain. The list receives it, adds [Work-Group] to the subject and a legal footer, then re-sends it to three hundred subscribers. Along the way, the SPF is worthless (the mail now comes from the list) and the DKIM signature is broken (the subject and body changed). For a subscriber whose domain is at p=reject, that message should end up rejected.

But the list participates in ARC. On receiving the message, it sealed a link attesting "on arrival, this message passed authentication for this domain." The subscriber is at a major provider that honors ARC: it validates the chain, finds it intact (cv=pass), trusts the list, and delivers the message despite the apparent DMARC failure. Without ARC, that post to the list ended up in the bin; with it, it arrives. It's precisely this scenario, repeated thousands of times a day, that makes moving to reject less frightening than it looks — provided, as we'll see, it doesn't turn into blind trust.

ARC doesn't replace DMARC — and isn't automatic

The limits deserve honesty, or the whole thing collapses into wishful thinking.

First, ARC rests entirely on trust. Nothing technically stops a malicious intermediary from sealing a chain asserting that a fraudulent message "passed authentication at the source." A valid ARC seal only proves the chain wasn't tampered with after the fact — not that its contents are honest. That's why a receiver grants an override only to intermediaries it knows and judges trustworthy. ARC shifts the problem to a question of reputation; it doesn't erase it.

Second, ARC is not a substitute for DMARC or for the alignment work. It only rescues legitimate indirect mail that was broken in transit. It does nothing for a message that wasn't authentic to begin with, and it in no way removes the obligation to publish SPF, DKIM and DMARC correctly. Where the roles blur, SPF, DKIM and DMARC explained together is the place to go back to: ARC is a patch at the edges, not the foundation.

Finally, not all receivers honor ARC, and not all intermediaries seal it. It's an improvement layer, unevenly deployed, not a universal guarantee.

ARC and the move to p=reject

For anyone looking to harden a policy, ARC quietly changes the risk calculation. The great fear of reject — seeing legitimate mail that travels through lists and forwards vanish — is precisely the case ARC exists to rescue, at the receivers that honor it. In practice, a significant share of an organization's indirect mail crosses Google or Microsoft, which know how to exploit the chain. That doesn't make the subject ignorable, but it does put the risk lower than people often assume.

The right method doesn't change: the policy ramps up under the watch of the reports, with no assumption that ARC covers everything everywhere. The prudent trajectory is detailed in getting to p=reject without breaking legitimate email. ARC is an extra net stretched out by receivers, not a license to harden blind.

Where it shows up in the reports

ARC leaves an observable trace. In the daily aggregation returns, a source that fails alignment but was delivered anyway often shows up with an evaluated disposition of none accompanied by a reason of type "local policy" — the signature of an override, frequently tied to a valid ARC chain. Spotting those rows heads off a classic mistake: taking a "failing" source for a problem to fix, when it's actually legitimate indirect mail rescued by the receiver. Reading that nuance correctly is the difference between panicking over a false problem and truly understanding a domain's posture.

Does ARC need configuring?

For the vast majority of domain owners, the answer is no — and that's good news. Unlike SPF, DKIM or DMARC, ARC isn't published on the sender's own domain as a DNS record under its control. It's the intermediaries (lists, gateways, forwarding services) and the receivers that implement it. A sender has nothing to switch on: the benefit is passive, arriving whenever messages travel through intermediaries that seal and land at receivers that honor.

The only case where ARC becomes a sender's own business is the operation of infrastructure that receives and then re-sends mail on behalf of others — a security gateway, a forwarding service, a platform that relays. There, applying ARC headers correctly becomes a responsibility, so that the authentication of the messages passed along survives the trip. That work belongs to the same family of advanced standards as MTA-STS and TLS-RPT: useful, targeted, and relevant mostly to those who operate mail infrastructure.

In short

ARC is the chain of testimonies that lets a receiver save legitimate mail broken by an intermediary, by relying on the original authentication rather than the damaged result it observes. Three headers (AAR, AMS, AS), a chain validation, an override left to the receiver's discretion — and grounded in trust. It's a valuable net against the false positives of indirect mail, honored by the major providers, but neither a substitute for DMARC, nor a universal guarantee, nor something that gets configured on the sending domain.

The best way to see all this concretely is still to look at the actual flows. A domain run through the free DMARC analyzer surfaces the real sources, aligned or not, and separates the genuine problem from the indirect mail receivers already know how to rescue.