Authenticated Received Chain, or ARC, is a crucial email authentication protocol that helps preserve email authentication results when a message is forwarded. This is a common scenario with mailing lists or complex routing systems where standard protocols like SPF and DKIM can break. When an email is forwarded, the server that forwards it often becomes the new sending source in the eyes of the final receiving server. This change can cause SPF alignment to fail. Similarly, some forwarders might alter the email's content or headers, which would invalidate the DKIM signature.
ARC solves this problem by creating what the IETF calls an authenticated "chain of custody" for a message. It allows each server that handles the email to add a new layer of authentication, attesting to the results it saw. But how does it store this chain of results? It uses a set of specific email headers.
The core ARC headers
The ARC protocol is defined in RFC 8617 and introduces three new email headers that are added by each intermediary (or "ARC Sealer") that processes the message. These headers work together to create the verifiable chain.
- ARC-Authentication-Results (AAR): This is the header that directly answers our question. It contains the authentication results (SPF, DKIM, DMARC) as seen by the intermediary server at that specific hop. It includes an instance number to indicate its position in the chain.
- ARC-Message-Signature (AMS): This is a DKIM-like signature that signs the entire message, including its headers, but it notably also includes the ARC-Authentication-Results header in its signature. This validates that the AAR header hasn't been tampered with.
- ARC-Seal (AS): This header signs the previous ARC headers in the chain, essentially "sealing" them and ensuring the integrity of the entire chain of custody.
The ARC-Authentication-Results header explained
The header that specifically indicates the chain of authentication results is the ARC-Authentication-Results header. Each time an ARC-aware mail server processes the email, it adds a new AAR header with a unique instance number.
The instance is specified by the i= tag. The first server in the chain adds an AAR header with i=1. The next server adds another AAR header with i=2, and so on. This creates a numbered, ordered sequence of authentication checks.
A receiving server can look at these headers, starting from the highest instance number, and trace the authentication results back through the message's journey. If the ARC-Seal validates each step, the receiver can trust the initial i=1 results, even if SPF and DKIM fail at the final destination.
How ARC establishes trust
While the ARC-Authentication-Results header holds the results, it's the combination of all three headers that makes the system trustworthy. As a message is forwarded, each intermediary server:
- Evaluates the message's authentication status (SPF, DKIM, DMARC) and the validity of any existing ARC headers.
- Adds a new ARC-Authentication-Results header with its findings.
- Creates a new ARC-Message-Signature to sign the message content and its new AAR header.
- Creates a new ARC-Seal to sign the previous headers, thus vouching for the integrity of the chain up to that point.
In essence, the ARC-Authentication-Results header is the logbook, recording what happened at each stop. The other two headers, AMS and AS, are the cryptographic proof that the logbook is accurate and hasn't been forged. This system allows a final recipient like Google or Microsoft to see that an email, despite failing SPF or DKIM on final delivery, was legitimately authenticated at an earlier point in its journey by a trusted forwarder.
What is the purpose of the ARC-Seal header?
Does ARC re-authenticate an email?
What ARC header field indicates the chain validation status?
What is the 's=' tag in an ARC-Seal header?
What is the ARC-Authentication-Results header used for?
What ARC header contains a cryptographically signed copy of the message's state?
