SRS: Why Forwarded Email Breaks SPF and How to Fix It
When you forward an email, SPF fails. The Sender Rewriting Scheme fixes this — and without it, forwarded mail from strict domains gets rejected.
The Problem
When a message from sender@gmail.com is forwarded through an intermediary server, the receiving server checks SPF and sees that the intermediary's IP is not authorized to send as gmail.com. The message fails SPF.
This is not a bug — it is SPF working exactly as designed. SPF validates that the sending IP is authorized by the domain in the envelope sender (MAIL FROM). When a forwarding server relays the message, the sending IP changes but the envelope sender does not. The result: SPF failure.
For domains with strict SPF policies (-all), this means forwarded mail is rejected outright. For domains with soft fail (~all), the message is penalized but may still be delivered — with a lower reputation score.
The Solution: Sender Rewriting Scheme
The Sender Rewriting Scheme (SRS) addresses this by rewriting the envelope sender to use the forwarding server's own domain, while encoding the original sender in a cryptographically signed format.
The receiving server checks SPF against the forwarding domain (which passes, because the forwarding server's IP is authorized for its own domain). The original sender is recoverable from the SRS address if a bounce occurs.
An SRS-rewritten address looks something like:
SRS0=HHH=TT=originaldomain.com=originaluser@forwardingdomain.com
Where HHH is a cryptographic hash (preventing forgery), TT is a timestamp (preventing replay), and the original sender information is preserved for bounce handling.
Industry Adoption
Microsoft implemented SRS in Office 365 specifically to solve this problem for auto-forwarded mail (Microsoft — Sender Rewriting Scheme in Microsoft 365). The Open SPF project documents the original specification.
Any mail server that forwards mail from third-party domains needs SRS. Without it, forwarded messages from domains with strict SPF policies will be rejected by the recipient's server.
Implementation in Postfix
In Postfix, SRS is typically implemented via PostSRSD, which runs as a TCP service on two ports — one for forward rewriting (outbound) and one for reverse rewriting (inbound bounces):
sender_canonical_maps = hash:/etc/postfix/sender_canonical, tcp:127.0.0.1:10001
recipient_canonical_maps = hash:/etc/postfix/sender_canonical, tcp:127.0.0.1:10002
sender_canonical_classes = envelope_sender
recipient_canonical_classes = envelope_recipient, header_recipient
The forward rewriting port (10001) rewrites the envelope sender on outbound forwarded mail. The reverse rewriting port (10002) decodes SRS addresses on inbound bounces, routing them back to the original sender.
The Relationship to ARC
SRS and ARC solve complementary problems. SRS fixes SPF alignment for forwarded mail. ARC preserves the original DKIM and DMARC authentication results across forwarding hops. Together, they ensure that forwarded mail passes all three authentication checks (SPF via SRS, DKIM via re-signing, DMARC via ARC chain) at the final destination.
A forwarding server without both SRS and ARC will see increasing delivery failures as more domains adopt strict DMARC policies.