Yes, absolutely. Authenticated Received Chain (ARC) was created specifically to solve the authentication problems that arise when emails are forwarded or sent through mailing lists. These scenarios have historically been a major headache for DMARC, as they can cause legitimate emails to fail authentication checks.
Before we get into how ARC fixes this, it's important to understand why this problem exists in the first place.
The problem with forwarders and mailing lists
Standard email authentication protocols like SPF and DKIM work wonderfully for emails sent directly from a sender to a recipient. DMARC sits on top of these, using their results to decide if an email is authentic. The issue arises when an intermediary server gets involved, like a mailing list server or an email forwarder.
- SPF breaks: SPF checks if the IP address sending the email is authorized in the sender's DNS records. When an email is forwarded, it's no longer sent from the original IP but from the forwarder's IP. This new IP is not listed in the original sender's SPF record, causing the SPF check to fail.
- DKIM breaks: DKIM creates a digital signature that covers parts of the email, like the body and certain headers. Mailing lists often modify emails by adding a subject line prefix (e.g., [MailingList]) or an unsubscribe footer. These modifications alter the content, which invalidates the DKIM signature, causing it to fail.
Since DMARC requires either SPF or DKIM (or both) to pass and align, a failure in both means a DMARC failure. This can result in legitimate, forwarded emails being rejected or sent to spam. As LuxSci notes, ARC was defined to handle these specific shortcomings.
How ARC provides the solution
ARC works by creating a 'chain of custody' for an email's authentication results as it travels through different hops. Think of it as a log that preserves the original authentication status.
When an intermediary server, like a mailing list, receives an email, it first performs the standard SPF, DKIM, and DMARC checks. Let's assume the email passes. The mailing list server then makes its modifications, which will break the original DKIM signature. Before forwarding the email, however, it does something crucial: it attaches a new set of ARC headers to the email. These headers contain:
- The results of the original authentication checks (e.g., 'dmarc=pass').
- A new ARC signature, which cryptographically signs the original authentication results and parts of the email.
When the final receiving server gets the email, it will see that the direct SPF and DKIM checks fail. But then it sees the ARC headers. It can verify the ARC chain and see that the email was genuine when it was received by a trusted forwarder (like Google Groups or ProtonMail). This allows the receiver to trust the ARC results and override the DMARC failure, delivering the email correctly.
An extension, not a replacement
It is important to view ARC as a necessary extension of the existing DMARC framework, not a replacement for it. Your primary email authentication still relies on setting up SPF, DKIM, and DMARC correctly. ARC steps in to handle the complex mail flows where DMARC alone falls short. As DuoCircle puts it, ARC works as an extension to compensate for the shortcomings of SPF, DKIM, and DMARC.
By preserving the chain of authentication, ARC provides the context needed for receiving mail servers to make better delivery decisions, ensuring that legitimate forwarded emails and mailing list messages reach the inbox.
