The short answer is no. Authenticated Received Chain (ARC) does not replace DMARC, SPF, or DKIM. Instead, it's designed to work alongside them, solving a very specific problem that can cause legitimate emails to fail authentication checks.
To understand why ARC is necessary, we first need to remember what SPF, DKIM, and DMARC do. In short, they are email authentication standards that help receiving mail servers verify that an email is genuinely from the domain it claims to be from. They are the foundation of modern email security, protecting against phishing and spoofing.
However, these systems can run into trouble with what's known as 'indirect mail flows'. This is where an email isn't sent directly from the sender's server to the recipient's server but passes through an intermediary first. The most common examples are mailing lists and email forwarding services.
When an email passes through a forwarding service or a mailing list server, that server might make small changes to the email, like adding a subject line prefix (e.g., [MailingList]) or an unsubscribe footer. These modifications can break the DKIM signature. Furthermore, since the email is now being relayed from the mailing list's server, it will fail the original sender's SPF check. When both SPF and DKIM fail, DMARC subsequently fails, and the receiving server might reject the email or send it to spam, even though it was originally a legitimate message.
How ARC solves the forwarding problem
This is where ARC comes in. ARC was created to preserve the original authentication results as an email passes through intermediaries. It essentially creates a secure chain of custody for the email's DMARC assessment.
As DuoCircle explains, ARC works as an extension of SPF, DKIM, and DMARC to compensate for their shortcomings in these specific scenarios. When an ARC-aware intermediary (like a mailing list server) receives a message that passes DMARC, it does the following:
- Copies the original authentication results: It takes the initial 'pass' results for SPF, DKIM, and DMARC and stores them in a new ARC-Authentication-Results header.
- Signs the message: The intermediary signs the email headers (including the new ARC-Authentication-Results header) with its own ARC signature and seal.
- Forwards the message: It then forwards the email on to its final destination.
When the final receiving server gets the email, the direct SPF and DKIM checks against the original sender's domain will likely fail. However, the server will see the ARC headers. It can then verify the ARC chain, see the original 'pass' result, and decide to trust the message based on the preserved authentication results. This allows legitimate messages to get through without breaking DMARC.
ARC complements, it doesn't replace
It's crucial to understand that ARC is entirely dependent on the initial SPF, DKIM, and DMARC authentication. Without a valid DMARC setup on the original sending domain, ARC has no 'pass' result to preserve. It can't magically make an unauthenticated email secure. ARC only serves to maintain the trust established by the original sender's authentication.
As UniOne states, "ARC does not replace the existing SPF, DKIM, and DMARC authentication protocols. Instead, you use the ARC email protocol to support them." The entire system is built on top of the existing framework laid out in RFC 8617.
In summary, ARC is not a replacement but a vital enhancement. It ensures that your carefully configured DMARC policy continues to work as intended, even when your emails take an indirect route to the inbox. For anyone sending emails that might be forwarded or distributed via mailing lists, understanding ARC is key to ensuring deliverability.
