Sender Rewriting Scheme: what SRS fixes in forwarded email
Understand envelope-sender rewriting, SPF, DMARC alignment, and the evidence to collect when forwarded email fails.
Sender Rewriting Scheme, usually shortened to SRS, helps an email forwarder handle a specific authentication problem: the final receiving server sees the forwarder’s IP address, rather than the original sender’s server. A normal SPF check against the original envelope-sender domain may therefore fail.
SRS rewrites that envelope sender to an address controlled by the forwarding service. It is useful plumbing for forwarding, but it does not guarantee inbox placement or make every forwarded message pass DMARC.
The address on the envelope is not the visible From address
Email has a transport-level sender, supplied in SMTP’s MAIL FROM, and the From header your mail application displays. Microsoft’s SRS documentation explains that SRS changes the former, not the visible From header.
| Field | Before forwarding | After SRS |
|---|---|---|
| Visible From | [email protected] | [email protected] |
| Envelope sender | [email protected] | An encoded address at forwarder.example |
| Server connecting to the destination | The original sender’s server | The forwarding service |
If you see a long rewritten address in a Return-Path field, that alone is not evidence of compromise. Inspect the delivery path and authentication results. Conversely, a familiar visible From address alone is not proof that the message is authentic.
Why SPF passing still may not satisfy DMARC
Microsoft explicitly notes that SRS does not solve DMARC alignment by itself. SPF can pass for the forwarding domain while that domain differs from the visible From domain. An intact, aligned DKIM signature can allow DMARC to pass through the other authentication path.
ARC serves a related but different purpose. Cloudflare’s postmaster documentation describes ARC as a way for intermediaries to preserve authentication information. The receiving system evaluates that chain and its own policy; ARC is not a universal promise that a forwarded message will be accepted.
Cloudflare’s email lifecycle documentation places incoming authentication checks before routing, followed by ARC signing and SRS rewriting for forwarded messages. That sequence matters: rewriting is not a way to turn an unauthenticated incoming message into a trusted original sender.
What a domain owner should configure
If you buy a forwarding service, start by checking whether it handles SRS and ARC and which DNS records it requires. You usually need the service’s supported setup, not a hand-written SRS address. Avoid adding arbitrary forwarding IPs to someone else’s sender policy; you do not control the original sender’s domain.
If you operate the mail server, use the implementation’s current documentation for rewriting, bounce handling, secrets, and supported forwarding paths. A copied example string is not a working SRS implementation. Confirm how the software handles loops and invalid bounces before relying on it for business mail.
A practical investigation when forwarded mail fails
- Confirm the original delivery. Did the first mailbox or forwarding service actually receive the message?
- Find the forwarding attempt. Use its timestamp, destination, and message identifier to locate the provider’s event.
- Read the rejection. Distinguish an unknown recipient, quota, temporary delivery failure, authentication failure, and spam classification.
- Inspect authentication at the destination. Compare the SPF domain, DKIM signing domain, visible From domain, and any ARC results.
- Compare direct and forwarded delivery. Use the same legitimate sender and recipient to narrow the problem to the forwarding path.
Share relevant headers and error codes privately with support, redacting message content and personal addresses where possible. Do not weaken the entire domain’s authentication policy merely because one forwarded message failed. First identify which hop changed the result and which provider can correct it.
For occasional forwarding, a supported service may be enough. For a business address that must reliably send and receive in its own identity, evaluate a dedicated hosted mailbox as well. That choice can simplify the workflow, although every mail service still depends on correct authentication and recipient policies.