Authenticated Received Chain, or ARC, is a crucial email authentication protocol that helps preserve the integrity of email authentication results as a message travels from the original sender to the final recipient. It's particularly important when emails are passed through intermediate servers, like mailing lists or forwarding services, which often break standard authentication methods like SPF and DKIM.
When an intermediary forwards an email, it might change the message content (like adding a footer) or send it from its own servers. These changes can cause the original DKIM signature to become invalid and the SPF check to fail. As a result, a perfectly legitimate email could fail DMARC authentication and be rejected or sent to spam. ARC was developed to solve this problem by creating a verifiable chain of custody.
Understanding the ARC headers
ARC works by adding three new headers to an email at each 'hop' or intermediary server. These headers work together to create the chain.
- ARC-Authentication-Results (AAR): This header captures the original email authentication results (SPF, DKIM, and DMARC) as seen by the intermediary server. It's like a snapshot of the authentication status before any modifications were made.
- ARC-Message-Signature (AMS): This is a DKIM-like signature that covers the entire message, including its headers, but excludes the ARC-Seal header. It essentially signs the state of the message at that specific hop.
- ARC-Seal (AS): This is the most critical header for chain validation. It's a signature that covers the previous ARC headers (the AMS and AAR of the current hop, plus the ARC-Seal of the previous hop). This links each step in the journey, creating the 'chain'.
The process of chain validation
Chain validation is the process a final receiving mail server undertakes to verify the integrity of the ARC headers. The goal is to determine if the chain of custody is intact and trustworthy. If the validation passes, the server can confidently use the original authentication results preserved in the AAR header to inform its delivery decision.
The validation process starts with the most recent ARC set (the one with instance number i=1) and works backwards. The server verifies each ARC-Seal. Since each seal signs the previous set of ARC headers, a valid seal confirms that the information from that hop hasn't been tampered with.
If the server can successfully validate every seal all the way back to the original message, the entire ARC chain is considered 'valid' or 'passed'. This confirms that the authentication results observed by the very first ARC participant, as recorded in the oldest AAR header, are reliable.
Why is chain validation important?
Chain validation is the mechanism that gives ARC its power. Without it, the ARC headers would just be pieces of information with no guarantee of authenticity. By validating the chain, a receiving server can trust the story the headers tell about the email's journey and its original authentication status.
This is especially important for DMARC. A DMARC policy tells a receiver what to do if SPF and DKIM fail. Normally, a forwarded email that fails these checks would be rejected. However, if the receiver can validate the ARC chain and see that the email *originally* passed DMARC, it can choose to override the DMARC policy and deliver the message. It allows email providers to trust that an email is genuine even when it's been forwarded.
In short, ARC chain validation is the linchpin that allows legitimate, forwarded emails to be delivered reliably in a world where DMARC enforcement is increasingly strict. It preserves trust across complex email routing paths, ensuring that important messages aren't lost simply because they passed through an intermediary.
