ARC (Authenticated Received Chain)
A signed chain that carries earlier email authentication results through forwarders and mailing lists that may break SPF or DKIM.
See it
What it is
ARC lets a forwarding service or mailing list preserve what it saw before it changed or relayed a message. Each participating hop adds a numbered set of ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers. The next hop validates the existing chain, records its own view, and seals a new set on top.
Reach for ARC when legitimate intermediaries routinely break ordinary authentication. Forwarding usually breaks SPF because the connecting IP changes, and a mailing list footer can break the original DKIM signature. The everyday cases are a Google Group that appends a footer and a university alumni address that forwards mail for life. A final receiver can use a valid ARC chain plus its trust in the intermediary as evidence that the message authenticated before those changes.
ARC records history, not innocence. It does not turn a DMARC failure into a pass, force Gmail to deliver the message, or make an unknown forwarder trustworthy. The chain is useful only when every seal validates and the receiver is willing to trust the service that vouched for the earlier result.
Ask AI for it
Configure OpenARC as a Postfix milter for a forwarding service that already produces trusted RFC 8601 Authentication-Results. Create an RFC 8617 rollout plan that validates any inbound ARC chain, adds one new numbered set containing ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal, and signs with a dedicated DKIM style selector under forwarder.example.com. Show how the OpenARC authserv-id and trusted Authentication-Results source are restricted to this Postfix instance, how failed inbound chains remain recorded as 'cv=fail' instead of being repaired, and how to test a message before and after forwarding. Do not rewrite DMARC to pass or treat a valid ARC chain as automatic permission to deliver.