How to implement SRS for forwarding services so forwarded mail passes SPF and DMARC more consistently

Forwarding breaks SPF for a very simple reason: the server delivering the message to the final recipient is no longer the original sender.

That means the receiving system checks the forwarder's IP address against the original MAIL FROM domain, and the answer is often spf=fail even though the original message was legitimate.

SRS, short for Sender Rewriting Scheme, is the usual fix for that part of the problem.

It does one very specific thing: when the forwarder relays mail, it rewrites the envelope sender so the next receiver evaluates SPF against the forwarder's domain instead of the original sender's domain.

That is useful, but it is also where a lot of admin confusion starts.

SRS can make forwarded mail pass SPF more consistently. It does not automatically make forwarded mail pass DMARC, because DMARC only uses SPF if the SPF-authenticated domain aligns with the visible From: domain. In many forwarding flows, that alignment still does not exist.

So the correct mental model is:

• SRS helps forwarding survive SPF checks
• DKIM is still the main way forwarded mail survives DMARC
• ARC can give receivers extra context when they evaluate forwarded mail

If you want the broader forwarding background first, read DMARC forwarding and mailing lists: why SPF and DKIM fail (and how ARC helps).

What SRS is actually rewriting

SPF is defined around the SMTP envelope identity, especially the MAIL FROM domain in RFC 7208.

That point matters because SRS does not rewrite the visible From: header. It rewrites the bounce address used at SMTP level.

Without SRS, a forwarded message often looks like this at the final hop:

Original From: alerts@example.com
Original MAIL FROM: bounces@example.com

Forwarder connects to recipient MX from IP 203.0.113.44
Recipient checks SPF for example.com against 203.0.113.44
Result: SPF fail

With SRS in place, the same flow looks more like this:

Original From: alerts@example.com
Rewritten MAIL FROM: SRS0=HHH=TT=example.com=bounces@forwarder.example.net

Forwarder connects to recipient MX from IP 203.0.113.44
Recipient checks SPF for forwarder.example.net against 203.0.113.44
Result: SPF pass

That is the whole point of SRS. The forwarder takes responsibility for the new SMTP hop.

Google says this plainly in its forwarding guidance: if you forward mail to Gmail, change the envelope sender to reference your forwarding domain, and make sure that forwarding domain has correct SPF coverage. See Google's Best practices for forwarding email to Gmail.

Why forwarding breaks SPF in the first place

SPF answers a transport question, not an authorship question.

It asks whether the current SMTP client is authorized to use the envelope sender domain. After forwarding, the current SMTP client is the forwarder.

That is why RFC 7960 calls out forwarding as a DMARC interoperability problem. If a forwarder keeps the original MAIL FROM, SPF will usually fail unless that forwarder is somehow part of the original sender's authorized infrastructure.

In other words, forwarding does not mean the original sender became invalid. It means SPF is being asked a different question at the next hop.

What SRS fixes, and what it does not fix

This is the part worth getting exactly right.

What SRS fixes

SRS fixes SPF validation for the forwarded hop by replacing the original envelope sender with one under the forwarder's control.

That gives you these practical benefits:

• forwarded mail is less likely to hard-fail SPF at the next receiver
• backscatter handling is cleaner because bounces come back to the forwarder that actually re-sent the message
• receivers like Gmail get a sender identity that matches the infrastructure they are seeing

What SRS does not fix

SRS does not create DMARC alignment with the original visible From: domain.

Example:

From: alerts@example.com
MAIL FROM after SRS: SRS0=...@forwarder.example.net
SPF: pass for forwarder.example.net
DMARC SPF alignment with example.com: fail

That outcome is normal.

RFC 7960 is explicit about this: if the forwarder replaces the original MAIL FROM with its own domain, SPF might pass, but identifier alignment with the From: domain fails. In those cases, DKIM is usually the only way DMARC still passes.

So if anyone on the team expects SRS alone to "make DMARC pass", reset that expectation early.

When SRS is the right thing to deploy

Implement SRS when your service acts as a real forwarder or aliasing layer and preserves the visible author identity.

Typical cases:

• mailbox forwarding from one address to another
• alumni or vanity-domain forwarding services
• role-address forwarding such as sales@example.org to another mailbox
• inbound routing services that accept mail for one domain and forward it elsewhere

If your service re-sends mail as a new message with a new visible sender identity, you may be solving a different problem. SRS is specifically for forwarding and similar indirect flows.

A practical implementation pattern

Different MTAs and forwarding platforms expose SRS differently, but the durable design is the same.

1. Rewrite only when you are forwarding mail onward

Directly delivered mail does not need SRS.

Apply SRS on the hop where your service accepts a message for one recipient and then re-transmits it to a different downstream destination.

2. Use a domain you control for the rewritten envelope sender

Common patterns look like this:

• forwarder.example.net
• bounces.forwarder.example.net
• srs.example.net

Keep it operationally separate from customer-visible identities if you can. It makes header inspection and incident response much easier later.

3. Publish SPF for the SRS domain

The rewritten domain must authorize the servers that will perform the forwarding.

Example:

srs.example.net. TXT "v=spf1 ip4:203.0.113.44 ip4:203.0.113.45 -all"

If the SPF record for the SRS domain is wrong, SRS buys you nothing. You just moved the failure to a different domain.

If SPF design needs a refresher, SPF redirect vs include, and common SPF mistakes and SPF 10-DNS-lookup limit: why it happens, how to audit includes, and mitigation patterns are the two posts most teams need here.

4. Preserve reversibility for bounce handling

An SRS address is not just a random alias. It must carry enough information for your forwarder to map a later bounce back to the original recipient path safely.

Operationally, that usually means the rewritten local part encodes:

• the original sender domain
• the original envelope sender local part or a lookup token
• a timestamp or age marker
• a cryptographic hash or secret-derived validation token

That validation piece matters. Otherwise, your forwarder can become a bounce forgery gadget.

5. Expire old SRS addresses

Do not treat rewritten addresses as valid forever.

Time-bounded SRS tokens reduce abuse surface and keep your bounce-processing state manageable. Exact retention depends on your environment, but the common goal is simple: allow delayed bounces for a reasonable period, then reject stale ones.

6. Keep the visible message as untouched as possible

SRS helps SPF. DKIM survivability still depends on not breaking the message.

That means the forwarding service should avoid unnecessary changes to:

• Subject
• MIME structure
• body content
• signed headers such as Date, To, or Message-ID

Google's forwarding guidance specifically warns that message changes can break DKIM and make forwarded mail more likely to land in spam. If you want a deeper treatment of that failure mode, see DKIM canonicalization and common breakage (footers, link tracking, MIME changes; why "DKIM=fail" happens).

What a good forwarded message path looks like

The healthiest forwarded flow usually looks like this:

1. Original sender signs with aligned DKIM.
2. Forwarder rewrites the envelope sender with SRS.
3. Forwarder avoids modifying the message body and signed headers.
4. Receiver sees SPF pass for the forwarder domain.
5. Receiver also sees the original DKIM survive and align with From:.
6. DMARC passes because aligned DKIM survived, even though SPF alignment to the original author domain did not.

That is the realistic target.

Should forwarders also add ARC?

Usually, yes.

SRS and ARC solve different parts of the problem:

• SRS rewrites the envelope sender so the new SMTP hop can pass SPF
• ARC preserves prior authentication context for downstream receivers

Google recommends ARC for forwarders and mailing lists in its sender guidance, and Microsoft also documents ARC handling for trusted sealers. That does not mean ARC overrides DMARC everywhere, but it can help receivers make better decisions about indirect flows.

If ARC is part of your roadmap, these are the follow-up reads:

• What is ARC in email and how does it work? (Authenticated Received Chain explained)
• Should you deploy ARC as a domain owner, a forwarder, or both?
• Trusted ARC sealers at mailbox providers (Microsoft 365/Google): when ARC can influence DMARC outcomes and when it cannot

Common SRS mistakes that create new problems

Rewriting the wrong identity

SRS is for the envelope sender, not the visible From: header.

If you start rewriting From: to make DMARC pass, you are no longer doing classic forwarding. You are changing visible authorship semantics, and users will notice.

Forgetting SPF on the rewrite domain

This is the most ordinary failure: SRS gets enabled, the rewritten address looks correct, but the forwarding domain itself has no valid SPF authorization.

The final receiver then reports spf=none or spf=fail on the SRS domain.

Breaking DKIM after fixing SPF

This is the painful one.

Teams implement SRS, see SPF improve, then still get DMARC complaints because the forwarder adds banners, footers, subject prefixes, or MIME changes that break the only aligned DKIM signature.

Using the same domain everywhere without operational separation

Keeping customer-facing mail, bounce handling, and forwarding rewrite identities all mixed into one namespace makes troubleshooting harder than it needs to be.

Dedicated subdomains are cheap. Confusing incident response is expensive.

Treating SRS as optional for a serious forwarding service

Google's forwarding recommendations are not subtle here. If you operate a forwarding service and keep the original envelope sender unchanged, you should expect more SPF failures and worse downstream handling.

A test plan that catches real issues

After enabling SRS, test with messages that have:

1. aligned DKIM that should survive forwarding
2. no DKIM at all
3. fragile DKIM that breaks if the message is modified
4. different recipient providers, especially Gmail and Microsoft-hosted inboxes

For each delivered sample, inspect at least:

• Return-Path
• Authentication-Results
• DKIM-Signature
• any ARC-* headers if you add ARC

You want to confirm these questions separately:

1. Did SPF pass for the SRS domain?
2. Did DKIM from the original sender survive?
3. Did DMARC pass, and was that because of DKIM rather than SPF alignment?

That last question matters because a lot of post-change reports say "SRS fixed DMARC" when what really happened is "SRS fixed SPF noise while DKIM was already carrying DMARC."

For faster header analysis, keep DMARC troubleshooting with real headers: interpreting Authentication-Results, alignment failures, and typical fixes nearby.

Bottom line

If your service forwards mail, implement SRS.

It is the standard operational answer to SPF breakage on forwarded hops, and mailbox providers like Google explicitly recommend rewriting the envelope sender for forwarders.

But do not oversell what it does.

SRS improves SPF consistency for forwarded mail. DMARC still depends mainly on aligned DKIM surviving the forward, and ARC may add useful trust context on top. When those pieces are designed together, forwarded mail behaves much more predictably.