The short answer is no, Authenticated Received Chain (ARC) does not re-authenticate an email in the way that SPF or DKIM initially do. Instead, its primary function is to preserve the original authentication results as an email travels through various servers, like forwarders or mailing lists.
Think of ARC as a system that provides a verifiable “chain of custody” for an email. When an email is forwarded, the forwarding server can break the original authentication. For example, SPF fails because the forwarding server's IP address doesn't match the original sender's SPF record. DKIM can also fail if the forwarder, such as a mailing list, adds a footer to the email, which alters the message body that was originally signed. This is the exact problem ARC was designed to solve.
How does ARC work?
When an intermediary server that supports ARC receives a message, it performs a few key steps before passing it along:
- It validates the initial message. The server checks the original SPF, DKIM, and DMARC authentication results.
- It summarizes the results. It records these original authentication results in a new header, the ARC-Authentication-Results header.
- It signs the headers. The server then creates a cryptographic signature of the message headers, including the new ARC header it just added. This signature is stored in two additional headers: the ARC-Message-Signature and the ARC-Seal.
Each server that forwards the message repeats this process, creating a chain. When the email finally reaches its destination, the recipient's mail server can look at this chain of ARC headers. Even if the final SPF and DKIM checks fail, the server can trace the ARC seals back through the trusted intermediaries. If the seals are valid and the initial ARC-Authentication-Results header showed a pass, the server has a strong reason to trust the message.
So it preserves authentication, it doesn't 're-authenticate'
The key distinction is that ARC doesn't try to make a broken SPF or DKIM pass. It doesn't perform authentication on behalf of the original sender. Instead, it provides a secure wrapper around the original authentication results. As Fastmail explains, ARC tracks an email's authentication state as it passes between servers.
The intermediary server is authenticating its own handling of the message, not the message itself. It's essentially saying, “I received this message, its original authentication status was X, I may have modified it (e.g., by adding a mailing list footer), and I am now passing it on to you. You can trust that I am who I say I am, and this information is accurate.”
This process gives the final receiving server valuable context. Without ARC, a DMARC policy of p=reject would cause a forwarded message to be blocked. With a valid ARC chain, the server can see that the message was legitimate when it was sent and can choose to override the DMARC failure, allowing the email to be delivered to the inbox.
Conclusion
To summarize, ARC doesn't re-authenticate an email. It preserves the initial authentication state and adds a new layer of verification for each hop in the email's journey. It's a vital protocol that works alongside SPF, DKIM, and DMARC to fix a critical blind spot in email deliverability, ensuring that legitimate forwarded emails and mailing list messages aren't incorrectly marked as spam or rejected.
