The short answer is not directly, but it plays a critical role in preserving the original authentication results. Authenticated Received Chain (ARC) is not a standalone authentication protocol like SPF, DKIM, or DMARC. Instead, it's designed to work alongside them.
Its main job is to fix a common problem in the email world: what happens when a fully authenticated email is forwarded? In many cases, this forwarding process breaks the original authentication, causing a legitimate email to fail DMARC checks and potentially land in spam or be rejected.
ARC provides a way for receiving mail servers to see the email's authentication history, even after it has passed through intermediate servers like mailing lists or forwarding services.
The problem ARC was built to solve
To understand ARC's importance, you first need to understand how standard email authentication can fail. The three pillars of email authentication are SPF, DKIM, and DMARC.
- SPF (Sender Policy Framework) checks if the IP address sending the email is authorized to send on behalf of your domain.
- DKIM (DomainKeys Identified Mail) adds a digital signature to the email, which proves the message hasn't been tampered with in transit.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers what to do with emails that fail SPF or DKIM checks.
This system works well for direct mail, but problems arise with intermediaries. When you send an email to a mailing list, the mailing list server receives it and then sends it out to all subscribers. This forwarding server is not listed in your domain's SPF record, so SPF fails. The mailing list might also add a footer to your email, which modifies the message and breaks the DKIM signature.
The result? A perfectly legitimate email now fails both SPF and DKIM, leading to a DMARC failure. Your important message gets flagged as suspicious.
How ARC preserves authenticity
ARC solves this by creating a chain of custody for email authentication results. When an ARC-supporting server (like a mailing list) receives an email, it first performs the standard SPF and DKIM checks.
Before forwarding the email, it adds a new set of headers, the ARC headers. These headers essentially say, "I received this email, and here are the authentication results I saw." This information is cryptographically signed. As vand3rlinden.com explains, ARC sealing helps ensure the authenticity of email messages as they pass through various servers.
When the final recipient's server gets the email, it sees that SPF and DKIM have failed. However, it also sees the ARC headers. The server can then:
- Verify the ARC signature to ensure the headers haven't been tampered with.
- Check the original authentication results recorded in the ARC headers.
- Decide if it trusts the intermediary server (the ARC "sealer") that added the headers.
So, does it ensure authenticity?
This brings us back to the original question. ARC doesn't authenticate the original sender. DMARC, based on passing SPF or DKIM, does that. What ARC does is authenticate the intermediaries that handle the email.
The final decision rests with the receiving server. If it receives a forwarded message that fails DMARC but has a valid ARC chain from a trusted source like Google or Microsoft, it's very likely to trust the chain and deliver the email. It trusts that Google correctly validated the original sender before forwarding. This concept of a Trusted ARC sealer is fundamental to how ARC works.
In conclusion, while ARC does not directly authenticate the sender, it provides a vital mechanism for preserving the original, authentic sender information across complex email routes. It acts as a trusted wrapper around the original authentication results, allowing DMARC to function reliably even in the face of forwarding. By doing this, it significantly helps in verifying that an email is genuinely from who it claims to be from, even if it didn't arrive directly.
