ARC is not something most senders deploy themselves. It is a chain-of-custody signature the forwarder applies so downstream receivers can use original authentication results.
In forwarded vs spoofed, we covered the most common DMARC failure mode: a legitimate message gets forwarded, SPF breaks, DKIM survives, and the receiver delivers because DMARC passed on DKIM alignment. That works when the body of the message survives.
The messier case is a forwarder that modifies the message: a mailing list adding a subject prefix, a footer, or a digest wrapper. SPF has already broken because the forwarding server is now the SMTP client. If the modification also breaks DKIM, a real message can start looking like a DMARC failure.
What ARC actually is
ARC stands for Authenticated Received Chain. RFC 8617 defines three headers an intermediary can add when it forwards or modifies a message:
- ARC-Authentication-Results - what SPF, DKIM, and DMARC said before the intermediary changed anything.
- ARC-Message-Signature - a DKIM-style signature over the message and ARC headers at that hop.
- ARC-Seal - a signature over the chain so the next receiver can verify whether earlier ARC headers were preserved.
Every participating hop adds a new instance number: i=1, i=2, and so on. A receiver at the end can verify the chain and decide whether it trusts the intermediaries that signed it.
Who signs ARC
ARC is usually not a sender-side control. Ordinary domain owners publish SPF, sign DKIM, and enforce DMARC. ARC is for systems in the middle:
- Mailing lists that add footers, rewrite subjects, or otherwise modify messages before redistributing them.
- Mailbox providers that forward mail from one account to another.
- Corporate gateways that scan, rewrite, and re-emit messages inside or across organizations.
- Email-handling services that operate forwarding infrastructure at scale.
If you operate one of those systems, ARC signing may belong in your stack. If you are a SaaS company sending product, billing, or support mail from your own domain, your job is still to get DKIM alignment right and move DMARC to enforcement.
Why ARC changes report triage
ARC does not make a forwarded message magically pass DMARC. It gives the final receiver a second piece of evidence: the message failed here, but an earlier trusted hop says it passed before modification.
That can lead to a local policy override. In aggregate reports, those overrides often show up as policy_evaluated.reason entries. A simplified record can look like this:
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>local_policy</type>
<comment>arc=pass</comment>
</reason>
</policy_evaluated>Different receivers describe the reason differently. The point is the same: the receiver had enough chain-of-custody evidence to avoid treating the message like ordinary spoofing.
What ARC does not prove
ARC is not stronger than the reputation of the intermediary. A valid chain proves the headers were signed consistently. It does not prove the signer is trustworthy, and it does not replace the receiver's judgment about whether to honor that signer.
It also does not solve every mailing-list behavior. If a list rewrites the visible From: header to something like "Alice via list", it is making a different deliverability tradeoff. ARC helps preserve authentication evidence across modification; it does not force every intermediary to preserve the original author domain.
How to read ARC-shaped failures
- SPF fails because the forwarding server is now the sender.
- DKIM may fail because the intermediary modified the message.
- The aggregate report includes a local-policy reason such as arc=pass.
- The source infrastructure looks like a mailbox provider, gateway, or mailing list.
That combination is very different from a spoofing burst with no aligned DKIM, no trusted forwarding infrastructure, and no local-policy reason. It should be triaged as forwarded mail first, then investigated only if the infrastructure or volume looks wrong.
The state of ARC adoption
ARC is now common enough that ignoring it creates noisy reports. Google, Microsoft, Yahoo, Fastmail, Mailman 3, and many gateway products either sign, verify, or participate in ARC handling. Receivers still apply their own trust model, but the mechanism is no longer rare.
For domain owners, the practical takeaway is narrow: do not try to deploy ARC unless you operate forwarding infrastructure. Do learn to recognize ARC in reports, because it explains why some apparent failures are accepted by receivers and why some mailing-list traffic should not block your path to p=reject.