When talking about email authentication, we often focus on standards like SPF, DKIM, and DMARC. These are fantastic for verifying a sender's identity, but they have a weakness: they can break when an email is forwarded or passes through an intermediary like a mailing list. This is where Authenticated Received Chain, or ARC, comes in. ARC is an email protocol designed to preserve authentication results across the entire delivery path, even when intermediaries are involved.
Understanding ARC sets
When an email passes through a system that supports ARC, like a mailing list server, that server performs its own DMARC validation. It then "stamps" the email with the results of that check before forwarding it on. This stamp takes the form of a group of new email headers. This group of headers is collectively known as an 'ARC Set'.
An ARC set essentially captures a snapshot of the email's authentication status at a specific point in its journey. As explained by Proton, this process helps a recipient's mail server trust that the authentication information is reliable, even if the final SPF and DKIM checks fail due to the forwarding process. Each ARC set is composed of three distinct headers:
- ARC-Authentication-Results: Records the initial authentication results (SPF, DKIM, DMARC) as seen by the intermediary.
- ARC-Message-Signature: A DKIM-like signature that covers the message content and the ARC-Authentication-Results header, proving they have not been altered.
- ARC-Seal: Another DKIM-like signature that covers the previous ARC headers, creating a verifiable chain.
The purpose of the 'arc-instance' (i=) tag
So, how does a receiving mail server know which ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers belong together? This is where the 'arc-instance' field comes into play. It is not a header itself, but a critical tag within each of the three ARC headers.
The instance is identified by the i= tag. It is a simple integer that acts as a unique identifier for a specific ARC Set. The first intermediary to add an ARC set uses i=1. If the email is then passed to a second ARC-aware intermediary, that system adds a new ARC set using i=2, and so on. This creates a sequential, verifiable chain.
According to the official IETF specification for ARC, this instance tag is the glue that binds the individual headers of an ARC set together. Without it, you would just have a collection of disconnected headers, making it impossible to validate the chain.
Why is the instance tag important?
The arc-instance tag is fundamentally important because it allows a receiving mail server to reconstruct the email's journey. Imagine an email sent from a user, which goes through their company's mailing list, and is then automatically forwarded by a recipient's personal account.
In this scenario, two ARC sets would be added. The mailing list would add the first set, with each header containing i=1. The personal account's forwarder would add a second set, with each header containing i=2. The final recipient's server can then verify the i=2 seal, which validates the integrity of the i=1 headers. It can then verify the i=1 seal, which validates the original authentication results. This chain of trust, made possible by the instance tag, allows the server to confidently accept a message that would otherwise have failed DMARC.
