SRS: what does it do in email flows?

SRS is a discreet topic, but an important one as soon as an email is forwarded automatically.

It comes into play mainly with redirection, external aliases, mailing lists, or gateways that relay a message to another mail system.

Without SRS, forwarding can break SPF, even when the original sender and the final recipient are legitimate. The message is not necessarily fraudulent, but the technical path becomes inconsistent.

What SRS means

SRS stands for Sender Rewriting Scheme.

Its role is to rewrite an email’s envelope address when a server forwards it to another destination.

This envelope address is the SMTP MAIL FROM, often visible later in the Return-Path. It is used notably to handle delivery errors, also called bounces.

SRS does not change the address the user sees in the “From” field. It works on the technical transport layer.

In other words:

SRS does not change the apparent author of the message. It changes the envelope address used during forwarding.

This difference is essential to understand why it matters.

Why forwarding often breaks SPF

SPF checks whether the IP address of the server sending the message is authorised by the envelope domain. Our article on SPF syntax and the 10-lookup limit explains the mechanism.

For a direct send, it is fairly simple. The sending server belongs to the domain, or to a platform listed in its SPF.

But with forwarding, the message goes through an intermediate server.

Example:

1. alice@example.com sends an email to contact@company.com;
2. company.com automatically forwards it to recipient@gmail.com;
3. Gmail receives the message from company.com’s server;
4. the envelope still carries alice@example.com.

Gmail then checks example.com’s SPF, but the IP it sees belongs to company.com’s server.

If that IP is not in example.com’s SPF, SPF fails.

The forwarding server did nothing wrong. It simply resent a message while keeping an envelope that does not belong to it.

How SRS fixes the problem

SRS fixes this mismatch by rewriting the envelope address at forwarding time.

Instead of relaying the message with:

MAIL FROM:<alice@example.com>

the forwarding server uses an address in its own domain, for example:

MAIL FROM:<SRS0=HHH=TT=example.com=alice@forwarder.tld>

The domain in the envelope then becomes forwarder.tld.

The final recipient checks the SPF of forwarder.tld, not example.com. If the forwarding server is authorised in its own SPF, the SPF check becomes consistent again.

SRS also encodes the original address in the new one. So if the message fails further down the line, the bounce can come back to the forwarding server, then be passed on to the original sender.

SRS0 and SRS1

You often see addresses starting with SRS0 or SRS1.

SRS0 usually corresponds to a first rewrite.

SRS1 appears when an already rewritten message is forwarded again. The mechanism avoids stacking overly long addresses and keeps a usable trace of the path.

The exact detail depends on the implementation, but the goal stays the same:

• prove that the rewritten address was generated by the forwarding server;
• prevent simple forgery;
• allow errors to come back;
• keep SPF consistent during the relay.

SRS therefore adds a form of technical traceability, without changing the message content.

What SRS does not do

SRS does not sign the content.

It does not replace DKIM.

It does not guarantee the message will be accepted.

Nor does it guarantee that DMARC will pass in every case.

Why? Because DMARC checks alignment with the domain shown in the “From” field.

After SRS, SPF can pass with the forwarder’s domain, but that domain is usually not aligned with the original sender’s visible domain.

In that case, DMARC often depends on DKIM. If the original DKIM signature is still valid and aligned with the visible domain, DMARC can pass.

If forwarding modifies the message, adds a footer, rewrites the subject or alters the body, DKIM can break. DMARC then becomes more fragile. Our DKIM “body hash did not verify” case study shows this mechanism in practice.

Where ARC comes in

ARC stands for Authenticated Received Chain.

ARC lets an intermediate server pass on to the final recipient the results of the checks it observed before forwarding.

It does not replace SRS. It adds context.

In a forwarded flow:

• SRS helps keep SPF consistent on the forwarder’s side;
• DKIM helps preserve the authenticity of the original message;
• DMARC checks alignment with the visible domain;
• ARC can help the final recipient understand that a message was authenticated before passing through a relay.

The major providers do not all treat ARC the same way, but it is becoming useful in architectures with forwarding, gateways and mailing lists.

Common cases where SRS matters

SRS becomes important as soon as a server resends messages that do not come from it.

You find it notably in:

• aliases forwarding to an external mailbox;
• domains redirecting all email to another mail system;
• mailing lists;
• anti-spam gateways relaying to Microsoft 365 or Google Workspace;
• migrations where an old server still forwards some accounts;
• hosting services offering simple forwarding.

In these cases, a lack of SRS can cause SPF failures, spam placement or rejections, depending on the original domain’s DMARC policy and the final recipient’s rules.

Points to watch

An SRS setup must be properly designed.

The important points:

• the domain used for SRS must have a consistent SPF;
• SRS addresses must be validated with a reliable secret;
• bounces must be decodable and correctly returned;
• generated addresses should not stay valid forever;
• logs must make it possible to understand a delivery incident;
• multiple forwarding hops must be taken into account.

A badly configured SRS can create other problems: lost bounces, forwarding loops, overly long addresses or hard diagnoses.

SRS and deliverability

SRS is not a magic deliverability tool.

It does not make a bad message legitimate.

It does not fix a poor IP reputation.

It does not protect against every side effect of forwarding.

But it avoids a very concrete problem: failing SPF only because a legitimate message was relayed by an intermediate server.

In a clean email architecture, SRS makes forwarding behaviour more technically honest. The forwarder is effectively saying: “I am the one relaying this message now, check my SPF for this step”.

Conclusion

SRS plays a precise role in email flows: it rewrites the envelope address during forwarding so that SPF does not fail because of the intermediate server.

It also preserves the return path for errors, which is essential to avoid lost or misrouted bounces.

But SRS does not replace DKIM, DMARC or ARC. It mainly addresses the SPF problem caused by forwarding.

For reliable email, it should be seen as an architecture building block: useful for redirection, external aliases, gateways and mailing lists, but to be combined with stable DKIM, consistent DMARC, ARC where relevant, and good control of the flows that forward messages.

If your redirections cause authentication failures, see Dharmail’s SPF, DKIM and DMARC audit and configuration service (page in French).