What happens if a forwarder doesn't support ARC?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
The receiving mail server has to judge the forwarded email on its own. And without ARC context, what it sees isn't promising.
Forwarding typically breaks SPF (the forwarder's IP replaces the original server's IP). If the forwarder also modifies the message (adding footers, changing subject lines), DKIM breaks too. With both failing, DMARC has nothing to work with. What happens next depends on your DMARC policy:
- p=none: The email still delivers. The failure gets logged in your DMARC reports, but nothing is blocked.
- p=quarantine: The email likely lands in the spam folder at the recipient's mailbox.
- p=reject: The email gets rejected outright. The recipient never sees it.
For senders running p=reject (which is where you should eventually land for security), this means legitimate forwarded mail gets silently blocked. It looks exactly like a spoofed message from the receiver's point of view. There's no way to distinguish the two without ARC.
There's no perfect fix on the sender side. You can't control which forwarding services your recipients use or whether those services implement ARC. Some senders temporarily relax their DMARC policy back to p=quarantine when forwarding failures show up in reports, accepting more spam-folder risk in exchange for fewer rejections. It's a real trade-off.
The best thing you can do: keep DKIM solid (it survives simple forwarding), monitor your DMARC aggregate reports for forwarding-related failures, and check whether high-volume forwarders your recipients use support ARC. If you're seeing a lot of forwarding rejections and aren't sure what to do, our SOS hotline is free.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
