emailmarketing.net
EnglishFrançais

ARC (Authenticated Received Chain)

RFC 8617 reference — the three ARC header fields, instance and chain-validation tags, sealing and validation rules, and how receivers use an intact chain to override DMARC failures caused by forwarding.

Reference5 min read

Who it is for ESP operators, Senders

Applies to senders on any platform

ContentsOn this page — 6 sections

When mail passes through a forwarder or a mailing list, it can fail DMARC at the final receiver even though the original sender authenticated it correctly. Forwarders and mailing lists routinely break SPF, because the sending IP address changes, and they often break DKIM, because they add subject tags or footers or rewrite the body. This is the problem of indirect mail flow.

ARC, defined in RFC 8617 (Experimental), addresses it. Each intermediary records the authentication results it saw when the message arrived, and seals them cryptographically, which builds a chain of custody that can be verified. 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 reports what intermediaries saw. It is an additional signal, not a replacement for SPF, DKIM and DMARC, and it does not by itself make a message trustworthy. A spammer can seal their own spam, so the sealer's reputation matters.

The ARC Set: three header fields per hop

Each intermediary that takes part (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 and DMARC (and ARC) results this hop saw when it received the message, in the same format as the Authentication-Results header. (not a signature)
ARC-Message-Signature AMS A signature like DKIM's (with the same tag syntax: a=, b=, bh=, d=, s=, h=, …) over the message headers and body as this hop passed it on. With it, the hop takes responsibility for any changes it made. It uses relaxed canonicalization, and must not sign existing ARC-Seal or Authentication-Results fields. Headers and body
ARC-Seal AS Seals the chain itself. It signs only header fields (not the body): all earlier ARC Sets plus this hop's AAR and AMS, in the order AAR, AMS, AS for each instance. It carries the cv= chain-validation verdict. ARC headers only

Key tags

Tag On Values and rules
i= all three The instance number that ties a set together: 1–50, increasing by 1 at each hop. Instance numbers must form a continuous sequence 1..N, with exactly one of each field for each instance. More than 50 sets, or a broken sequence, fails the chain.
cv= ARC-Seal The chain validation status as this sealer saw it: none (no earlier chain existed, so this is the first hop), pass (the earlier chain validated) or fail (the earlier chain failed validation).
d=, s=, a=, b=, t= AMS, AS As in DKIM: the sealing domain, the selector (the key is published at <selector>._domainkey.<domain>), the algorithm, the signature and the timestamp.

Chain validation (receiver algorithm)

  1. Collect all ARC Sets. The chain fails if there are more than 50, or if the instance sequence 1..N is broken, duplicated or incomplete.
  2. If the ARC-Seal with the highest instance 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 also be checked, to find the oldest point where the message still passed.
  4. Validate every ARC-Seal, from the highest instance down. Each seal must verify over all the sets it covers.
  5. If all checks pass, the chain status is pass. Otherwise it is fail.

A failed or missing chain simply means that ARC gives no usable information. Judge the message on its ordinary SPF, DKIM and DMARC results.

Sealing rules

  • A sealer records the results it saw in a new AAR, signs the message with an AMS, then seals it with an AS whose cv= reflects the state of the chain it found.
  • If the sealer found a malformed or failed chain, it must not extend the chain as valid. It seals with cv=fail, and the scope of the AS b= MUST cover only the ARC Set created by the MTA that detected the failure (not the broken earlier sets).
  • Sealers should seal only mail they actually handled and evaluated. Sealing is a statement of custody, backed by the reputation of the sealing domain.

How receivers and DMARC evaluators use ARC

  • A DMARC evaluator may, as local policy, accept the authentication results in a validated ARC chain. If the message fails DMARC now, but the oldest AAR shows an aligned SPF or DKIM pass at the first hop and the receiver trusts every sealer in the chain, the receiver can deliver the message despite p=reject or p=quarantine.
  • This is exactly the local_policy or mailing_list override you see in DMARC aggregate reports. RFC 8617 suggests recording, in the report's comment on the policy override, the chain validation status, each seal's d= and s=, and the originating IP address from the first ARC Set.
  • Trust in sealers is based on reputation and differs from one receiver to another. Large providers keep lists of forwarders and list operators whose seals they honor. An ARC pass from an unknown sealer, or one with a poor reputation, typically changes nothing.

Deliverability takeaways

  • Senders cannot deploy ARC to fix their own deliverability. Intermediaries (forwarders, mailing lists, security gateways) implement it, and receivers honor it. What senders should do is publish solid SPF, DKIM and DMARC records, so that the AAR at the first hop records an aligned pass.
  • Operators of forwarding services, mailing lists or filtering gateways should seal with ARC (and preserve the original headers), so that DMARC enforcement further along the path does not destroy their traffic.
  • Under its sender guidelines, Gmail requires ARC headers on traffic from bulk forwarders. Microsoft, Google and other major providers both seal and honor ARC.

Check your own record

The free check reads what your domain publishes in DNS.

In this topic

All 13 in Authentication →