Every email administrator has faced this support ticket: "I forwarded an important email to my colleague, and it went to their spam folder. Why?" The answer involves one of email's most frustrating edge cases—the way forwarding breaks authentication.
When you forward an email, you're essentially re-sending it from a different server. The original SPF record authorized the sender's server, not yours. The original DKIM signature covered the exact message content, which forwarding often modifies. By the time the email reaches its final destination, every authentication check fails. The message looks like a forgery, even though it's completely legitimate.
ARC—Authenticated Received Chain—was designed to solve this problem. It creates a chain of custody for authentication results, allowing each server that handles a message to vouch for what it saw.
Why forwarding breaks authentication
To understand ARC, you need to understand exactly how forwarding breaks things.
SPF checks whether the sending server's IP address is authorized for the domain in the envelope 'from' address. When you forward an email, your server becomes the sender. Your IP isn't in the original sender's SPF record, so SPF fails. This is working as designed—SPF is supposed to fail when an unauthorized server sends mail.
DKIM is trickier. A DKIM signature covers specific parts of the message, typically including the body and certain headers. Many forwarding systems modify messages: adding footers, changing subject lines, wrapping content. Any modification invalidates the signature. Even if the forwarder doesn't modify anything, some DKIM implementations are fragile enough that minor changes in whitespace or header ordering break validation.
DMARC ties these together. If both SPF and DKIM fail, DMARC fails. And if the original sender has a strict DMARC policy (p=reject), the forwarded message gets rejected entirely. The recipient never sees it.
This creates a real problem. Mailing lists, email forwarding services, and corporate mail routing all involve legitimate forwarding. Without a solution, strict authentication policies would break huge swaths of normal email usage.
How ARC works
ARC doesn't fix SPF or DKIM—it works alongside them. The idea is simple: each server that handles a message records what it observed and signs that record. Downstream servers can then see the full history of authentication results.
When a message arrives at an ARC-enabled server, the server performs normal authentication checks: SPF, DKIM, DMARC. It then creates three new headers.
The ARC-Authentication-Results header records what the server observed. Did SPF pass or fail? Did DKIM validate? What was the DMARC result? This is essentially a snapshot of authentication status at this point in the message's journey.
The ARC-Message-Signature header is a DKIM-like signature covering the message content. This lets downstream servers verify that the message hasn't been modified since this server handled it.
The ARC-Seal header ties everything together. It signs the ARC headers themselves, creating a tamper-evident chain. Each server adds its own set of ARC headers, incrementing a sequence number, and signs over all previous ARC headers plus its own.
The result is a chain of custody. The final recipient can see: "Server A received this message and SPF passed. Server B forwarded it and DKIM was still valid. Server C is delivering it now." Even if current authentication fails, the chain shows that authentication was valid earlier.
ARC in practice
Let's trace a real scenario. You send an email from your company domain to a mailing list. The list forwards it to all subscribers.
Your email leaves your server with valid SPF and DKIM. It arrives at the mailing list server. The list server checks authentication—everything passes. It adds ARC headers recording these results and signs them.
The list server then forwards the message to subscribers. In doing so, it adds a footer and changes the envelope sender (so bounces come back to the list, not you). These changes break your original DKIM signature and make SPF fail.
When the message arrives at a subscriber's mail server, current authentication fails. But the server sees the ARC chain. It can verify the ARC signatures and see that when the mailing list received the message, authentication passed. If the server trusts the mailing list (based on its reputation), it can accept the message despite current authentication failures.
This is the key insight: ARC doesn't automatically make forwarded mail trusted. It provides information that receiving servers can use to make better decisions. Trust still depends on the reputation of the intermediaries.
Implementing ARC
If you run a mail server that forwards messages—a mailing list, a forwarding service, or corporate mail routing—you should implement ARC. You're the one breaking authentication; you should provide the chain of custody that helps recipients trust the result.
Most modern mail server software supports ARC. Postfix, Exim, and Microsoft Exchange all have ARC capabilities. The configuration typically involves generating a key pair (similar to DKIM), publishing the public key in DNS, and enabling ARC signing in your server configuration.
The DNS record looks like a DKIM record because it essentially is one. ARC uses the same key format and validation mechanism. You publish a TXT record at a selector._domainkey.yourdomain.com containing your public key.
For receiving servers, ARC validation is usually automatic if your software supports it. The decision of whether to trust ARC results—and which intermediaries to trust—is a policy decision. Most servers use reputation data: if a well-known mailing list operator signs an ARC chain, that carries more weight than an unknown server.
ARC's limitations
ARC isn't a silver bullet. It has real limitations you should understand.
First, ARC requires trust in intermediaries. If a malicious server adds fake ARC headers claiming authentication passed, downstream servers might be fooled. This is why reputation matters—you shouldn't trust ARC chains from unknown or low-reputation sources.
Second, ARC doesn't help if the first hop is malicious. If an attacker sends a spoofed message directly to a mailing list, the list will faithfully record that authentication failed and forward it anyway. ARC preserves authentication results; it doesn't create authentication where none existed.
Third, adoption is still incomplete. While major providers like Google and Microsoft validate ARC, many smaller mail servers don't. Your carefully constructed ARC chain might be ignored entirely.
Finally, ARC adds complexity. More headers, more signatures, more things that can break. Debugging delivery problems becomes harder when you need to trace through multiple layers of ARC validation.
ARC and DMARC interaction
The relationship between ARC and DMARC is important. DMARC policies tell receivers what to do when authentication fails. ARC provides additional context that might change that decision.
When a message fails DMARC but has a valid ARC chain showing earlier authentication success, the receiver faces a choice. Strictly following DMARC policy would reject the message. But the ARC chain suggests it's legitimate mail that was forwarded.
Most receivers that support ARC will override DMARC failures for messages with trusted ARC chains. This is the whole point—allowing legitimate forwarded mail through despite authentication failures. But this is a local policy decision, not a standard requirement.
If you're a domain owner with a strict DMARC policy, understand that ARC might cause your policy to be overridden for forwarded mail. This is generally what you want—you probably don't want your emails rejected just because someone forwarded them. But if you have specific security requirements, you should understand this interaction.
Should you care about ARC?
If you operate mail infrastructure that forwards messages, yes. Implementing ARC is good citizenship—you're helping the email ecosystem work better.
If you're just sending email from your domain, ARC is less directly relevant. You don't need to do anything special; ARC is handled by intermediaries. But understanding ARC helps you debug delivery problems when your emails are forwarded.
If you're evaluating email deliverability, knowing about ARC helps explain why some forwarded messages succeed and others fail. A message forwarded through a major provider with good ARC implementation will fare better than one forwarded through a small server without ARC support.
Frequently asked questions
Does ARC replace DKIM?
No. ARC complements DKIM. You still need DKIM on your outgoing messages. ARC helps preserve authentication results when messages are forwarded and DKIM signatures break.
Can I implement ARC without DKIM?
Technically yes, but it doesn't make much sense. ARC is designed to preserve authentication results, including DKIM. If you're not doing DKIM, there's less to preserve.
How do I know if my emails are being ARC-signed when forwarded?
Check the headers of forwarded messages. Look for ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers. These indicate ARC processing occurred.
Does Gmail support ARC?
Yes. Google was one of the primary developers of ARC and fully supports both signing and validation. Messages forwarded through Gmail will have ARC headers, and Gmail considers ARC chains when evaluating incoming mail.