Email authentication protocols like SPF, DKIM, and DMARC are the foundation of modern email security. They help verify that an email is genuinely from the sender it claims to be from. But they have a significant weakness: they can break when an email isn't sent directly from the sender to the recipient. This happens all the time with legitimate email, especially with forwarding or mailing lists. When authentication breaks, DMARC can fail, and your important messages might end up in the spam folder or get rejected entirely. This is where Authenticated Received Chain (ARC) comes in, providing a way to preserve those initial authentication signals.
ARC stands for Authenticated Received Chain. At its core, it's an email authentication protocol designed to maintain the integrity of SPF and DKIM results even after an email passes through intermediate servers. Think of it as a wrapper around the original authentication verdicts, protecting them as the message travels to its final destination.
The protocol is officially defined by the Internet Engineering Task Force (IETF) in RFC 8617. It doesn't replace DMARC, but rather complements it by giving receiving mail servers more context to make a better delivery decision when DMARC alignment appears to fail due to forwarding.
To understand why ARC is necessary, you first have to understand how forwarding can break standard authentication.
When either of these checks fail, it can cause the DMARC check to fail, signaling to the recipient's mail server that the message might be fraudulent.
The "chain" in Authenticated Received Chain is the key concept. It creates what the official RFC calls an authenticated "chain of custody" for a message.
When an ARC-aware server (like a mailing list) receives an email, it first performs the standard SPF and DKIM checks. It then adds a new set of ARC headers to the email, creating the first link in the chain. These headers contain the results of those checks and a cryptographic signature to seal them. If the email passes through another intermediary, that server will add its own ARC headers, creating a new link in the chain.
The final receiving server can then validate this entire chain of signatures. If the chain is unbroken and trustworthy, the server can look at the authentication results recorded in the very first link. This allows it to trust the original authentication, even if the final SPF and DKIM checks it performs fail.
The ARC protocol is made up of three new email headers added at each hop:
By following this chain, a receiving mail server can make a more informed decision. It can see that while the direct SPF and DKIM checks may have failed, the email was authenticated correctly at an earlier, trusted step in its journey. This makes it far more likely that your legitimate, forwarded emails will land safely in the inbox instead of being flagged as suspicious.
What ARC header field indicates the chain validation status?
What ARC header indicates the chain of authentication results?
What is the 'arc-set' in ARC?
What is the role of the 'chain validation' in ARC?
Does ARC ensure end-to-end encryption?
Does ARC need to be implemented by all mail servers in the chain?