When we talk about email authentication, standards like SPF, DKIM, and DMARC are often the first to come to mind. These protocols are crucial for verifying a sender's legitimacy and preventing spoofing. However, a common scenario can disrupt these checks: email forwarding. When an email is forwarded through an intermediary server, like a mailing list or an inbox rule, it often undergoes modifications that can break the original SPF and DKIM signatures, leading to DMARC authentication failures.
This is where Authenticated Received Chain (ARC) steps in. ARC was designed specifically to address the challenges posed by legitimate email forwarding. Its primary role is to preserve the authentication results through intermediaries, allowing receiving mail servers to make informed delivery decisions even when an email has been modified after its initial sending.
The core question then arises: does ARC re-authenticate an email? Understanding ARC's function is key to realizing its value in the email ecosystem. It doesn't perform a fresh authentication check on the original sender at each hop. Instead, it creates a verifiable chain of authentication results, essentially vouching for the legitimacy of the forwarding process.
The problem ARC solves
The challenge with email forwarding
Traditional email authentication protocols like SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) work by verifying aspects of the email at the point of initial sending. SPF checks if the sending IP address is authorized by the sender's domain, while DKIM verifies that the email content hasn't been tampered with since it was signed by the originating server. DMARC (Domain-based Message Authentication, Reporting, and Conformance) then builds upon these, instructing receiving servers on how to handle emails that fail SPF or DKIM and align with the From address.
The issue arises because these checks are often broken by intermediaries. When a mailing list modifies the From header or alters the email body (to add a footer, for instance), the original DKIM signature becomes invalid. Similarly, if a forwarded email comes from an IP address not listed in the original sender's SPF record, SPF will fail. Both failures can lead to a DMARC policy of quarantine or reject being applied to an otherwise legitimate email.
This problem has been a significant headache for email deliverability, especially for organizations that rely on mailing lists or internal forwarding systems. Without a mechanism to account for these legitimate changes, many valid emails would end up in spam folders, or worse, be blocked entirely. This is why ARC addresses issues with mailing lists and forwarders.
ARC does not re-authenticate
How ARC preserves authentication state
ARC does not re-authenticate an email in the sense of running a fresh SPF, DKIM, or DMARC check on the original sender at each step of the forwarding chain. Instead, ARC works by encapsulating the email's authentication status at each hop. When a trusted intermediary (an ARC-Sealer) receives an email, it takes the current authentication results (SPF, DKIM, DMARC) and creates a cryptographically signed ARC-Seal and ARC-Message-Signature header before forwarding the message.
Each subsequent ARC-Sealer in the chain adds its own set of these headers, building a verifiable history of authentication results. The final receiving mail server can then inspect this chain. If the latest SPF or DKIM checks fail, the receiver can look at the ARC chain to see if a trusted intermediary vouched for the email's authenticity at an earlier stage. This allows the receiving server to make an informed decision, recognizing that the failures might be due to legitimate forwarding, not malicious spoofing.
This mechanism ensures that the original sender's reputation is preserved throughout the forwarding process. Microsoft Defender for Office 365, for example, configures trusted ARC sealers to reduce inbound email authentication failures. It's a system of trust, where each intermediary signs off on the authentication state it received, creating an audit trail for the email's journey. You can learn more about how to implement ARC and its effects.
Anatomy of an ARC-signed message
Components of the ARC chain
An ARC-enabled email will contain several specific headers that build this chain of trust. These headers work together to provide a comprehensive view of the email's authentication journey, even through multiple intermediaries. Understanding these components is essential to grasp how ARC functions and what ARC header contains a cryptographically signed copy of the message's state.
ARC-Authentication-Results: This header contains the raw Authentication-Results header from the previous hop, as seen by the current ARC-Sealer. It effectively logs the results of SPF, DKIM, and DMARC checks performed by the previous server.
ARC-Message-Signature (AMS): This is a DKIM-like signature that covers important parts of the email message, including immutable header fields and the email body. This signature is created by the ARC-Sealer and allows subsequent servers to verify that the message content and critical headers have not been tampered with since the ARC-Sealer processed it.
ARC-Seal (AS): The ARC-Seal cryptographically covers all the previous ARC headers (AMS and AAR) and some immutable headers. This creates a chain of trust, where each ARC-Sealer signs the entire prior ARC chain, ensuring that no intermediary has maliciously altered the recorded authentication history.
By examining these headers, a receiving mail server can reconstruct the email's authentication journey. Even if the immediate SPF or DKIM checks fail, the presence of a valid ARC chain from trusted intermediaries can signal that the email is legitimate despite the authentication failures caused by forwarding. This ensures that ARC preserves email sender authenticity and does not mean ARC replaces DMARC or SPF/DKIM.
ARC's practical implications
ARC's role in email deliverability and security
ARC plays a vital role in modern email deliverability by ensuring that legitimate forwarded emails reach their intended recipients rather than being mistakenly flagged as spam. Without ARC, many DMARC policies set to p=quarantine or p=reject would cause legitimate emails to be blocked simply because they passed through a forwarding service. As ProtonMail's blog explains, ARC allows receiving mail servers to check an email's authentication results even after forwarding.
Key takeaway on ARC's function
ARC does not directly re-authenticate an email in the traditional sense of SPF or DKIM. Instead, it provides a cryptographically verifiable history of prior authentication results. This allows a receiving email server to trust that the email was legitimately authenticated at an earlier point, even if subsequent forwarding processes broke the original authentication signals.
While ARC significantly improves deliverability for legitimate forwarded emails, it's important to note that it's not a silver bullet against all email threats. For instance, ARC does not prevent email spoofing by malicious actors who haven't passed through a legitimate ARC-Sealer. It relies on the trustworthiness of the intermediaries that apply the ARC headers. For comprehensive email security, DMARC remains the foundational protocol, and ARC acts as an essential supporting layer for specific forwarding scenarios.
Monitoring your DMARC reports is crucial to understand how ARC is impacting your email deliverability. A robust DMARC monitoring tool can show you which emails are passing via ARC, allowing you to fine-tune your policies and ensure maximum deliverability without compromising security. Suped offers a comprehensive platform for DMARC monitoring, with real-time alerts and AI-powered recommendations to simplify managing your email authentication.
Conclusion
The real value of ARC
In summary, ARC's primary function is not to re-authenticate an email at each forwarding step, but rather to attest to the email's authentication status at the point it was last handled by a trusted intermediary. It builds a chain of trust that allows a final recipient to determine if an email, despite appearing to fail traditional authentication checks, was legitimately authenticated earlier in its journey. This ensures that essential emails forwarded by mailing lists or other services are not erroneously rejected, thus improving overall email deliverability. By preserving this critical context, ARC prevents DMARC policies from unfairly penalizing legitimate message flows that undergo typical forwarding modifications.
Microsoft Defender for Office 365, for example, configures trusted ARC sealers to reduce inbound email authentication failures. It's a system of trust, where each intermediary signs off on the authentication state it received, creating an audit trail for the email's journey. You can learn more about how to implement ARC and its effects.
