Email forwarding breaks SPF because the forwarding server relays the message from its own IP address, and that IP was never listed in the original sender's SPF record. When the final mailbox provider runs the SPF check, it looks up the domain in the envelope sender and asks a simple question: is the connecting IP authorized to send for this domain? The forwarder is not, so the answer is fail. This is not a bug or a misconfiguration. It is a designed limitation of how SPF works, described in RFC 7208, and it hits plain aliases and mailing lists alike.
The good news is that the fix is well understood. Sender Rewriting Scheme (SRS) repairs the SPF check, and DKIM plus ARC restore the DMARC alignment that SRS alone cannot. Here is exactly why forwarding fails and how to climb the ladder of fixes.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The root cause: SPF authorizes IPs, not domains
SPF is a list of IP addresses and includes that a domain publishes in DNS. A record like v=spf1 include:_spf.google.com -all tells the world "these are the servers allowed to send mail using my domain in the envelope sender." When a receiving server gets a message, it reads the domain from the envelope sender (the SMTP MAIL FROM, also called the Return-Path), looks up that domain's SPF record, and checks whether the IP that just connected is in the authorized set.
Now walk through a forward. A message is sent from newsletter@brand.com to alice@herdomain.com. Alice has set up an alias that forwards everything to alice@gmail.com. Her server at herdomain.com accepts the mail, then re-sends it out to Google's inbound servers. When Gmail checks SPF, it still sees the envelope sender domain brand.com, but the connecting IP now belongs to herdomain.com. That IP is nowhere in brand.com's SPF record, because Brand has no idea Alice forwards her mail. SPF fails.
The check was never wrong. Brand really did not authorize Alice's server. SPF simply has no mechanism to say "I trust this hop to forward on my behalf." That is the core of the problem.
Why mailing lists are even worse
A discussion list like a Mailman or Google Groups list is a forwarder that also edits the message. It often rewrites the subject to add a [list-name] tag, appends an unsubscribe footer, and re-sends from its own IP. The IP change breaks SPF exactly as an alias does, and the body change breaks the original DKIM signature on top of it. Mailing lists are the classic case where both authentication methods fail at once.
Envelope sender vs header From: the distinction that matters
To understand every fix that follows, you need to separate two different "from" addresses.
The envelope sender (MAIL FROM / Return-Path) is used during the SMTP conversation and is where bounces go. This is the domain SPF checks.
The header From is the address your recipient actually sees in their mail client. This is the domain DMARC cares about for display and alignment.
These two can be completely different domains, and that is the whole game. DMARC does not just want SPF or DKIM to pass. It wants one of them to pass and to be aligned with the header From domain. SPF alignment means the envelope sender domain matches the header From domain. If you rewrite the envelope sender to a forwarder's domain to make SPF pass, you have just broken SPF alignment with the original From. Hold that thought, because it is why SRS is only half the answer. If this alignment concept is new, our SPF, DKIM and DMARC explained guide lays out how the three fit together.
Fix 1: SRS repairs the SPF check
Sender Rewriting Scheme is the standard fix for a forwarding server. When your server forwards a message, SRS rewrites the envelope sender so it now belongs to the forwarding domain instead of the original sender. An address like newsletter@brand.com becomes something like SRS0=hash=tt=brand.com=newsletter@herdomain.com.
Because the envelope sender is now a herdomain.com address, the receiver checks herdomain.com's SPF record instead of Brand's. Your forwarding server's IP is in that record, so SPF passes. The encoded original address is preserved so that bounces can be routed back correctly.
SRS on Postfix
The common approach on Postfix is PostSRSd. Install it, then point Postfix at it as a sender and recipient canonical rewrite service:
sender_canonical_maps = tcp:localhost:10001
recipient_canonical_maps = tcp:localhost:10002
PostSRSd handles the rewriting on the way out and the reverse decoding on bounces. Make sure the forwarding domain you rewrite into has an SPF record that authorizes your outbound IP, or you will simply move the failure rather than fix it. If your record is getting large, watch the ten-lookup cap covered in fix SPF too many DNS lookups.
SRS on Microsoft 365
If you forward through Microsoft 365, you do not configure SRS yourself. Microsoft applies SRS automatically to mail forwarded by Exchange Online, rewriting the P1 (envelope) sender into the onmicrosoft.com or accepted domain space so SPF passes at the next hop. Your job is to make sure forwarding is set up through supported mechanisms (mailbox forwarding, mail flow rules, or forwarding on the mail contact) rather than a client-side rule that re-sends as a new message.
Fix 2: why SRS alone does not satisfy DMARC
Here is the trap. SRS makes SPF pass, but it makes SPF unaligned. After rewriting, the envelope sender is herdomain.com while the header From is still brand.com. SPF now authenticates the wrong domain as far as DMARC is concerned. So a domain publishing a strict DMARC policy can still see the forwarded message fail DMARC, because neither SPF alignment nor DKIM alignment holds.
SRS solves the bounce and the raw SPF result. It does not, by itself, get a forwarded message past a p=reject policy. For that, you need the header From domain's own authentication to survive the trip.
Fix 3: DKIM and ARC complete the picture
DKIM is what actually carries a message through a forward intact. A DKIM signature is a cryptographic signature over selected headers and the body, published against the sending domain. Because it travels inside the message and is tied to the From domain, a plain alias forward that does not modify the message leaves DKIM valid. DKIM passes, DKIM aligns with the From domain, and DMARC passes even though SPF failed. This is precisely why every sender should sign with DKIM; see how to set up DKIM. If DKIM is passing but still failing alignment, our fix DKIM alignment guide covers the domain-match rules.
The remaining hard case is the mailing list that edits the body. Body changes invalidate the original DKIM signature, so now both SPF and DKIM are broken, and DKIM cannot save the message either.
Where ARC comes in
Authenticated Received Chain (ARC) is the answer for that final case. When a forwarder or list receives a message, it records the authentication results it saw (the original SPF, DKIM and DMARC verdicts) and seals them with its own signature, adding ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results headers. The next hop can then read the chain and reason: "SPF and DKIM fail here, but a forwarder I trust vouches that they passed before it modified the message." A receiver that trusts the ARC signer can honor that vouch and deliver the mail despite the broken original authentication.
ARC does not force delivery. It gives the final receiver trustworthy evidence to make a better decision. Large providers like Google and Microsoft both generate and evaluate ARC, which is why forwarded list mail from major services generally still lands even under strict DMARC.
Putting it together
The clean mental model is a ladder. SPF fails on forward because the relay IP is not authorized, by design. SRS repairs the raw SPF check and keeps bounces working. DKIM keeps authentication aligned with the visible From domain through simple forwards, so it, not SRS, is what actually satisfies DMARC. ARC rescues the messages that get edited in transit by preserving the earlier verdicts across hops. Publish SPF and DKIM correctly, move your DMARC policy up deliberately as described in DMARC policy none, quarantine or reject, and forwarding stops being a mystery.
Frequently asked questions
Does SRS fix DMARC as well as SPF?
No. SRS makes SPF pass by rewriting the envelope sender into the forwarder's domain, but that breaks SPF alignment with the header From, so DMARC does not pass on SPF alone. DMARC survives a forward through DKIM, which stays aligned with the visible From domain, or through ARC when the message was modified. Treat SRS as the SPF and bounce fix, and DKIM plus ARC as the DMARC fix.
Will forwarded mail fail if I use p=reject?
Not necessarily. A plain alias forward that does not modify the message keeps the original DKIM signature valid, so DMARC passes on DKIM even at p=reject. Mailing lists that edit the subject or body break DKIM, and there ARC is what lets a trusting receiver still deliver. The risk is highest for edited list mail sent to a receiver that does not evaluate ARC.
Why does SPF fail but DKIM pass on a forward?
Because they check different things. SPF checks the connecting IP against the envelope sender domain, and forwarding changes the IP, so it fails. DKIM checks a cryptographic signature carried inside the message against the From domain, and a forward that leaves the message intact does not touch that signature, so it still verifies. This is the everyday reason to rely on DKIM for forwarded mail.
Do I need to configure SRS on Microsoft 365?
No. Exchange Online applies SRS automatically to mail it forwards, rewriting the envelope sender so SPF passes at the next hop. Your responsibility is to use supported server-side forwarding rather than client rules, and to make sure your domain publishes valid SPF and DKIM so the messages authenticate in the first place.