Yes, Authenticated Received Chain (ARC) is specifically designed to help legitimate forwarded emails pass DMARC. In fact, that's its primary purpose. DMARC, while powerful for preventing spoofing, has a well-known weakness when it comes to indirect mailflows like mailing lists or email forwarding services. ARC was developed to address this exact problem.
When an email is forwarded, it often breaks the authentication checks that DMARC relies on, SPF and DKIM. This isn't because the email is malicious; it's a technical consequence of the forwarding process. ARC acts as a way to preserve the original, valid authentication results, allowing the final receiving server to see that the email was legitimate before it was forwarded.
The problem with DMARC and forwarding
To understand why ARC is necessary, we first need to look at why forwarding breaks DMARC. DMARC requires that an email passes either SPF or DKIM, and that the domain used in those checks aligns with the domain in the 'From' header.
- SPF breaks: SPF checks if the IP address sending the email is authorized by the domain owner. When a mailing list or forwarder resends your email, it comes from their server, not yours. Their IP address isn't in your SPF record, so the check fails.
- DKIM breaks: DKIM adds a cryptographic signature to the email. If an intermediary, like a mailing list, adds a footer or changes the subject line (e.g., by adding a tag like [MyList]), it alters the content of the email. This alteration invalidates the original DKIM signature, causing the check to fail.
When both of these checks fail, the email fails DMARC. If the original sender has a strict DMARC policy of p=reject or p=quarantine, the legitimate, forwarded email might not reach the final recipient's inbox. As DuoCircle explains, this means legitimate emails can be flagged as spam or rejected.
How ARC creates a 'chain of trust'
ARC works by adding a new layer of authentication headers to an email every time it's processed by an intermediary server. This creates a verifiable sequence of authentication results.
Here's the process:
- The original email is sent and passes DMARC at the first hop (the forwarding server).
- The forwarding server, before modifying and resending the email, records the initial authentication results (e.g., 'DKIM=pass', 'SPF=pass').
- It then cryptographically signs these results and attaches them to the email in a new set of ARC headers (ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal).
- The email is forwarded. The final recipient's mail server receives it and sees that the standard DMARC check fails (as expected).
- However, the server also sees the ARC headers. It can validate the ARC signature and trace the 'chain of trust' back. It sees that the email passed authentication *before* it was handled by the forwarder.
This gives the final server enough information to trust that the email is legitimate and override the DMARC failure, delivering the email to the inbox. Essentially, as GoDMARC notes, ARC helps preserve authentication results across these transfers.
Does ARC replace DMARC?
No, ARC does not replace DMARC. It's a complementary standard that enhances DMARC by fixing its most significant blind spot. You still need a properly configured DMARC policy for your domain. ARC is implemented by the intermediary mail servers (like Google Groups, Proton Mail, and other mailing list providers) to ensure the emails they forward on behalf of DMARC-protected domains don't get unfairly penalized.
For senders, there is nothing you need to configure to 'turn on' ARC. Your responsibility is to have valid DMARC, SPF, and DKIM records. The adoption of ARC is handled by the mailbox providers and forwarding services. The good news is that major providers like Google and Microsoft already support ARC, so your legitimate forwarded messages have a much better chance of being delivered correctly.
