ARC: Authenticated Received Chain explained

22 June 2026 · 5 min read

ARC, the Authenticated Received Chain, lets a forwarder or mailing list record the SPF, DKIM and DMARC results it saw when a message arrived, then seal that record with its own signature before passing the message on. A later receiver whose own DMARC check fails, because the forwarder changed the message, can read the chain and decide whether to trust the earlier result. ARC is defined in RFC 8617, published in July 2019 as an Experimental RFC. It informs a receiver's decision; it never forces delivery.

The problem ARC addresses

DMARC passes when SPF or DKIM passes and aligns with the From domain. Indirect mail breaks both:

• SPF fails, or passes only for the forwarder's own domain, because the message now arrives from the forwarder's IP address.
• DKIM fails if the forwarder changed anything the signature covers, such as a mailing list adding a Subject tag or a footer.

The message was genuine and passed when it left the sender, yet the final receiver sees a DMARC failure. Why forwarding breaks authentication covers this in detail.

The three ARC headers

Each participating intermediary adds an ARC set of three headers, numbered with an instance tag i= from 1 (the first intermediary) up to a maximum of 50.

A simplified example from the first intermediary:

ARC-Authentication-Results: i=1; lists.example.org;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; s=arc1; h=from:to:subject; bh=...; b=...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc1; b=...

The cv= tag on each seal records the state of the chain when that intermediary received the message:

• cv=none: there was no chain yet. Only the first set, i=1, uses it.
• cv=pass: the existing chain validated.
• cv=fail: the existing chain did not validate. RFC 8617 says a failed chain must be treated the same as no chain at all.

The order of events at an intermediary

RFC 8617 requires all modifications to be made before sealing. So a mailing list:

1. receives the post and runs its normal SPF, DKIM and DMARC checks;
2. makes its changes, such as the Subject tag and footer;
3. adds the ARC set: the AAR with the results from step 1, the AMS over the modified message, and the AS over the ARC headers;
4. sends the message on.

Because the AMS covers the message as it leaves, a later receiver can tell whether anything changed after this intermediary sealed it, while the AAR still tells it what the original authentication looked like.

A worked journey

1. alice@example.com posts to a list at lists.example.org. Her mail passes SPF, DKIM and DMARC for example.com.
2. The list records those passes in an AAR, adds [announce] to the Subject and a footer, then signs and seals the ARC set with cv=none.
3. A subscriber's mailbox provider receives it. SPF for example.com fails (the list's IP), and DKIM fails (the Subject and body changed), so DMARC fails.
4. The provider validates the ARC chain against lists.example.org's published keys. If the chain is intact and the provider trusts that list as a sealer, it can use the recorded dmarc=pass to deliver the post instead of applying example.com's policy.

What ARC does not do

• It is not a trust framework. RFC 8617 says so in as many words, and advises receivers to treat every sealer with suspicion. Whether a seal counts is entirely up to the receiver. Microsoft 365, for example, lets administrators name the ARC sealers they trust.
• It does not launder failed mail. If the message failed authentication when it reached the intermediary, the AAR records that failure.
• It is not something senders configure. ARC is added by intermediaries and checked by receivers. Your part as a sender is to make sure your mail passes DMARC with aligned DKIM when it leaves you, so there is a genuine pass for the chain to record.
• It does not make every list safe at p=reject. It only helps where the list adds ARC and the receiver trusts it. RFC 9989, the current DMARC standard, still says domains whose users post to mailing lists SHOULD NOT publish p=reject.

What it means for your own DMARC rollout

• Expect indirect mail in your reports. Forwarders and lists show up as SPF failures from their IP addresses. Where DKIM still passes and aligns, nothing needs fixing. The DMARC report analyser separates these sources from spoofing.
• Do not add forwarders to your SPF record. It does not scale, it eats your ten-lookup budget, and it is the wrong layer.
• Sign everything with aligned DKIM. A plain forward leaves it intact, and it is what ARC's first seal records as passing. Check selectors with the DKIM checker.
• Pick your policy with lists in mind. Mailing lists, DMARC and ARC covers the decision, and RFC 8617 explained goes through the specification section by section.

If you would rather have forwarded mail told apart from spoofing for you, DMARC analytics groups it separately in your report data.