Does ARC fix every forwarding issue?

ARC is often described as the fix for forwarding authentication failures. And it genuinely helps. But no, it doesn't fix every forwarding issue, and knowing why matters if you're trying to track down why forwarded emails keep failing.

First, a quick recap of the problem ARC is solving. When an email gets forwarded, the forwarding server often modifies the message in small ways (adding a footer, rewriting headers). That breaks the original DKIM signature. SPF fails too, because the message is now coming from the forwarder's IP, not yours. DMARC sees two failed checks and can reject the email. Your recipients never see it. For a deeper look at why this happens, the question on DMARC and forwarding walks through it step by step.

ARC's job is to carry proof of the original authentication results through the forwarding chain. The forwarder stamps what the authentication looked like before it touched the message. Receiving servers that trust that stamp can make an exception and deliver the email even though the original DKIM and SPF have broken. Think of it like a chain of custody document passed along with the email.

Here's where ARC falls short in practice.

• Not every forwarder implements ARC. Simple forwarding setups, older mailing list software, and many corporate mail gateways don't add ARC headers at all. If the forwarder doesn't stamp it, there's nothing for the receiver to evaluate.
• Not every receiver evaluates ARC. Gmail and Outlook do use ARC chains to make forwarding decisions. But plenty of smaller mailbox providers and custom mail setups don't yet. A valid ARC chain arriving at a receiver that ignores it is still a failed authentication.
• ARC only covers authentication breakage, not content changes. If a forwarder rewrites the subject line, changes links, or modifies the email body in a way that looks suspicious, spam filters can still reject it regardless of ARC passing cleanly.
• Multi-hop forwarding gets complicated. Each hop in a forwarding chain needs to implement ARC correctly for the full chain to hold. One server in the middle that doesn't stamp correctly breaks the whole chain of custody.

So what should you actually do if you're seeing forwarding failures?

Start by reading your DMARC reports. Forwarding failures show up as SPF and DKIM failures from IP addresses that aren't yours. If you're not yet parsing those reports, that's the first move. (The free DMARC parser from RME can help you make sense of the XML.)

From there, your main options are these. If you control the forwarding service, ask whether it supports ARC signing. If your recipients are forwarding through a service that doesn't support ARC, there isn't much you can do on your end. And if DMARC is in enforcement mode (p=quarantine or p=reject), you might consider whether strict enforcement is right for your setup if forwarding is a significant part of how your audience reads your mail.

ARC is a real improvement to a genuinely hard problem. But it's one layer in a messy ecosystem, not a universal fix. The forwarding problem won't fully disappear until both forwarders and receivers adopt ARC consistently, and that's still a work in progress.

If forwarding failures are affecting your DMARC pass rates and you're not sure what you're looking at in the reports, you're welcome to bring the data to our SOS hotline for a free look.