Authenticated Received Chain, or ARC, is an email authentication protocol designed to address a common problem that arises with modern email security standards like SPF and DMARC. When an email is forwarded or passes through an intermediary like a mailing list, it can often cause the original authentication checks to fail. This is because the forwarding server's IP address doesn't match the original sender's SPF record, and mailing lists can sometimes alter the email's content, which breaks the DKIM signature.
ARC creates a verifiable chain of custody for an email, allowing each server that handles the message to see the authentication results from the previous steps in its journey. This helps the final receiving server make a more informed decision about the email's legitimacy, even if its SPF or DKIM alignment is broken.
The current ARC specification
The current and definitive version of the Authenticated Received Chain protocol is specified in RFC 8617. This document outlines the entire framework, including the syntax of the headers and the process for signing and verifying the chain. While there were earlier drafts, RFC 8617 is the standard that implementations follow.
It is important to note that the status of this RFC is "Experimental". This doesn't mean it's unstable; rather, it indicates that the protocol is being evaluated in real-world environments to gather more data on its effectiveness and potential issues. Despite this status, ARC has seen widespread adoption by major email providers like Google and Microsoft.
ARC headers and versioning
ARC functions by adding three new headers to an email as it passes through a mail transfer agent (MTA) that supports the protocol. These headers work together to create the chain of trust.
- ARC-Authentication-Results (AAR): This header records the email's authentication results (SPF, DKIM, DMARC) as seen by the ARC-signing server. It includes an instance number (i=1) which is incremented by each server in the chain.
- ARC-Message-Signature (AMS): This is a DKIM-like signature that covers the entire message content plus the AAR header. It ensures the message and the initial authentication results haven't been tampered with.
- ARC-Seal (AS): This header contains a signature that covers the previous ARC headers (AAR and AMS), effectively "sealing" them and linking them to the next hop in the chain.
The version of the ARC specification itself is not explicitly numbered in every header, but the process is standardized by RFC 8617. For practical purposes, you can consider the current version to be "1".
Why this matters for email deliverability
The primary benefit of ARC is preserving authentication results across email hops that would otherwise break them. Without ARC, a legitimate email sent through a mailing list could be marked as spam or rejected by the final recipient's server because the mailing list's forwarding breaks SPF.
By implementing and checking ARC headers, a receiving mail server can look back through the chain and see that the email passed DMARC validation at its first hop, before it was forwarded. This provides a strong signal that the message is legitimate, even if the final SPF check fails. It effectively makes DMARC more reliable for senders who rely on mailing lists or other legitimate intermediaries to distribute their messages.
What is the purpose of the ARC-Seal header?
What ARC header field indicates the chain validation status?
What ARC header contains a cryptographically signed copy of the message's state?
What ARC header indicates the chain of authentication results?
What are the three main ARC header fields?
What ARC header contains the list of signed header fields?
