When we talk about email authentication, we often focus on SPF, DKIM, and DMARC. These protocols are fantastic for verifying a sender's identity, but they can run into trouble when an email passes through an intermediary, like a mailing list or a forwarding service. This is where Authenticated Received Chain, or ARC, comes in. ARC preserves the original authentication results, and the 'arc-set' is the fundamental building block of this system.
An 'arc-set' is a collection of three headers that are added to an email by each server (or "hop") that handles it after the original sender. Think of it as a single entry in a passport, stamped at each border crossing. Each set contains the authentication results from that specific hop, and it's cryptographically sealed to ensure it hasn't been tampered with.
What makes up an arc-set?
Each 'arc-set' is composed of a specific group of headers, each serving a distinct purpose. This grouping is why it's referred to as a "set". According to the official IETF RFC 8617 specification, the process involves collecting all ARC sets attached to a message. This collection of sets creates the chain of custody.
The three headers in every arc-set are:
- ARC-Authentication-Results (AAR): This header is similar to the standard Authentication-Results header. It records the results of SPF, DKIM, and DMARC checks as seen by that intermediary server. It also includes an instance tag, i=1, which indicates it's the first hop.
- ARC-Message-Signature (AMS): This is a DKIM-like signature that covers the message content and some headers. It's signed by the intermediary server (e.g., the mailing list). This signature allows the final recipient to verify that the message content hasn't been altered since this specific hop. It also includes the instance tag i=1.
- ARC-Seal (AS): This is the crucial header that connects the sets into a chain. The ARC-Seal signs the previous two ARC headers (AAR and AMS) in the current set, as well as the ARC-Seal from the previous set (if one exists). This creates a verifiable, ordered chain. This header also contains the instance tag i=1.
How the sets form a chain
When a second intermediary handles the email, it will add its own 'arc-set' with an instance tag of i=2. Its ARC-Seal (AS) will sign its own AAR and AMS headers, but it will also sign the ARC-Seal from the first set (i=1).
When the final mail server receives the message, it may see that SPF and DKIM fail because the email now comes from the last intermediary, not the original sender. However, it can validate the entire ARC chain. It starts with the highest instance number (i=2) and works its way down to i=1. If all the seals are valid, it can trust the authentication results recorded in the very first 'arc-set' (i=1), which show the original sender's authentication passed. This allows the email to be delivered successfully, even though it passed through systems that broke the direct authentication path.
