Why forwarded email breaks SPF, what SRS (Sender Rewriting Scheme) does about it, and when you absolutely need to implement it.

Email forwarding sounds simple. Alice sends to forward-me@example.com. Your server forwards to alice-real@other.com. Done, right?

It used to be. Then SPF became mandatory. Now forwarded mail gets rejected silently by receivers who don't realize their SPF check is about to strand a support ticket.

The problem in one paragraph

SPF says: "for domain X, only these IPs are allowed to send mail." When you forward alice@example.com's message without touching envelope headers, the receiving mailbox sees it arrived from your IP but with alice@example.com's envelope sender — and example.com's SPF doesn't list your IP. Result: SPF fails. DMARC fails. Message lands in spam or gets rejected outright.

This is specifically about the envelope sender (the MAIL FROM: in SMTP), not the From: header. Receivers check SPF against the envelope. Leaving the envelope unchanged breaks forwarding. Rewriting it breaks attribution. Enter SRS.

What SRS is

SRS (Sender Rewriting Scheme) rewrites the envelope sender when forwarding. alice@example.com becomes something like SRS0=abc=aq=example.com=alice@yourforwarder.com.

Now when the final receiver checks SPF:

Envelope domain: yourforwarder.com
Sending IP: yourforwarder.com's IP
SPF check: passes, because yourforwarder.com lists its own IPs in SPF.

The original address is preserved inside the rewritten local part (SRS0=abc=aq=example.com=alice) so if the final recipient replies, your forwarder can reverse the rewrite and deliver back to the original sender correctly.

When you absolutely need SRS

You run a forwarder that accepts mail for other people's domains and forwards to their real addresses.
You offer masked email addresses (like our Postscale Shield — aliases that forward to real inboxes).
You run mailing lists where messages get redistributed.
You handle Forward rules inside a larger mail platform.

If you don't do any of the above — you only receive mail for your own users and don't redistribute — you don't need SRS.

The one rule

Always rewrite the envelope sender. Never rewrite the From: header.

Tempting to think "I'll just rewrite From: so it looks like it came from us." Don't. Two reasons:

Reply would go to you, not the original sender. Breaks the fundamental point of forwarding.
DMARC alignment fails. If example.com publishes p=reject, the receiver sees your forwarder's From: and example.com's claim — mismatch — rejected.

Envelope rewrite only. Header-From stays intact.

SRS implementation pieces

You need:

A domain you control for the rewrite (e.g., srs.yourforwarder.com). The rewritten SRS0=... address points at this domain.
Correct SPF on that domain listing your forwarding IPs.
A reverse-rewrite function so bounces/replies to the SRS0=... address can be mapped back to the original sender.
An SRS secret (HMAC key) used to sign the rewritten address so attackers can't forge SRS addresses and bounce mail at arbitrary users.

The protocol was formalized in SRS specification (draft by Meng Weng Wong). Most MTAs have a module — postsrsd for Postfix is the common choice and integrates with less than 20 lines of config.

What SRS doesn't fix

SRS fixes SPF. It does not fix:

DKIM breakage caused by the forwarder modifying headers (e.g., adding List-Unsubscribe:). If your forwarder adds headers the original DKIM signature doesn't cover, DKIM still passes. If it modifies a signed header, DKIM breaks and no SRS can rescue it. Solution: don't modify signed headers; if you must, you have to re-sign.
ARC (Authenticated Received Chain). For sophisticated multi-hop scenarios (list → forward → alias → final recipient), ARC preserves authentication history across hops. SRS is the simpler envelope-only fix. ARC is the heavier solution for mailing lists.
Content modifications. If you append a footer or rewrite links, DKIM's body hash won't match. Same mitigation as above.

How we handle it at Postscale

Every masked address on Postscale Shield uses SRS transparently. You don't have to implement anything — when mail forwards through one of your aliases, the envelope is rewritten, SPF validates, DKIM re-signs for the forwarder domain, and the receiving inbox sees a cleanly-authenticated message.

The tradeoff: bounces come back to us first, then we forward them to the alias owner. So the feedback loop is slightly delayed compared to receiving mail directly — a second or two, no practical impact.

What to test

If you're implementing forwarding yourself, these are the must-pass tests:

Send from Gmail → forwarded domain → real inbox. Check SPF result in the received headers.
Same, but from Outlook and Yahoo (they enforce SPF more aggressively than Gmail).
Bounce scenario: send to a nonexistent address through the forwarder. Verify the bounce reaches the original sender, not the forwarder.
High-volume case: forward 1,000 messages in an hour. Check whether your forwarder's IP gets rate-limited by major mailboxes.
Edge case: forward from a p=reject DMARC sender. Confirm the final message still authenticates.

SRS and email forwarding: why forwarded mail bounces (and how to fix it)