How do auto-forwarders impact authentication results?

Auto-forwarders are common. A user sets up their work email to forward to their personal Gmail. Or a domain has catch-all aliases that redirect to a different mailbox. These setups seem simple, but they quietly break email authentication in ways that are hard to diagnose.

Here's what happens when an auto-forwarder touches a message:

SPF almost always fails. The auto-forwarder sends the message from its own mail server. That server's IP isn't listed in the original sender's SPF record. SPF checks the IP against the record for the domain in the SMTP envelope, and it fails. This is expected and basically unavoidable with standard auto-forwarding.

DKIM sometimes survives, sometimes doesn't. If the forwarder just passes the message along without touching headers or body, the DKIM signature stays valid. But if it adds a footer, rewrites a Received header in a way DKIM's canonicalization can't absorb, or modifies the MIME structure, DKIM breaks too.

With both failing, DMARC fails. If the original sender has p=reject, the forwarded message might get rejected at the final destination. The subscriber never receives it. From their perspective, emails from that sender just stopped.

The protocol designed to address this is ARC. Well-implemented forwarders add ARC headers that preserve the original authentication state. Receiving mailbox providers that honor ARC can then make an informed decision rather than a hard reject. If you're running forwarding infrastructure and seeing downstream failures, check whether your mail server supports ARC and whether destination providers are likely to honor it.