ARC (Authenticated Received Chain)

ARC (RFC 8617, Experimental) addresses the indirect mail flow problem: forwarders and mailing lists routinely break SPF (new sending IP) and often break DKIM (subject tags, footers, body rewrites), so legitimate forwarded mail fails DMARC at the final receiver. ARC lets each intermediary record the authentication results it observed on arrival and cryptographically seal them, building a verifiable chain of custody. The final receiver can then see that the message authenticated properly before the forwarder modified it, and may choose to override a DMARC failure.

ARC conveys what intermediaries saw — it is an additional signal, not a replacement for SPF/DKIM/DMARC, and it does not by itself make a message trustworthy (a spammer can seal their own spam; the sealer's reputation matters).

The ARC Set: three header fields per hop

Each participating intermediary (an "ARC sealer") adds one ARC Set of three headers, all carrying the same instance number i=:

Header	Abbrev.	Contents	Signs
ARC-Authentication-Results	AAR	The SPF/DKIM/DMARC (and ARC) results this hop observed at receipt — same payload format as the Authentication-Results header.	(not a signature)
ARC-Message-Signature	AMS	A DKIM-like signature (same tag syntax: a=, b=, bh=, d=, s=, h=, …) over the message headers and body as this hop passed it on, taking custodianship of any modifications it made. Uses relaxed canonicalization; must not sign existing ARC-Seal or Authentication-Results fields.	headers + body
ARC-Seal	AS	Seals the chain itself. Signs only header fields (no body): all prior ARC Sets plus this hop's AAR and AMS, in order AAR → AMS → AS per instance. Carries the cv= chain-validation verdict.	ARC headers only

Key tags

Tag	On	Values / rules
i=	all three	Instance number tying a set together: 1–50, incrementing by 1 per hop. Instance numbers must form a continuous 1..N sequence with exactly one of each field per instance; >50 sets or a broken sequence fails the chain.
cv=	ARC-Seal	Chain validation status as seen by this sealer: none (no prior chain existed — first hop), pass (prior chain validated), fail (prior chain failed validation).
d=, s=, a=, b=, t=	AMS, AS	As in DKIM: sealing domain, selector (key published at <selector>._domainkey.<domain>), algorithm, signature, timestamp.

Chain validation (receiver algorithm)

1. Collect all ARC Sets; fail if more than 50 or the instance sequence 1..N is broken / duplicated / incomplete.
2. If the highest-instance ARC-Seal has cv=fail, the chain fails.
3. Validate the most recent AMS signature (the latest custodian's snapshot of the message). Older AMS signatures may optionally be checked to establish an "oldest-pass" point.
4. Validate every ARC-Seal, in descending instance order — each seal must verify over all sets it covers.
5. All checks pass → chain status pass; otherwise fail.

A failed or absent chain simply means ARC provides no usable information — treat the message on its ordinary SPF/DKIM/DMARC merits.

Sealing rules

• A sealer records its observed results in a new AAR, signs the message with an AMS, then seals with an AS carrying cv= reflecting the chain state it found.
• If the sealer found a malformed/failed chain, it must not extend it as valid: it seals with cv=fail, and the AS b= scope MUST cover only the ARC Set created by the MTA that detected the failure (not the broken prior sets).
• Sealers should only seal mail they actually handled and evaluated; sealing is an assertion of custody, backed by the sealing domain's reputation.

How receivers and DMARC evaluators use ARC

• A DMARC evaluator may, as local policy, accept the authentication assessments in a validated ARC chain: if the message fails DMARC now, but the oldest AAR shows an aligned SPF/DKIM pass at the first hop and every sealer in the chain is trusted, the receiver can deliver despite p=reject/p=quarantine.
• This is exactly the local_policy / mailing_list override you see in DMARC aggregate reports; RFC 8617 suggests documenting the chain validation status, each seal's d=/s=, and the originating IP from the first ARC Set in the report's policy-override comment.
• Trust in sealers is reputation-based and receiver-specific: large providers maintain lists of forwarders/list operators whose seals they honor. An ARC pass from an unknown or low-reputation sealer typically changes nothing.

Deliverability takeaways

• Senders can't deploy ARC to fix their own deliverability — it's implemented by intermediaries (forwarders, mailing lists, security gateways) and honored by receivers. What senders should do is publish solid SPF/DKIM/DMARC so the first hop's AAR records an aligned pass.
• Operators of forwarding services, mailing lists, or filtering gateways should seal with ARC (and preserve original headers) so downstream DMARC enforcement doesn't destroy their traffic.
• Gmail requires ARC headers on forwarded traffic from bulk forwarders under its sender guidelines; Microsoft, Google, and other major providers both seal and honor ARC.

Related

• DMARC — the policy layer ARC helps preserve across hops
• Authentication-Results header — the payload format AAR reuses
• DKIM — the signature machinery AMS/AS build on