ARC

Each ARC set includes ARC-Authentication-Results mirroring Authentication-Results at that hop, ARC-Message-Signature as a DKIM-like signature over selected headers, and ARC-Seal binding the chain instance.

Validators walk the chain from the newest instance backward, checking seals and signatures. A broken seal means the chain cannot be trusted.

ARC is designed for meshed forwarding paths where DMARC alignment for the original From domain would fail without context. It does not force receivers to accept mail; it documents prior authentication states.

RFC 8617 remains experimental in the standards track sense operators see in the document. Not every mailbox provider validates ARC on every message.

When ARC is present, verifiers walk instances from i=1 upward, checking that each ARC-Seal covers the previous chain material.

Mailing lists that re-sign mail may add their own ARC set while preserving earlier instances so downstream verifiers can see both the list's authentication and the contributor's.

Verifiers process ARC instances from newest to oldest, checking ARC-Seal signatures and matching ARC-Authentication-Results to the chain they protect.

A valid ARC chain does not override a published DMARC reject policy by itself. It informs the receiver why alignment might fail on the visible From domain.

RFC 8617 defines the experimental status of the protocol. Deployment varies by mailbox provider; some consumers consult ARC only when DMARC fails and forwarding is suspected.