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.
What is Authenticated Received Chain (ARC)?
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.
The problem ARC solves: Broken authentication
To understand why ARC is necessary, you first have to understand how forwarding can break standard authentication.
- SPF fails: Sender Policy Framework (SPF) checks if the IP address sending the email is authorized by the domain owner. When a mailing list server forwards your email, the recipient sees the mailing list's IP, not yours. This new IP address is likely not in your domain's SPF record, causing the SPF check to fail.
- DKIM fails: DomainKeys Identified Mail (DKIM) adds a cryptographic signature to the email. If anything in the signed parts of the email changes, the signature becomes invalid. Mailing lists often add content, like an unsubscribe link in the footer or a subject line prefix (e.g., [MailingList]), which breaks the DKIM signature.
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.
How the ARC 'chain of custody' works
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 three ARC headers
The ARC protocol is made up of three new email headers added at each hop:
- ARC-Authentication-Results (AAR): This header contains the results of the authentication checks (SPF, DKIM, DMARC) as seen by the intermediary server. It's like a snapshot of the authentication status at that point in time.
- ARC-Message-Signature (AMS): This is a DKIM-like signature that covers the entire message content, including headers. It is added by the ARC-signing server.
- ARC-Seal (AS): This is the crucial header that creates the 'chain'. It signs the previous ARC headers (the AAR and AMS) to prevent tampering. Each new 'AS' header signs the previous set, linking them together.
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?
