The ARC-Seal header is a crucial component of Authenticated Received Chain (ARC), an email authentication protocol designed to solve a very specific, but common, problem. In modern email, DMARC is the standard for preventing spoofing. It works by checking that an email's sending domain aligns with what's verified by SPF and DKIM. However, this system can break down when an email is passed through an intermediary, like a mailing list or a forwarding service.
These intermediaries often make small changes to the email, such as altering the 'From' header or adding a footer. These modifications can cause DMARC, SPF, or DKIM checks to fail at the final destination, even if the email was legitimate to begin with. This is where ARC comes in.
Defined in RFC 8617, ARC creates a chain of custody for an email, allowing each server that handles the message to see the authentication results from the previous hops. The ARC-Seal header is what holds this chain together.
The three ARC headers
When an intermediary server processes an email, ARC adds three distinct headers to the message to preserve the original authentication results. This is the core of how ARC works.
- ARC-Authentication-Results: This header records the original email authentication results (SPF, DKIM, and DMARC) as seen by the intermediary. For example, if the original DMARC check passed, this header will note that.
- ARC-Message-Signature: This is a DKIM-like signature that covers the entire message, including any modifications made by the intermediary. This signature effectively says, 'This is what the message looked like when I, the intermediary, was done with it.'
- ARC-Seal: This header is a cryptographic signature that covers the previous ARC-Authentication-Results and ARC-Message-Signature headers. This is the critical piece that connects each step in the chain.
The specific purpose of the ARC-Seal
The main purpose of the ARC-Seal header is to validate the integrity of the other ARC headers added by a specific intermediary. Think of it as a tamper-proof seal. It verifies that the ARC-Authentication-Results and ARC-Message-Signature for a particular hop in the email's journey have not been altered.
Each ARC-Seal header includes an instance tag (i=1, i=2, etc.) that indicates its place in the sequence. The first intermediary adds a set of headers with i=1. If the email passes through a second intermediary, that server will add a new set of ARC headers, with its ARC-Seal having an i=2 tag. This seal also signs the ARC-Seal from the previous hop (i=1), creating a verifiable chain.
How the ARC-Seal builds a chain of trust
When a final recipient's mail server receives an email, it may see that the DMARC check fails. Normally, this could lead to the email being rejected or sent to spam. However, if ARC headers are present, the server can perform an additional check.
The server will validate the ARC chain, starting with the newest ARC-Seal and working its way backward. It checks the cryptographic signature of each seal. If the chain is intact and the server trusts the domains that sealed the chain (the intermediaries, or 'trusted ARC sealers'), it can look at the original ARC-Authentication-Results from the very first hop.
If those original results show a 'pass' for DMARC, the recipient server can choose to override its own local DMARC failure and deliver the message to the inbox. The ARC-Seal is the mechanism that makes this trust possible. Without it, there would be no way to verify that the reported authentication results from the intermediaries are legitimate.
In summary, the ARC-Seal acts as the connective tissue for email authentication. It allows DMARC results to survive the journey through forwarding services and mailing lists, ensuring that legitimate emails still have a high chance of reaching the inbox. It's a critical innovation for maintaining strong deliverability in a complex email ecosystem.
