Why email forwarding breaks SPF, and how SRS and ARC fix it

Why forwarding and SPF are fundamentally at odds

SPF, as defined in RFC 7208, works by publishing a list of IP addresses or hostnames authorized to send mail claiming to be from a domain, and having receiving mail servers check the IP of the server currently delivering the message against that list. This check is deliberately about the connecting server, not the message’s original author — SPF has no concept of “this message originated somewhere else and is only passing through.”

Forwarding breaks that model directly. When a mailbox forwards a message — whether through an explicit “forward to” rule, a mailing list, or an automatic redirect — the forwarding server delivers the message to the next recipient without becoming the original sender. The envelope sender (the technical MAIL FROM address checked by SPF, which is often invisible in a mail client and different from the visible “From:” header) still shows the original sender’s domain, but the connecting IP is now the forwarding server’s, which was never authorized by the original domain’s SPF record. The result is a legitimate, non-spoofed message that still technically fails SPF — SPF working exactly as specified, just not in the way an end user expects. See our guide on SPF, DKIM, and DMARC explained for how SPF fits into the broader authentication picture.

Sender Rewriting Scheme (SRS): fixing SPF by rewriting the sender

SRS solves this at the point where the problem is introduced: the forwarding server itself. Instead of relaying the message with the original envelope sender untouched, an SRS-capable forwarder rewrites it to an address on the forwarder’s own domain — something like [email protected] — before relaying it onward. That rewritten address encodes enough information to route any bounce back to the original sender, but critically, it belongs to the forwarder’s domain. When the final recipient’s server checks SPF, it’s now checking the forwarder’s IP against the forwarder’s own SPF record, which correctly lists that IP, so the check passes.

SRS is a widely deployed convention rather than a formal IETF standard, and its biggest limitation is that it only works if the forwarding server itself implements it — a domain owner on the receiving end of forwarded mail can’t force a third-party forwarder to adopt SRS. It also only addresses SPF; it does nothing for DKIM.

Authenticated Received Chain (ARC): preserving the original result instead of rewriting

ARC, standardized in RFC 8617, takes a structurally different approach. Rather than rewriting anything to make a later check pass, each server in a forwarding chain adds a cryptographically signed “ARC set” to the message, recording what the authentication results (SPF, DKIM, DMARC) looked like at that hop, along with who forwarded it. A final recipient can then see that a message genuinely passed SPF and DKIM before a known, trusted forwarder relayed it — and the receiving mail system can choose to honor that historical result instead of penalizing the message for failing SPF on the final hop. This also helps with DKIM, which SRS doesn’t touch: a forwarder that modifies a message (adding a disclaimer footer, converting line endings) can break the original DKIM signature, and ARC preserves a record that it was valid before that happened.

ARC depends on both sides supporting it — the forwarder must sign an ARC set, and the final recipient’s mail system must be willing to evaluate ARC results rather than just the raw SPF/DKIM/DMARC outcome. Major mailbox providers including Gmail and Microsoft 365 support evaluating ARC today, but support isn’t universal across every mail server.

How to tell which problem you actually have

A forwarded-mail SPF failure looks identical, from the SPF record’s perspective, to a spoofed message — both show a connecting IP that isn’t on the domain’s SPF list. The distinguishing signal is usually in the receiving server’s authentication report: a legitimate forwarder typically has a consistent, identifiable IP or hostname, often a known mailbox provider’s infrastructure, rather than an arbitrary unrelated server. Use AdminKit’s SPF check tool to confirm exactly what your domain’s SPF record currently authorizes, and our DMARC check tool and guide on DMARC aggregate reports to see real delivery and failure patterns before assuming every SPF failure is spoofing — and before tightening a DMARC policy to p=reject prematurely, which can silently drop forwarded mail from legitimate senders whose forwarders don’t yet support SRS or ARC.

Related checks

SPF forwarding failures are one specific, well-understood cause of SPF breakage — if you’re instead seeing a PermError about too many DNS lookups, that’s a different and more common SPF problem covered in fixing SPF “too many DNS lookups”. A different envelope-sender quirk entirely is backscatter, where a spammer forges your domain as the MAIL FROM address on someone else’s spam run rather than your own mail being forwarded — see email bounces and backscatter explained.