RFC 8617

ARC: Authenticated Received Chain

ARC lets a forwarder vouch for the authentication state of a message it received, so the next hop can trust the upstream verdict even when SPF and DKIM are broken by forwarding.

TL;DR

Forwarders add three ARC headers per hop: ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results.
Each hop's instance number (i=) increases by one.
Final receivers can honour the upstream auth verdict via cv=pass on the most recent seal.

What it does

ARC is the answer to 'my mailing-list provider rewrites every message and DMARC fails because of it.' Without ARC, the final receiver sees broken SPF and broken DKIM and either rejects the message (at p=reject) or quarantines it.

With ARC, the upstream forwarder writes a signed record of what it observed before forwarding (e.g. 'when I received this, DKIM passed and aligned to yourdomain.com'). The final receiver can verify the ARC chain end-to-end and choose to honour that upstream verdict.

ARC is now widely supported on the receiving side (Google, Microsoft, Yahoo all add ARC headers and trust ARC chains from each other) and on the forwarding side (most modern mailing-list managers and many corporate forwarders).

How it works

When a forwarder receives a message, it captures the current SPF/DKIM/DMARC verdict in an ARC-Authentication-Results header.
The forwarder also signs a copy of the message with ARC-Message-Signature and seals the entire ARC chain with ARC-Seal.
Each hop along the path increments the i= instance number on its own three headers.
The final receiver walks the chain, verifies each seal, and reads the cv= (chain validation) result on the most recent seal. cv=pass means the chain is intact.
If the chain validates AND the most upstream Auth-Results showed a pass aligned to your domain, the receiver can accept the message even though SPF/DKIM at the final hop fail.

Example record

(headers added per-message by forwarders)

No DNS record needed; ARC headers are added per-message by forwarders that support it.

Common pitfalls

Assuming ARC fixes DMARC for you. ARC only helps when both the forwarder AND the final receiver support it; if either side is older, you still see DMARC fail.
Counting on ARC for security. ARC is a trust signal, not a verification — it says 'the upstream said this passed,' not 'I verified.' Don't drop your DMARC policy because of it.
Ignoring broken chains. cv=fail on a seal means the chain's been tampered with; treat that as suspicious, not as 'just broken.'

Want PhishFence to monitor ARC for your domains?