ARC
TL;DR: ARC lets a mail intermediary seal its authentication results into a message. The final receiver can verify what every hop on the forwarding path saw.
What is ARC?
ARC (Authenticated Received Chain) is an email standard that lets an intermediary attach its authentication assessment to a message and sign the message. As a message travels through forwarders and mailing lists, each ARC-enabled intermediary adds its own sealed assessment. The final receiver can see who handled the message and what the authentication results were at each hop.
Why ARC matters
Intermediaries break email authentication. A forwarder changes the envelope: it submits the message with its own envelope sender, so SPF no longer matches the original domain. Intermediaries also modify the message: mailing lists add footers, subject tags, and new headers. These changes break DKIM signatures.
By the time the message reaches its final destination, DMARC can fail even though the message was legitimate when it was sent. The sender has no way to prove that the message authenticated at the start of its journey.
ARC solves this problem. An ARC-enabled intermediary records the authentication results that it computed when it received the message, and seals them. The sealed results travel with the message. The final receiver can base its decision on the results from the point of sealing, not on the broken results at final delivery.
How ARC works
Each ARC-enabled intermediary adds one ARC set to the message. An ARC set is three headers:
| Header | Purpose |
|---|---|
ARC-Authentication-Results |
The intermediary’s SPF, DKIM, and DMARC results |
ARC-Message-Signature |
A DKIM-style signature over the message headers and body |
ARC-Seal |
A signature over the set’s own headers and all earlier seals |
The i= tag numbers each set. The first intermediary seals with i=1, the next with i=2, and so on. Each hop adds one set, and the sets together form the chain of custody.
The cv= tag in the ARC-Seal records the validation status of the chain up to that seal. none means that no prior chain existed when the message was sealed. pass means that the receiver validated the prior chain. fail means that the receiver did not validate the prior chain, for example because the message changed after an earlier seal.
How to verify an ARC seal
Seal verification is the same as DKIM verification. The ARC-Seal header carries the selector s= and the signing domain d= of the sealing intermediary.
- Look up the public key in DNS at
<selector>._domainkey.<domain>. - Verify the signature of each set in chain order.
The cv= tag of the newest seal gives the status of the entire chain.
Limits and trust
ARC reports authentication results. It does not force acceptance. A receiver that trusts the sealing domain can use a sealed pass to accept mail that fails DMARC. A receiver that does not trust the sealing domain can ignore the chain and apply its own policy. ARC deliberately leaves this decision to the receiver.
A broken chain means the message changed after a seal was applied. It does not tell you who changed it or why, only that at least one seal no longer covers the message as received.