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.
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:
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.