The short answer is no, not every single mail server in the chain needs to implement Authenticated Received Chain (ARC). ARC is specifically designed to solve a problem that arises when emails pass through intermediary servers, like mailing lists or forwarding services.
When an email travels directly from a sender to a recipient, standard authentication protocols like SPF, DKIM, and DMARC work perfectly well. The trouble starts when a middleman gets involved. These intermediaries can unintentionally break the authentication chain, causing legitimate emails to fail DMARC checks and potentially land in spam.
ARC's purpose is to preserve the original authentication results, allowing the final receiving server to see that the email was valid before it was forwarded.
Why forwarding breaks email authentication
To understand who needs ARC, we first need to understand why forwarding is a problem for DMARC. When an email is forwarded or passed through a mailing list, two key things can happen that break authentication:
- SPF fails: SPF checks if the IP address sending the email is authorized by the domain in the "From" address. A forwarding server sends the email from its own IP, which is almost never listed in the original sender's SPF record. This causes an immediate SPF failure.
- DKIM fails: DKIM uses a cryptographic signature to verify that the message content hasn't been altered. Mailing lists often add content, like an "[unsubscribe]" link in the footer. This modification changes the message body, which breaks the DKIM signature.
When both SPF and DKIM fail, the email will subsequently fail DMARC. The receiving server, seeing the DMARC failure, might reject the message or send it to spam, even though it was originally a legitimate email. As Mailgun points out, ARC is designed to address these specific authentication challenges.
So, who should implement ARC?
ARC implementation is a tale of two parties: the intermediaries that modify messages and the final recipients that validate them.
1. Intermediary Mail Servers
These are the actors who need ARC the most. Any service that sits between the original sender and the final recipient and might alter the email should implement ARC. This includes mailing list providers, email forwarders, and certain security gateways. By adding ARC headers, they take responsibility for the changes they make. They essentially say, "Yes, DMARC for the original sender will now fail, but we've validated the original authentication results, and here is our signature to prove it." Cloudflare's Email Routing service is a perfect example of an intermediary that uses ARC to preserve authentication.
2. Receiving Mail Servers
For ARC to have any effect, the final mail server must be able to read, validate, and trust the ARC chain. If a receiver doesn't support ARC, the headers are simply ignored, and the DMARC failure will be treated as definitive. Fortunately, major inbox providers like Gmail and Microsoft 365 support ARC, so they can use this information to make better filtering decisions.
What about the original sender?
The original sender doesn't need to implement ARC. Their responsibility is to have a robust email authentication setup with SPF, DKIM, and a DMARC policy in place. ARC is not a replacement for these foundational protocols; it works as an extension of them.
Conclusion
In summary, ARC does not need to be implemented by all mail servers in a chain. Its role is highly specific. The primary responsibility falls on intermediary services that forward or modify emails. They must sign the message with ARC to preserve the original authentication verdict. On the other end, receiving mail servers must be configured to validate this ARC chain to make more intelligent deliverability decisions.
For the average sender, the focus should remain on a correct and secure DMARC setup. ARC operates in the background to help ensure your properly authenticated emails reach their final destination, even when the path isn't a straight line.
