ARC is the answer to a problem DMARC created. Once receivers started acting on authentication failures, a whole category of legitimate mail started failing: anything that passed through something which modified it or relayed it. ARC is a way for that something to leave a signed record of what the authentication looked like before it interfered.
Why does legitimate mail fail authentication?
Because both mechanisms are fragile in exactly the situations forwarding creates.
SPF is evaluated against the sending server's IP. Forward a message and the forwarding server is not on the original domain's SPF record, so SPF fails. DKIM signs the content, so it survives a plain forward, but a mailing list that appends a footer or rewrites the subject changes the signed material and the signature fails.
Put a DMARC policy of p=reject behind those failures and a mailing list becomes a machine for bouncing its own subscribers' mail. That was the immediate, practical breakage, and ARC is the protocol response.
What does ARC add to a message?
Three header fields per participating hop, together called an ARC set.
- ARC-Authentication-Results records the authentication result that this handler observed, before it did anything to the message.
- ARC-Message-Signature signs the message as this handler is passing it on, in the manner of a DKIM signature.
- ARC-Seal signs the chain itself, so that earlier sets cannot be removed or reordered without detection.
Each set carries an instance number, so the chain has an order, and the seal carries a chain validation status of none, fail or pass. A receiver at the end can therefore reconstruct who handled the message and what each of them saw.
The specification describes the result as a chain of custody, and is careful about what makes it worth anything:
Any ARC-enabled Internet Mail Handler can validate the entire set of custody and the authentication assessments asserted by each party to yield a valid chain of custody. If the evidence-supplying custodians can be trusted, then the validated chain of custody describes the (possibly changing) authentication assessment as the message traveled through various custodians.
Does a valid ARC chain mean the message gets delivered?
No, and this is the part most summaries overstate.
RFC 8617 grants a receiver permission, not an obligation:
With this information, Internet Mail Handlers MAY inform local policy decisions regarding disposition of messages that experience authentication failure due to intermediate processing.
"MAY inform local policy" is the whole guarantee. A receiver is free to ignore your chain, and a receiver evaluating a chain is really evaluating the reputation of the intermediaries that sealed it. An unknown forwarder's seal buys nothing. A large mailbox provider's seal buys a great deal. So ARC does not transfer trust so much as give a receiver something to attach trust to.
It is also worth noting the document's own status. ARC is published as Experimental, not Standards Track, which is unusual for a mechanism this widely deployed and a fair signal of how much of its behaviour is convention rather than specification.
Do I need to implement ARC?
Only if you relay other people's mail.
The distinction that matters is whether you are an originator or an intermediary.
| If you are | What ARC asks of you |
|---|---|
| Sending your own mail to your own recipients | Nothing. Get DKIM alignment right instead |
| Running a mailing list or a forwarding service | Seal messages, so your subscribers' mail survives their senders' policies |
| Receiving mail | Optionally validate chains, and decide which sealers you trust |
Yahoo puts the same rule in one line in its sender guidance: "If you forward emails, implement ARC (Authenticated Received Chain)."
If your mail is failing DMARC and you are not forwarding anything, ARC is not your fix. The cause is almost certainly alignment, and how to fix DMARC failures is the right place to start.
What should I do about mail that legitimately gets forwarded?
Assume it will lose SPF and keep DKIM intact.
Since DMARC passes on either aligned mechanism, a message with a valid, aligned DKIM signature survives a plain forward without ARC being involved at all. That makes DKIM the mechanism worth protecting: sign with a key you control, sign the headers that matter, and avoid tricks like body-length limits that buy a surviving signature at the cost of a spoofing surface.
ARC then covers the remaining case, where the intermediary does not just relay but edits. You cannot make that case work from the sending side, which is precisely why the protocol puts the obligation on the intermediary.