The short answer is nuanced. Authenticated Received Chain (ARC) doesn't directly authenticate a Mail Transfer Agent (MTA) in the way you might think. Instead, it allows an MTA to attest to the authentication results of an email it received, preserving a chain of trust as the message is forwarded. Let's break down what that means.
First, it's helpful to define an MTA. An MTA is essentially a mail server. Its job is to transfer email messages from one computer to another. As the IETF puts it, an MTA is "software that sends and receives email messsages across a network with other MTAs." When you send an email, it hops through several MTAs on its way to the final recipient.
ARC was developed to solve a specific problem that arises during this journey, particularly with what we call indirect mail flows.
The problem of indirect mail flows
Standard email authentication protocols like SPF and DKIM work wonderfully for direct mail. However, they often fail when an email is not sent directly from the original source to the final destination. The most common examples are mailing lists and email forwarding services.
When a mailing list server receives your email and sends it out to all the subscribers, it becomes the new sending MTA. This new MTA is likely not listed in your domain's SPF record, causing the SPF check to fail. The mailing list might also add a footer or prefix to the subject line, which can break the DKIM signature. When SPF and DKIM fail, DMARC fails, and the email might be rejected or sent to spam. This is precisely the issue ARC was designed to fix.
How ARC creates a chain of trust
ARC allows an intermediate MTA, like a mailing list server, to add a new set of headers to the email. These headers effectively say, "I received this email, and when I did, it passed its original SPF and DKIM checks. I may have modified it slightly, but I'm vouching for its original authenticity." This creates a verifiable chain of custody for the email.
This is accomplished by adding three new headers at each 'hop' in the chain:
- ARC-Authentication-Results (AAR): A snapshot of the original authentication results (SPF, DKIM, and DMARC) as seen by the intermediate MTA.
- ARC-Message-Signature (AMS): A DKIM-like signature that covers the entire message content (including headers), plus the AAR header above. This signs the state of the email at that point in the chain.
- ARC-Seal (AS): A DKIM-like signature that validates the previous ARC headers (AAR and AMS). This links the chain together, preventing tampering with previous ARC entries.
When the final recipient's MTA gets the email, it may see that SPF and DKIM are now failing. However, it will also see the ARC headers. It can then validate the entire ARC chain. If the seals are unbroken and the initial AAR header shows a DMARC pass, the MTA can choose to trust the ARC results and override the new DMARC failure, delivering the email to the inbox.
Conclusion: authenticating the chain, not the agent
So, to return to the original question: Does ARC authenticate the Mail Transfer Agent? Not directly. ARC authenticates the chain of events. It allows a receiving server to look back in time and see the original, valid authentication results.
However, each MTA in the chain uses its own private key to sign its part of the ARC headers. In doing so, it is staking its own reputation on the validity of the information it provides. The final recipient has to trust the MTAs in the ARC seal (like Google, Microsoft, etc.) to have done their job correctly. In this sense, ARC is a system where MTAs vouch for an email's journey, preserving its authenticity across systems that would otherwise break it.
