Sender Rewriting Scheme (SRS): Why Forwarding Breaks Without It

You configure a forwarder: contact@your-agency.com → you@gmail.com. Test it. Works. Two weeks later, a contract from an enterprise client never arrives — not in spam, not anywhere. Pull the logs: 550 5.7.1 Unauthenticated email. Or 550 5.7.520 Access denied if it was heading to Microsoft 365. The message was silently killed.

The fix — when it's configured — is the sender rewriting scheme SRS. Without it, every email forward you run is a potential SPF violation. In 2026, with Google and Yahoo enforcing strict p=reject DMARC policies (Google's email sender requirements), that violation gets your forwarded mail silently dropped. This guide explains what sender rewriting scheme SRS does at the protocol level, where it falls short, and what a complete fix actually looks like.

For the full forwarding picture, start with our guide on email forwarding setup and common fixes.

What Is Sender Rewriting Scheme (SRS)?

Sender rewriting scheme SRS is an envelope-rewriting technique that prevents SPF failures caused by email forwarding. When your server forwards a message, it rewrites the invisible SMTP envelope address (MAIL FROM) to use your forwarding domain instead of the original sender's. The receiving server then checks SPF against your domain — one your server is actually authorized for — and the check passes. Without sender rewriting scheme SRS, the forwarded message claims to originate from a domain your server has no permission to send for, and modern DMARC enforcement treats that as spoofing.

The Two Layers of Email Identity

Every forwarding failure traced to sender rewriting scheme SRS starts with the same confusion: email has two distinct identity layers, and most operators treat them as one. SPF checks one. DMARC checks both. Forwarding splits them apart.

The Envelope handles delivery — invisible to the recipient, checked by SPF. The Header is what appears in the email client and what DMARC measures for alignment. When forwarding creates a new SMTP connection, these two layers diverge, and every authentication check downstream fails unless sender rewriting scheme SRS is applied first.

The New Hop Problem: Why Forwarding Breaks SPF

When your server forwards a message, it opens a brand-new SMTP connection to the destination — a "new hop." The envelope sender still reads alice@bank.com, but the connecting IP is now yours. SPF checks your IP against bank.com's SPF record. Your IP isn't listed. SPF fails. If bank.com publishes DMARC p=reject — standard for banks and large enterprises — the receiving server drops the message immediately with no bounce.

This isn't a misconfiguration. It's how forwarding works by design. Every forwarding server in the world has this problem unless it applies sender rewriting scheme SRS.

How Sender Rewriting Scheme (SRS) Rewrites the Envelope

Sender rewriting scheme SRS fixes SPF by rewriting the MAIL FROM envelope address to your forwarding domain before initiating the new SMTP connection. The From: header the recipient sees stays exactly as the original sender wrote it.

# WITHOUT SRS — SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS — SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

The destination server checks SPF against your-domain.com — a domain your server is authorized for. SPF passes. The recipient sees From: alice@bank.com as normal. Sender rewriting scheme SRS solved the immediate check. But it created a new problem in the process.

Decoding the SRS Address Format

The SRS address in the Return-Path looks like noise, but each segment serves a purpose. Understanding it helps you confirm sender rewriting scheme SRS is working and pinpoint what's wrong when it isn't.

Example: SRS0=4fac=PM=bank.com=alice@your-domain.com

The Double Whammy: SRS Breaks SPF Alignment

Here's what most guides don't tell you: implementing sender rewriting scheme SRS fixes the SPF check but breaks SPF alignment — and DMARC requires both. This is why forwarded mail often still fails even after SRS is correctly configured.

DMARC requires the authenticated domain to match the visible From: header domain. With sender rewriting scheme SRS active:

• SPF check: PASS — your IP matches envelope domain your-domain.com
• SPF alignment: FAIL — envelope your-domain.com ≠ header bank.com

The email's survival now depends entirely on DKIM. If the original sender signed with DKIM and your forwarder didn't touch the message body, DMARC can pass via DKIM alignment. But forwarders routinely break DKIM signatures by adding "External Email" warning banners, appending antivirus footers, or rewriting MIME encoding (8-bit to 7-bit).

The result: SPF alignment fails (because of SRS). DKIM fails (because of body modification). DMARC fails. Message dropped — even though sender rewriting scheme SRS was doing its job correctly.

ARC: The Fix Beyond Sender Rewriting Scheme SRS

ARC (Authenticated Received Chain, RFC 8617) is the modern complement to sender rewriting scheme SRS. Where SRS rewrites the envelope to fix SPF, ARC lets your forwarding server seal the original authentication results — telling the next receiver: "I verified this message on arrival and it was clean. Trust the chain."

ARC adds three headers — ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal — that survive body modification. This handles the cases DKIM can't cover after forwarding breaks its signature.

The catch: ARC only works if the receiver trusts your sealer. Microsoft 365 admins must explicitly add your domain to the trusted ARC sealers list via PowerShell (Set-ArcConfig). Gmail's trust is algorithmic — you can't manually force it.

For production setups, you need both: sender rewriting scheme SRS to fix the SPF check, and ARC to survive DMARC when DKIM breaks. Neither alone is sufficient for reliable delivery to all major providers.

Diagnosing SRS Problems: A Checklist

If forwarded mail is disappearing, use this checklist to isolate whether sender rewriting scheme SRS is the problem — or something upstream of it.

1. Check the Return-Path header

Send a test from an external account through your forwarder. At the final destination, inspect raw headers.

# SRS inactive — SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active — SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. Check for Microsoft 365 outbound blocks

If you're forwarding out of Microsoft 365, sender rewriting scheme SRS is irrelevant — the block happens before mail leaves the tenant.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Fix this in the Outbound Spam Filter Policy in the Defender portal. SRS on your receiving server won't help here.

3. Check for routing loops

If A forwards to B and B forwards back to A, you get a routing storm. Look for these in the logs:

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

Stop Forwarding. Host Real Mailboxes.

Configuring postsrsd, managing HMAC keys, debugging DMARC alignment failures — that's the operational tax for routing professional email through personal inboxes to avoid per-mailbox fees. Sender rewriting scheme SRS is a patch on an architectural problem. The problem is the forwarding architecture itself.

Instead of forwarding contact@client-domain.com to Gmail and wrestling with sender rewriting scheme SRS configuration, you host contact@client-domain.com as a proper IMAP mailbox on TrekMail. Connect it to Gmail via IMAP if you want — but delivery goes direct. No new hop, no envelope rewriting, no authentication chain to break. See how these approaches compare in our guide on forwarding domain email to Gmail, or weigh the tradeoffs in our alias vs. mailbox breakdown.

Managing multiple client domains? Instead of debugging sender rewriting scheme SRS across each client's server, provision every domain on TrekMail with isolated mailboxes in minutes. Our guide on multi-domain email hosting covers how that scales without the config overhead.

TrekMail starts at $3.50/mo with a 14-day free trial. Set up real mailboxes and skip the workarounds entirely.