ARC (Authenticated Received Chain) explained

ARC (Authenticated Received Chain) is an email standard that lets intermediaries, mailing lists, forwarding services, security gateways, record the authentication results a message had when they received it, then vouch for that record as they pass the message on. A downstream receiver whose own SPF and DKIM checks fail can consult the ARC chain and see that the message authenticated cleanly before the forwarding hop broke it. ARC is defined in RFC 8617 and exists for exactly one reason: forwarding legitimately destroys SPF and often DKIM, and DMARC enforcement would otherwise punish that mail.

The problem: forwarding breaks authentication

A forwarded message arrives from the forwarder's IP, which the original sender's SPF record never authorized, so SPF fails. If the forwarder modifies content, a mailing list adding a subject prefix or footer, DKIM breaks too. With both mechanisms down, DMARC fails, and at p=reject the receiver refuses mail that was perfectly legitimate one hop earlier. This is the forwarding gap described in the DMARC limitations entry, and ARC is the ecosystem's structural answer to it.

How the chain works

Each participating intermediary adds three headers, together called an ARC set, numbered by an instance tag (i=1 for the first hop, i=2 for the next). ARC-Authentication-Results records the SPF, DKIM, and DMARC results the intermediary observed on arrival. ARC-Message-Signature is a DKIM-like signature over the message as the intermediary forwarded it. ARC-Seal signs the ARC headers themselves, chaining each instance to everything before it, so the record cannot be reordered or partially stripped without detection.

1ARC-Seal: i=1; a=rsa-sha256; d=list.example.org; s=arc1;
2  cv=none; b=...
3ARC-Message-Signature: i=1; a=rsa-sha256; d=list.example.org;
4  s=arc1; h=from:to:subject:date; bh=...; b=...
5ARC-Authentication-Results: i=1; list.example.org;
6  spf=pass smtp.mailfrom=sender.com;
7  dkim=pass header.i=@sender.com;
8  dmarc=pass header.from=sender.com
9
10cv= in later seals records chain validity so far:
11none (first hop), pass, or fail

The final receiver validates the chain: every seal verifies, every instance links correctly, and the cv= status holds. A valid chain gives the receiver a trustworthy record that instance 1 saw the message pass DMARC, which it can weigh when deciding whether to override its own failing checks. That word, weigh, is the honest center of ARC: the standard explicitly leaves the override decision to receiver policy.

What ARC means for each role

For ordinary senders: nothing to deploy. ARC is implemented by intermediaries and receivers, and no DNS record or configuration on the sending side participates. The sender-side contribution to forwarding survival remains robust DKIM, since an intact signature needs no rescue. For operators of forwarding services and mailing lists: implementing ARC sealing (supported by Rspamd, OpenARC, and the large mail platforms) materially improves delivery of the mail you relay, and pairing it with From-rewriting covers the receivers that do not evaluate ARC. For receiver operators: evaluating ARC from reputable sealers reduces false rejections at enforcement without opening the DMARC bypass that blind trust would.

Reading ARC in the wild

In delivered headers, ARC sets sit alongside the ordinary authentication headers, and Gmail's Authentication-Results often shows arc=pass when a chain influenced its decision. In DMARC aggregate reports, forwarded traffic that a receiver accepted on ARC evidence typically appears with an override reason, which is how domain owners see the mechanism quietly saving their forwarded mail at enforcement.