ARC (Authenticated Received Chain): Solving the Forwarding Problem
Email forwarding breaks SPF. This has been a known problem for years, and it creates a real headache for senders who rely on email authentication to maintain deliverability. ARC (Authenticated Received Chain) is the protocol designed to fix this problem, and understanding it matters for anyone whose emails might be forwarded, which is basically everyone.
The Forwarding Problem
SPF works by checking whether the sending IP address matches the authorized addresses in the sender's SPF record. When you send an email from your server to a recipient's server, SPF checks out fine because your server's IP is in your SPF record.
But when the recipient forwards that email to someone else, the forwarding server's IP is what the final destination sees. The forwarding server's IP is not in your SPF record (why would it be?), so SPF fails at the final destination. Your perfectly authenticated email now looks unauthenticated because it went through a forwarding hop.
This affects common scenarios: mailing lists (your email to the list gets forwarded to all subscribers from the list server's IP), corporate email forwarding (many companies forward email from one system to another), and personal forwarding (users who forward their work email to a personal account).
DKIM typically survives forwarding because the signature is attached to the message content, not the sending IP. But if the forwarding server modifies the email (adds a footer, changes headers, reformats content), DKIM can break too.
When both SPF and DKIM fail after forwarding, DMARC fails as well. And if the original sender has p=quarantine or p=reject, the forwarded email gets spam-foldered or rejected at the final destination. The original sender did everything right. The recipient wanted the email forwarded. But the authentication infrastructure breaks down at the forwarding step.
How ARC Solves It
ARC preserves the authentication results from each hop in the email's journey. When a forwarding server processes an email, instead of just passing it along (which breaks SPF), the server creates an ARC record that captures the authentication state at that point in the chain.
The ARC record includes three headers added by each intermediary server:
ARC-Authentication-Results: The authentication results (SPF, DKIM, DMARC) as evaluated by this intermediary. This is essentially a snapshot of the email's authentication state at this hop.
ARC-Message-Signature: A signature over the message headers and body, similar to DKIM but created by the intermediary. This proves the message content was intact when the intermediary processed it.
ARC-Seal: A signature over the ARC headers themselves, creating a chain of custody. Each intermediary signs the previous intermediary's ARC headers, creating an authenticated chain back to the original message.
When the final destination receives the email, it sees that SPF has failed (as expected with forwarding). But it also sees the ARC chain, which shows that the message passed SPF and DKIM at the first hop, the forwarding intermediary has signed the chain, and the message content has not been tampered with between hops.
The final destination can then use the ARC chain to make a more informed delivery decision. Instead of failing DMARC because SPF failed on the final hop, it can see that the original authentication was valid and that a trusted intermediary forwarded the message.
Who Needs to Support ARC
ARC requires participation from intermediary servers, not from the original sender. As a sender, you do not configure ARC on your outgoing email. The forwarding servers in the chain are responsible for creating and signing ARC headers.
The good news is that major email providers already support ARC as intermediaries. Gmail, Microsoft 365, Yahoo, and other major providers add ARC headers when they forward email through their systems. If your email is forwarded through Gmail's infrastructure (for example, through a Google Group or Gmail forwarding rule), ARC headers are added automatically.
As a receiver, the final destination server needs to understand ARC and factor it into DMARC evaluation. Gmail, Microsoft, and Yahoo all support ARC on the receiving side, meaning they consider ARC results when making DMARC pass/fail decisions for forwarded email.
ARC and Mailing Lists
Mailing lists are one of the most impactful use cases for ARC. When you send an email to a mailing list (Google Groups, Mailman, Listserv), the list server receives your email, potentially modifies it (adds a footer, changes the Subject prefix), and resends it to all subscribers.
Without ARC, every subscriber's email server sees the list server's IP (not your IP), which fails SPF. If the list modified the email, DKIM might fail too. The result: your email to a mailing list fails authentication for every subscriber.
With ARC, the list server adds ARC headers that preserve your original authentication results. When the email reaches each subscriber's server, the server sees the ARC chain and knows that the original email was properly authenticated before the list server forwarded it.
This is particularly relevant for B2B communication. Many companies use internal mailing lists and distribution groups. If your cold email reaches someone who has a list-based forwarding rule, ARC helps ensure the forwarded copy maintains authentication at the final destination.
ARC Limitations
ARC is not a guarantee of delivery. It provides information that receiving servers can use, but they are not required to trust ARC headers. A receiving server might choose to ignore ARC data entirely and rely solely on the final-hop SPF/DKIM results.
Trust is also selective. Receiving servers maintain lists of trusted ARC signers. They will trust ARC chains signed by Gmail or Microsoft but might not trust ARC chains from unknown intermediaries. If your email passes through a forwarding server that the final destination does not trust as an ARC signer, the chain does not help.
ARC also does not fix the fundamental problem of unauthorized forwarders. If someone sets up a malicious forwarding service and adds ARC headers to phishing emails, the receiving server should not trust that ARC chain. Trust in ARC is delegated to trust in the intermediary's identity, which is not always verifiable.
What Senders Should Do
As a sender, your direct responsibilities related to ARC are minimal, but there are several things you should be aware of.
First, maintain strong DKIM signing. ARC works best when the original email has valid DKIM that can survive forwarding. DKIM survives content modifications better than SPF, so a strong DKIM configuration is your best insurance against authentication failures in forwarded emails.
Second, be aware that DMARC p=reject can cause issues for forwarded email. If your email is forwarded through a server that does not support ARC, and your DMARC policy is p=reject, the forwarded copy will be rejected at the final destination. This is a known tradeoff of strict DMARC policies.
Third, if you run mailing lists or forwarding infrastructure, implement ARC signing. This helps downstream recipients maintain authentication for emails that pass through your systems. The technical implementation involves configuring your mail server to add ARC headers, which is supported by most modern mail transfer agents.
For cold email specifically, ARC matters when your email gets forwarded by a recipient to a colleague. This is actually a positive outcome. It means the recipient found your email interesting enough to share. ARC helps ensure that the forwarded copy retains authentication at the colleague's mail server, increasing the chance that your email is seen and potentially replied to by an additional decision-maker.
The Broader Authentication Picture
ARC is one piece of the email authentication ecosystem that includes SPF, DKIM, DMARC, and BIMI. Each protocol addresses a specific aspect of email security and trust.
SPF verifies the sending server. DKIM verifies the message integrity. DMARC sets the policy for failures. ARC preserves authentication through forwarding. BIMI provides visual brand trust.
Together, these protocols create a comprehensive authentication framework that protects senders, recipients, and the email ecosystem as a whole. For cold email senders, the practical priority is SPF, then DKIM, then DMARC progression, with ARC and BIMI as awareness items rather than action items. ARC works in the background, supported by the intermediary infrastructure, and benefits you automatically when your emails are forwarded through ARC-capable systems.
The most important takeaway: proper DKIM signing is your best defense against authentication failures in forwarded email, with or without ARC. Make sure DKIM is configured correctly for every sending service, and the forwarding problem becomes significantly less impactful for your deliverability.
