The three ARC header fields explained
As defined in RFC 8617, Authenticated Received Chain (ARC) adds three new header fields to an email. These headers work together to create a verifiable chain of custody for an email's authentication results, even as it passes through different email servers.
Let's break down what each of these three headers does.
1. ARC-Authentication-Results (AAR)
The AAR header is the first part of the chain. When an email intermediary, like a mailing list server, receives a message, it performs the standard authentication checks: SPF, DKIM, and DMARC. The ARC-Authentication-Results header is then added to the email to record these results. It essentially takes a snapshot of the email's authentication status at the moment it was received by the intermediary.
This header includes an instance tag (e.g., i=1) which indicates its position in the chain. If an email passes through multiple intermediaries, each one will add its own set of ARC headers, incrementing the instance number.
2. ARC-Message-Signature (AMS)
The ARC-Message-Signature is a cryptographic signature, similar in concept to a DKIM signature. Its job is to verify that the message content and the AAR header haven't been altered since the intermediary processed the email. The AMS signs a selection of the email's headers (like From, To, and Subject) and the entire message body. Crucially, it also signs the AAR header that was just added.
This step ensures the integrity of the captured authentication results. Without it, a malicious actor could potentially change the AAR header to make a failed email look like it passed.
3. ARC-Seal (AS)
The ARC-Seal is the final piece of the puzzle for each intermediary. It's another cryptographic signature, but this one validates the integrity of the entire ARC header set created by that specific server. The AS signs the AAR and AMS headers that were just added.
By sealing the previous two ARC headers, the AS provides a guarantee that the recorded authentication results (in the AAR) and the signature of the message (the AMS) belong together and have not been tampered with. This completes the 'chain' for that specific hop.
How the ARC headers form a chain
When the final recipient's email server receives the message, it may see that SPF and DKIM fail due to modifications made by the intermediary. However, it will also see the ARC headers. The server can then validate the ARC chain, starting from the last instance and working backwards.
What is ARC (Authenticated Received Chain)?
Authenticated Received Chain, or ARC, is an email authentication protocol that helps preserve email authentication results when an email is forwarded. This is a common issue with indirect mailflows, such as when using mailing lists or forwarders, where SPF and DKIM checks can fail even for legitimate emails. ARC works by adding a new set of headers to an email, creating a verifiable 'chain of custody' for its authentication history.
By checking the ARC chain, the final recipient's mail server can see the original, valid authentication results and make a more informed decision about whether to trust the message, improving deliverability for forwarded mail.
The ARC validation process
The process works like this:
- Validate the ARC-Seal: The server checks the most recent AS to ensure the integrity of the AAR and AMS headers from the last hop.
- Validate the ARC-Message-Signature: If the seal is valid, it then checks the AMS to ensure the message content and AAR header are unmodified.
- Trust the ARC-Authentication-Results: If both signatures are valid, the server can now trust the results contained within the AAR header, which reflects the email's original authentication status.
In short, these three headers work in concert to provide a secure and verifiable record, allowing receiving mail servers to understand an email's history and trust its origins, even when it hasn't arrived directly from the sender.
What is the purpose of the ARC-Seal header?
What ARC header field indicates the chain validation status?
What is the 's=' tag in an ARC-Seal header?
What ARC header contains a cryptographically signed copy of the message's state?
What is the 'i=' tag in an ARC-Seal header?
What ARC header indicates the chain of authentication results?
