When an email is forwarded or passes through a mailing list, its authentication can break. This happens because intermediary servers can modify the email, causing SPF to fail due to a change in the sending IP, and DKIM to fail because of alterations to the message body or headers. Authenticated Received Chain (ARC) was developed to solve this problem.
ARC creates a verifiable chain of custody for an email, preserving the initial authentication results across multiple "hops". A receiving server can then look at this chain and make a more informed decision, even if the final SPF and DKIM checks fail. The key to this system is understanding how the validation status is communicated.
The ARC-Seal header and the 'cv' tag
The short answer is that the chain validation status is indicated in the cv tag within the ARC-Seal (AS) header field. The cv tag reports the status of the ARC chain validation from the previous hop.
The cv tag can have one of three values:
- none: This indicates that there were no previous ARC headers to validate. This is the expected status for the very first ARC set added to an email.
- pass: This means the signature in the previous ARC-Seal header was successfully validated, and the chain of custody is intact up to this point.
- fail: This signifies a break in the chain. The previous ARC-Seal header could not be validated, meaning the chain is compromised and should not be trusted.
Understanding the three ARC headers
While the cv tag gives the final verdict for each hop, it works in concert with two other ARC headers. Every participating server in the forwarding chain adds a set of three headers, identified by an instance number (the i tag).
- ARC-Authentication-Results (AAR): This header records the original email authentication results (SPF, DKIM, DMARC) as seen by the first server in the chain. As noted by Stellastra, this header summarizes outcomes like 'pass' or 'fail', giving later servers a clear picture of the initial validation.
- ARC-Message-Signature (AMS): This is a DKIM-like signature that covers the entire message, including the AAR header. It creates a snapshot of the message's state at that specific hop, ensuring that any modifications can be detected.
- ARC-Seal (AS): This is the final piece. The ARC-Seal signs the previous two headers (AAR and AMS) of the current instance, as well as the ARC-Seal header from the *previous* instance. This action links the hops together. By validating this signature, a server confirms that the prior ARC set hasn't been tampered with. The result of this validation is then placed in the cv tag of the *next* ARC-Seal in the chain.
How it works in practice
Imagine an email is sent to a mailing list. The mailing list server is the first hop.
- The mailing list server receives the email and validates its SPF and DKIM, adding an ARC-Authentication-Results header with the results.
- It adds an ARC-Message-Signature to sign the message content.
- It adds an ARC-Seal with i=1 and cv=none, because there's no previous seal to check.
- When the final recipient's server receives the email, it sees the ARC headers. It validates the i=1 ARC-Seal. If it's valid, the server can trust the original authentication results stored in the i=1 AAR header, even if the direct SPF and DKIM checks now fail.
In summary, while the entire ARC protocol involves a set of headers working together, the definitive signal of the chain's integrity at each step is the cv tag in the ARC-Seal header. A cv=pass indicates a healthy, trustworthy chain, allowing receiving mail servers to have confidence in the email's origin.
