Yes, absolutely. The entire purpose of Authenticated Received Chain (ARC) is to preserve the original email authentication results (SPF, DKIM, and DMARC) as an email travels from its origin to the final recipient. This is especially important when messages pass through intermediate servers, such as mailing lists or forwarding services, which can otherwise break the original authentication.
Think of ARC as a chain of custody for your email's authentication. It doesn't replace protocols like SPF, DKIM, or DMARC; instead, it works with them to ensure legitimate messages don't fail authentication checks just because they were forwarded.
Why is authentication preservation necessary?
The main challenge ARC solves is the fragility of SPF and DKIM when intermediaries are involved. When an email is forwarded or sent through a mailing list, a few things happen that can invalidate its authentication:
- SPF breaks: SPF checks if the IP address sending the email is authorized in the sender's DNS records. A forwarding server sends the email from its own IP, not the original sender's, causing the SPF check to fail.
- DKIM can break: DKIM creates a cryptographic signature of the email's content and headers. Many mailing lists add a footer (like an "unsubscribe" link) or modify the subject line, which alters the message and breaks the DKIM signature.
When either SPF or DKIM fails to align, it can lead to a DMARC failure, and the receiving server might reject the email or send it to spam, even though it was originally a legitimate message.
How ARC preserves the results
ARC solves this problem by adding a new set of headers to the email at each step of its journey. When an ARC-supporting intermediary (like a mailing list server) receives an email, it first performs the standard SPF and DKIM checks. It then records these results in a new ARC-Authentication-Results header.
After recording the results, the intermediary adds its own cryptographic signature (an ARC-Seal and ARC-Message-Signature) before forwarding the email. This process creates a verifiable chain. Each server that handles the email can see the authentication results from all the previous hops. As Vand3rlinden notes, ARC helps preserve the results and verifies the identity of the forwarding servers.
The impact on DMARC and your deliverability
When the final recipient's server gets the email, it may see that the immediate SPF and DKIM checks fail. Ordinarily, this would trigger a DMARC failure. However, if the server supports ARC, it can now look at the ARC chain.
The server can validate the chain of ARC seals to ensure it hasn't been tampered with. If the chain is valid and the server trusts the intermediaries in the chain, it can look back at the very first ARC-Authentication-Results header. If those original results showed a DMARC pass, the server can choose to trust that original assessment and accept the email, even if the current authentication checks fail.
In short, ARC's ability to preserve the original authentication verdict is crucial for modern email deliverability. It allows complex but legitimate email routing to coexist with strict DMARC policies, ensuring your messages reach the inbox without being unfairly penalized for being forwarded.
Does ARC re-authenticate an email?
What is the ARC-Authentication-Results header used for?
Does ARC prevent email spoofing?
What ARC header contains a cryptographically signed copy of the message's state?
Does ARC add a new digital signature to the email?
What ARC header indicates the chain of authentication results?
