Sender Rewriting Scheme (SRS): Why Forwarding Breaks

You set up an email forwarder. Tested it — worked. Two weeks later, a client's contract email vanishes. Not in spam. Not bounced. Just gone. You pull the logs and find: 550 5.7.1 Unauthenticated email from domain.com.

That error almost always traces back to a missing or broken sender rewriting scheme. Modern email authentication assumes whoever sends your email owns the domain in the envelope. Forwarding breaks that assumption at the protocol level. A sender rewriting scheme is the patch — but in 2026, it's not a complete fix on its own, and knowing where it fails matters as much as knowing what it does.

This guide covers what a sender rewriting scheme does, how it fails, and what a working forwarding stack looks like. If you're also chasing the broader delivery problem — wrong MX records, catch-all misconfigurations, DNS changes that broke routing — read the email forwarding setup and fix guide first.

Why SPF Breaks the Moment You Forward Email

Email forwarding breaks SPF because the forwarding server's IP sends the message, but the envelope sender still shows the original domain. That domain's SPF record doesn't include the forwarding server's IP. With DMARC p=reject in play, the receiving server drops the message silently — no bounce, no warning to anyone.

Email isn't one continuous pipe. It's a chain of SMTP connections — a new TCP handshake at each hop. Here's the exact failure sequence:

1. alice@client.com sends to contact@your-agency.com
2. Your server accepts it — Alice's IP matches client.com's SPF record
3. Your server opens a new SMTP connection to Gmail to forward the message
4. Gmail sees the connection coming from your IP
5. The envelope sender still reads alice@client.com
6. Gmail checks client.com's SPF — your IP isn't authorized
7. SPF fails. If client.com uses p=reject, Gmail drops the message

RFC 7208 (the SPF specification) explicitly acknowledges this: the protocol was designed knowing that forwarding would break it. There's no fix at the SPF layer. You have to fix the envelope.

The Two Identity Layers: Envelope vs. Header

Email has two sender identity layers. The Envelope Sender (RFC 5321, MAIL FROM, P1) is used for SPF checks and bounce routing — only servers ever see it. The Header From (RFC 5322, P2) is what shows up in Gmail or Outlook. Forwarding desynchronizes these two layers, and that desynchronization is the core problem a sender rewriting scheme is built to solve.

When you forward email, the Header From stays alice@client.com. Your server creates a new SMTP transaction, and SPF is evaluated against the Envelope Sender at that new hop. Those two are now out of sync — and that's the failure.

What a Sender Rewriting Scheme Actually Does

A sender rewriting scheme rewrites the Envelope Sender (P1) address before the forwarding server opens its new SMTP connection. The Header From — what the end user sees — stays unchanged. By aligning the envelope domain with the forwarding server, a sender rewriting scheme causes SPF to pass at the destination while keeping the visible "From" intact.

The postal analogy: Without a sender rewriting scheme, you receive Alice's letter, put it in a new bag, and leave Alice's return address on it. The destination sees you delivering something claiming to be from Alice — and rejects it as a forgery. With a sender rewriting scheme, you cross out Alice's return address and write your own. Delivery matches the return address. If the bag needs to come back, it goes to you, and you route it back to Alice.

Decoding the SRS Address Format

When a sender rewriting scheme is active, it transforms the envelope into an encoded string before the forwarding hop. The destination sees a valid envelope matching your domain. That string contains a cryptographic hash (security), a timestamp (replay attack prevention), and the original sender's address (bounce re-routing). It's not garbage — it's structured data.

A standard SRS-rewritten address:

SRS0=4fac=PM=client.com=alice@your-agency.com

• SRS0 — first hop. SRS1 appears when the message is forwarded again downstream, preventing the address from growing infinitely long
• 4fac — HMAC-SHA1 hash. Validates incoming bounces; invalid hashes are dropped to block backscatter abuse of your server
• PM — timestamp. Usually enforces a 7–21 day window; expired addresses are rejected to prevent replay attacks
• client.com=alice — encoded original sender, used to re-route bounces back to the right address

When You Actually Need a Sender Rewriting Scheme

You need a sender rewriting scheme whenever you auto-forward email between domains and the forwarding server's IP isn't authorized by the original sender's SPF record. With DMARC enforcement tightening every year, any multi-domain forwarding infrastructure operating without SRS is running on borrowed time.

Vanity domain to personal Gmail. You own cool-startup.com and forward all mail to founder@gmail.com. A sender rewriting scheme is mandatory here. Banks, government agencies, and any sender with strict DMARC will hit SPF failure at Gmail without SRS in the path.

MSP or agency with a shared mail cluster. You host 200 client domains. Clients constantly set up forwarders to their ISPs (Comcast, AT&T, Outlook). Without a sender rewriting scheme enforced globally, every forwarded spam message gets attributed to your IP — SPF fails, and you land on Spamhaus within weeks.

Microsoft 365 with an outbound Connector. M365 handles SRS internally for direct delivery. But if you route traffic through an outbound connector, the rewrite may not fire before the handoff. Set SenderRewritingEnabled on the connector explicitly — and check the outbound spam filter policy for the 5.7.520 external forwarding block, which is a policy setting, not an SRS failure.

Why a Sender Rewriting Scheme Isn't Enough

A sender rewriting scheme fixes SPF alignment but breaks DMARC alignment by design. DMARC requires the authenticated domain to match the Header From. SRS changes the envelope domain to your forwarding domain — but leaves the Header From as the original sender's domain. SPF alignment fails, so DMARC survival depends entirely on DKIM surviving the transit intact.

Forwarding servers routinely break DKIM signatures:

• Adding [EXTERNAL] to the subject line changes the header — DKIM fails
• Appending footer text (virus scan notices, unsubscribe links) changes the body hash — DKIM fails
• MIME rewriting (8-bit to 7-bit encoding conversion) — DKIM fails

End result: SPF alignment fails (by design, from the sender rewriting scheme). DKIM fails (from message modification). DMARC fails. Message dropped.

The fix is ARC (Authenticated Received Chain, RFC 8617). ARC lets your forwarding server seal authentication results before passing the message on. Three headers are added:

• ARC-Authentication-Results — "When this arrived at my server, SPF/DKIM/DMARC passed"
• ARC-Message-Signature — a snapshot of the message as you received it
• ARC-Seal — a cryptographic signature tying your server to the chain

When Gmail sees broken SPF and broken DKIM on a forwarded message, it checks the ARC seal. If it trusts your domain as a sealer, it overrides the DMARC failure. You can't force that trust — it's earned through domain reputation over time.

How to Verify Your Sender Rewriting Scheme Is Working

To check whether your sender rewriting scheme is active, send a test email from an external account to your forwarded address and inspect the raw headers at the destination. The Return-Path header tells you immediately whether SRS rewrote the envelope or left it as the original sender's address.

Step 1: Check Return-Path at the destination

# SRS inactive — SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>

# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>

Step 2: Verify your SRS domain's DNS

# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf

# Check MX — bounces need a place to go:
dig MX your-domain.com

If your SRS domain has no MX record, receiving servers may reject the forward entirely — the return path is unreachable. A working sender rewriting scheme requires the rewrite domain to have valid SPF and a working MX.

Step 3: Check the mail log on Linux

grep "srs_forward" /var/log/mail.log

If you see hash mismatch or timestamp expired, your PostSRSd secret key is out of sync — or you're seeing a replay attack attempt. Note: Postfix doesn't include a sender rewriting scheme natively. You need PostSRSd, and you must set SRS_EXCLUDE_DOMAINS to include your own local domains, or Postfix will rewrite internal mail into SRS format and create routing loops.

The Simpler Alternative: Stop Forwarding

A sender rewriting scheme exists because forwarding desynchronizes envelope and header identities. The clean fix is to stop forwarding and use a proper IMAP mailbox on your domain instead. No SPF mismatch, no DMARC alignment problem, no DKIM fragility. The message goes directly to your mailbox, authenticated end to end.

Forwarding is popular because nobody wants to pay per-user fees for a mailbox that gets five emails a month. A sender rewriting scheme is often a workaround for a pricing problem, not a technical one.

TrekMail's model changes that. Plans start at $3.50/month and cover multiple domains under flat-rate pooled storage — no per-user fees. You run sales@yourdomain.com as a real IMAP mailbox, connect it to Gmail or Outlook via IMAP, and retire the forwarding stack. No sender rewriting scheme to configure, no ARC to deploy, no DMARC alignment failures to chase.

For multi-client setups, the multi-domain email hosting guide covers how to manage dozens of domains without per-domain overhead. If you're running a hybrid setup — some mailboxes, some legacy forwarders — the email alias forwarding guide covers how to configure forwarding correctly with SRS in the path.

Whether you keep forwarding or switch to mailboxes: understand what a sender rewriting scheme does, verify it's active, and pair it with ARC. Half-configured forwarding infrastructure swallows legitimate email. That's a business problem, not a technical curiosity.

Start with a free TrekMail account — no card required, no trial expiry — and see how multi-domain email works without the forwarding complexity.