SRS Email Forwarding: How It Works and Why It Fails

You set up a forwarder. contact@yourdomain.com routes to Gmail. Works fine for a week. Then client emails vanish — no bounce, no trace. The server logs say 550 5.7.1 Unauthenticated email or 550 5.7.26 This message does not have authentication information. This is the exact problem SRS email forwarding was built to fix. When your server re-sends a message, it opens a fresh SMTP connection — but the envelope still names the original sender's domain. The destination checks SPF against that domain, finds your IP unauthorized, and drops the mail. If the original domain has p=reject in DMARC, the message is gone. Not spammed. Gone.

Enabling SRS isn't the complete fix. There's a second failure mode most guides skip, and it'll still drop mail even after SRS is correctly configured. For the full picture of forwarding failure modes and how to diagnose them, see our email forwarding setup and fix guide.

What Is SRS Email Forwarding?

SRS email forwarding — Sender Rewriting Scheme — rewrites the envelope sender address when your mail server re-delivers a message to a new destination. It replaces the original sender's domain with your own in the technical return path so the new routing hop passes SPF validation. The recipient still sees the original sender in their inbox. SRS only touches the invisible envelope layer, not anything users read.

SRS email forwarding is supported on Postfix via the postsrsd daemon, on Microsoft 365 in hybrid configurations, and is baked into several managed email hosting platforms. It patches a fundamental mismatch between how legacy SMTP forwarding works and how modern SPF and DMARC enforcement expects traffic to behave.

Why Forwarding Breaks: The New Hop Problem

Every email forward creates a new SMTP hop, and every new hop breaks SPF by design. Email has two identity layers, and forwarding severs the relationship between them. The Header From (RFC 5322) is what users see — From: alice@client.com. The Envelope Sender (RFC 5321, MAIL FROM) is the technical return address servers use for SPF lookups and bounce routing — users never see it.

Here's the exact failure sequence when a forward silently kills a message:

1. Alice sends from alice@client.com. Her SPF record authorizes her server. SPF passes on arrival at your server.
2. Your server opens a fresh SMTP connection to you@gmail.com. New hop. Your IP is now the sender.
3. The Envelope Sender is still alice@client.com — but your server's IP is unauthorized by client.com's SPF record.
4. Gmail checks SPF for client.com, finds your IP, sees no authorization. SPF fails.
5. If client.com publishes p=reject in DMARC, Gmail discards the message. No bounce. Gone.

How SRS Email Forwarding Fixes SPF

SRS email forwarding rewrites the Envelope Sender before re-delivery, replacing the original sender's domain with your own. The destination now checks SPF against your domain — which you control — so SPF passes. The Header From stays untouched. Recipients see the original sender. Bounces route through your domain instead of the original sender's, which is the correct behavior for a forwarding server.

The SRS Syntax Decoded

When SRS email forwarding is active, the return path transforms from a simple address into a cryptographic string:

Before SRS: MAIL FROM: <alice@client.com>
After SRS: MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>

If the same message is forwarded a second time (A → B → C), SRS email forwarding uses SRS1 syntax. Instead of wrapping the full SRS0 string in another layer, it encapsulates just the hash and timestamp. This keeps the local-part within the 64-character limit defined in RFC 5321 and prevents immediate bounces from length violations.

Why SRS Email Forwarding Isn't Enough: The DMARC Problem

Many admins enable SRS email forwarding and assume the job is done. Then emails land in Spam anyway. Here's why: SRS fixes SPF but breaks DMARC alignment. DMARC requires that the Header From domain aligns with either the SPF-authenticated domain or the DKIM signing domain. After SRS rewriting, the SPF-authenticated domain is yourdomain.com, but the Header From is still client.com. They don't match. SPF alignment fails by design.

At this point, the message's survival depends entirely on DKIM — and forwarding servers frequently break DKIM signatures by modifying the message:

• Prepending [EXTERNAL] to the subject line
• Injecting antivirus footers or legal disclaimers
• Converting 8-bit encoding to 7-bit
• Rewriting MIME boundaries

If the forwarder modifies the message in any of these ways, DKIM breaks. With both SPF alignment and DKIM failed, DMARC fails. The message is gone — even though SRS email forwarding worked exactly as designed.

The Fix: ARC (Authenticated Received Chain)

ARC (RFC 8617) lets the forwarding server seal the authentication results it observed before any modifications occur. It adds three headers:

• ARC-Authentication-Results: Records SPF/DKIM/DMARC pass/fail at the moment of receipt
• ARC-Message-Signature: A snapshot of headers and body at sealing time
• ARC-Seal: A cryptographic signature linking your server to the chain of custody

If the final destination trusts your domain as an ARC sealer, it can override the downstream DMARC failure and accept the message. Gmail has been evaluating ARC seals in production since 2019.

Reliable forwarding in 2026 requires all three: SRS email forwarding for SPF, no body modifications to preserve DKIM, and ARC sealing for chain of custody. Miss any one of them and you're back to dropped mail.

Configuring SRS Email Forwarding by Platform

The setup steps for SRS email forwarding differ significantly by platform — Postfix requires a third-party daemon, Microsoft 365 requires a policy change before forwarding is even permitted, and Google Workspace has its own undocumented failure modes. None of these are enabled by default.

Postfix (Self-Hosted Linux)

Postfix doesn't support SRS email forwarding natively. You need the postsrsd daemon:

apt-get install postsrsd

Configure /etc/postfix/main.cf to route through postsrsd's TCP ports:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Critical: Set SRS_EXCLUDE_DOMAINS in /etc/default/postsrsd to include your local domains. If you skip this, postsrsd rewrites your own outbound mail into SRS format and creates routing loops. This is the most common misconfiguration when setting up SRS email forwarding on Postfix — and it's not obvious until your own outbound mail starts bouncing.

Microsoft 365

M365 handles SRS automatically for standard outbound pools. In hybrid environments or when using Connectors to route through a third-party gateway, you'll hit a policy block first: 550 5.7.520 Access denied, Your organization does not allow external forwarding.

This is a policy block, not an SRS failure. Go to Security Center → Policies & Rules → Anti-spam → Outbound spam filter policy and set Automatic forwarding to On. Then enable SRS on the Connector explicitly:

Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true

Google Workspace

Google uses a proprietary forwarding mechanism. Two failure modes unique to Workspace:

• Volume limits: Catch-all forwarding to Gmail hits quota limits fast. A spam flood can suspend the destination account entirely.
• Silent drops: Google's loop detection aggressively discards bounced forwards with no log trace. The message disappears and you have no record of it.

Troubleshooting SRS Email Forwarding Failures

When SRS email forwarding misbehaves, the raw message headers tell you exactly what's wrong. Send a test from ProtonMail to your forwarder and inspect the headers at the final destination. Don't guess — read the output. The failure mode is always visible if you know where to look.

Check 1: Return-Path

SRS inactive (bad): Return-Path: <original@protonmail.com>
SRS active (good): Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>

If the Return-Path still shows the original domain, postsrsd isn't running or isn't wired into Postfix correctly.

Check 2: Authentication-Results

Look for spf=pass with your domain in the qualifier. If you see dmarc=fail despite SPF passing, DKIM is broken or absent. Investigate whether the forwarder is modifying the message body or subject before re-delivery.

Check 3: DNS Verification

dig yourdomain.com TXT +short

Confirm the SRS anchor domain has a valid SPF record and an MX record. Some destination servers reject forwards from domains that can't receive bounces — if the SRS domain has no MX, the forward may be refused before it's even inspected.

Check 4: Postfix Log Analysis

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

If you see hash mismatch or timestamp expired, your postsrsd secret key may be out of sync across nodes, or you're seeing a replay attack where old SRS addresses are being recycled to generate backscatter.

When to Stop Using SRS Email Forwarding

SRS email forwarding is a patch for a structural mismatch. The full stack — SRS for SPF, ARC for chain of custody, zero body modifications for DKIM — exists because you're routing mail through a server that isn't the final destination. Each fix introduces a new dependency. Most businesses end up here because per-user licensing makes forwarding look cheaper. It isn't, once you count the engineering time.

Compare the two approaches side by side:

TrekMail uses a pooled storage model — you pay for storage once, shared across all mailboxes and domains. No per-user pricing. For agencies managing client email, see how this compares to a standard Gmail forwarding setup, or read the email alias forwarding tradeoffs guide if you're evaluating aliases instead. If you're not sure whether to use aliases or real mailboxes at all, the domain email alias vs mailbox comparison covers that decision in detail.

When you host mailboxes directly on TrekMail, you don't need SRS email forwarding. You don't need ARC. SPF, DKIM, and DMARC are configured through a setup wizard. Mail works because the sending server is the authoritative server for the domain — the way SMTP was designed.

Try TrekMail free — no card required on the Nano plan, or start a 14-day trial on Starter from $3.50/mo if you want managed SMTP included.

Summary

SRS email forwarding is the necessary first step for any server running mail forwarders in 2025–2026. Without it, SPF fails at the forwarding hop and any domain with strict DMARC will discard your forwarded messages. With it, SPF passes — but DMARC alignment breaks, and survival depends on DKIM making it through the forward intact.

Configuring SRS email forwarding correctly on Postfix means installing postsrsd, wiring it into main.cf, and setting the exclude domains list. On M365, it's a policy toggle plus a PowerShell command. On Google Workspace, it's a proprietary system with undocumented limits waiting to suspend your account.

The complete stack for reliable forwarding is: SRS email forwarding for SPF, no body modifications for DKIM, and ARC sealing for chain of custody. All three. Or skip it entirely and host the mailbox where the mail actually needs to live.