SRS Forwarding: PostSRSd, ARC, and When to Host Instead

Forwarding email is supposed to be simple. Set a redirect, done. Except it's not — and if you've deployed forwarding without SRS forwarding (Sender Rewriting Scheme), your emails are failing SPF checks right now. Here's the scenario: bank.com sends a message to a forwarded address on your server. Your server relays it onward. The destination sees your IP sending mail claiming to be from bank.com. SPF fails. If bank.com has p=reject in its DMARC policy, the email is silently deleted — no bounce, no notification, gone.

This is the operational guide to getting SRS forwarding right. The complete guide to email forwarding setup and failure modes covers the full picture. This article focuses on the SRS layer specifically: the architecture, the rewrite syntax, the Postfix implementation, and the ARC companion protocol you need for real DMARC compliance.

What SRS Forwarding Actually Does

SRS forwarding rewrites the envelope sender address when your server relays an email, replacing the original sender's domain with a domain you control. This makes SPF checks pass at the destination because your forwarding server's IP is now legitimately authorized to send mail from your own domain. The header From — what the recipient sees in their email client — stays untouched throughout.

Without SRS forwarding, every relayed message is a potential SPF failure. With it, the authentication chain stays intact. This isn't optional if you're forwarding mail from domains with strict SPF records.

The Two Layers of Email Identity

To configure SRS forwarding correctly, you need to understand the protocol distinction between two separate address fields. SPF only verifies one of them — and that's exactly where forwarding breaks without SRS.

• Envelope Sender (RFC 5321 MAIL FROM): The return address used by mail transfer agents for routing bounces. This is what SPF verifies. The receiving server checks whether the connecting IP is authorized to send mail for this domain.
• Header From (RFC 5322 From): The address displayed in email clients. DMARC checks alignment between this and the authenticated domain. SRS forwarding deliberately leaves this field untouched.

Here's exactly what breaks when you forward without SRS forwarding:

The SRS rewrite puts a domain you control in the envelope sender. Your SPF record covers that domain. The destination checks it, passes, and delivers. The recipient never sees the rewritten address — it's MTA-level plumbing only.

SRS Forwarding Syntax: What Those Tokens Mean

The SRS forwarding rewritten address looks cryptic, but each token has a deliberate purpose. Reading it is essential for diagnosing bounce log failures and debugging multi-hop delivery chains.

A first-hop SRS forwarding rewrite (SRS0) looks like this:

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

Each component:

• Hash: A truncated HMAC (usually SHA1) generated from a local secret key. This prevents spammers from forging SRS bounce addresses pointed at your domain — without it, any attacker could construct valid-looking SRS0 addresses and make your server an open relay for NDRs.
• Timestamp: Base32 encoded, typically valid for 7–21 days. Prevents replay attacks. Old rewritten addresses expire and won't be accepted.
• Origin: The data needed to reconstruct the original sender if the email bounces. Your server receives the NDR, reverse-maps it, and delivers the bounce to the right place.
• AnchorDomain: The domain you control. It must have an SPF record covering your forwarding server's IP, and MX records so bounces can actually arrive.

If the email is forwarded again (multi-hop), SRS0 becomes SRS1:

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1 exists to prevent the local part from exceeding the 64-character RFC 5321 limit. If you're seeing forwarding failures in multi-hop chains, local-part length is the first thing to check.

Postfix Implementation: PostSRSd Setup

PostSRSd is the standard daemon for SRS forwarding on Linux/Postfix systems. It runs as a background process that Postfix queries via canonical maps — Postfix hands it envelope addresses at relay time, and PostSRSd returns rewritten ones. Here's how to configure it correctly.

Step 1: Anchor Domain Prerequisites

Before touching config files, get your anchor domain ready. This is the domain that appears in the rewritten envelope sender for all SRS forwarding your server performs. It needs:

• MX records: Bounces (NDRs) get routed to this domain. If it can't receive mail, you're creating a black hole — NDRs from original senders go nowhere and you're violating RFC 5321.
• SPF record: Destination servers check this domain's SPF against your server's IP. If your forwarding IP isn't listed, SPF fails regardless of SRS forwarding being active.
• Clean reputation: If your server relays spam, the anchor domain gets blacklisted. There's no insulation between the anchor domain and the mail you forward.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output — must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

Step 2: Configure PostSRSd

Edit /etc/default/postsrsd (Debian/Ubuntu) or /etc/postsrsd/postsrsd.conf on newer installations:

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list — critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

Generate a strong secret key if you don't have one:

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

Step 3: Postfix Integration

Edit /etc/postfix/main.cf. PostSRSd 2.x uses unix socket maps; version 1.x uses TCP:

# PostSRSd 2.x — modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x — legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

Restart both services:

systemctl restart postsrsd
systemctl restart postfix

SRS Forwarding Isn't Enough: Enter ARC

SRS forwarding fixes the SPF problem but creates a new one: DMARC alignment failure. DMARC requires the Header From domain to align with either the SPF-authenticated domain or the DKIM-signing domain. After SRS rewriting, SPF authenticates on relay.yourdomain.com, not client.com — alignment fails. That leaves DKIM as the only path to DMARC compliance.

Forwarding often breaks DKIM. Adding "External Sender" prefixes to the Subject, appending unsubscribe footers to the body, or rewriting MIME boundaries all invalidate the original DKIM signature. When DKIM breaks and SPF alignment is already gone because of SRS forwarding, DMARC fails and strict destinations reject the message.

The solution is ARC — Authenticated Received Chain, defined in RFC 8617. ARC lets your forwarding server cryptographically attest to what the authentication state was when the message arrived — before you modified anything. Destination servers that trust your ARC seal can use that attestation to override the DMARC failure and deliver the message.

ARC adds three headers to each forwarded message:

• ARC-Authentication-Results: The auth checks your server performed on receipt
• ARC-Message-Signature: A cryptographic snapshot of headers and body at the forwarding point
• ARC-Seal: The chain link tying the sequence together across hops

SRS forwarding is the plumbing. ARC is the permit. For strict DMARC environments — Google, Microsoft — you need both running together. SRS forwarding alone won't save you when DKIM breaks in transit and SPF alignment is gone.

For the SPF specification that SRS forwarding was designed to work around, the authoritative reference is RFC 7208.

Provider-Specific Failures to Know Before You Deploy

Even with correct SRS forwarding and ARC implementation, specific providers enforce policies that block forwarded mail regardless of authentication state. These aren't misconfiguration errors on your end — they're deliberate product decisions. Know them before you hit them in production.

The M365 550 5.7.520 error is the one that wastes the most time. It's not a technical failure that SRS forwarding or ARC tuning can fix — it's a security policy deliberately enabled in the destination tenant. You need admin access to their Microsoft Defender portal to change forwarding permissions.

Verifying SRS Forwarding Works

After configuring SRS forwarding, verify it works before trusting it in production. Send a test message through the forwarding chain and inspect the raw headers at the destination. If Return-Path shows an SRS-rewritten address, SRS forwarding is active. If it shows the original sender's address, PostSRSd isn't running or Postfix isn't querying it.

1. Check the Return-Path Header

Send a test email from an external account (ProtonMail is clean for this) to your forwarded address. View raw message source at the destination and find the Return-Path line:

• Return-Path: <SRS0=...@yourdomain.com> → SRS forwarding is active and rewriting correctly
• Return-Path: <alice@protonmail.com> → SRS forwarding is not running

2. Verify Anchor Domain DNS

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. Check Postfix Logs

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

You should see Postfix querying the SRS daemon and receiving rewritten addresses in response. Connection refused errors mean PostSRSd isn't running — check systemctl status postsrsd.

4. Test TLS Reachability

SRS forwarding failures and TLS failures produce similar symptoms at the log level. Rule TLS out:

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

If this times out or negotiation fails, you have a separate TLS problem that's unrelated to SRS forwarding configuration.

When to Stop Forwarding and Start Hosting

SRS forwarding, ARC, anchor domain maintenance, secret key management, exclusion list updates, reputation monitoring — this is a real operational surface area for what is fundamentally a workaround. Most organizations build SRS forwarding into their stack to avoid per-mailbox licensing fees at major providers. Forward sales@ to your personal inbox and skip the $6/month seat. Rational math at one address, expensive math at ten.

If you're weighing the options, the email alias forwarding trade-off guide runs through the scenarios where forwarding makes sense versus where it compounds problems over time. And the alias vs mailbox decision guide helps when you're choosing the underlying address structure.

TrekMail's Pro plan ($10/month) gives you 100 domains and 50GB of pooled storage. Host sales@, support@, and info@ as real IMAP mailboxes — no per-seat fees, no forwarding chains, no SRS forwarding to maintain. Mail arrives and stays.

If you do need forwarding — consolidating multiple domains to a single destination, for example — TrekMail's managed forwarding on Pro and Agency plans handles SRS rewriting and OpenARC signing automatically. You set the destination address in the dashboard; the protocol compliance happens server-side. On the Nano plan with BYO SMTP, you implement SRS forwarding on your own outbound infrastructure using the PostSRSd setup above.

For the specific path of routing custom domain email to Gmail, the guide to forwarding domain email to Gmail covers the Gmail-specific failure modes and verification steps in detail.

The Short Version

SRS forwarding rewrites the envelope sender so your forwarding server's IP passes SPF at the destination. Without it, SPF fails on every forwarded message. Implement it with PostSRSd on Postfix — anchor domain with MX and SPF records, a secret key, an exclusion list for your own domains, and canonical map entries in main.cf. Then add ARC on top for environments where DKIM breaks in transit and SPF alignment alone won't satisfy DMARC.

Verify with raw header inspection after every config change. And if the operational overhead of SRS forwarding starts outweighing the licensing cost you're avoiding, it's time to stop forwarding and start hosting. Check TrekMail's plans — the Nano plan needs no credit card and works immediately. Pro adds managed SRS forwarding and ARC if you want the protocol complexity handled for you.