Sender Rewriting Scheme (SRS) coming to Office 365

Published Jun 15 2018 08:02 AM 35.5K Views

The introduction of email authentication mechanisms like SPF, DKIM, and DMARC have improved email security and spoofing prevention. However, some scenarios have been disrupted by these authentication mechanisms, namely auto-forwarding and relaying. Here in Office 365, we are committed to ensuring the security of our customers and the general integrity of the email ecosystem that we are a part of. From July 16th, we will begin rolling out Sender Rewriting Scheme (SRS) functionality to solve the problem of auto-forwarding being incompatible with SPF. The SRS feature will rewrite the P1 From address (also known as the Envelope From address) for all applicable messages being sent externally from Office 365. The From header (also known as Display From address or P2 From address) which is displayed by email clients will remain unchanged. This change will improve deliverability of applicable messages since SPF checks that were failing in the past for such messages will now pass. Regarding ‘applicable’ messages, we anticipate the following scenarios will be affected and result in SRS rewriting the P1 From address:

  1. Messages that are auto-forwarded (or redirected) from hosted mailboxes using one of the supported methods – SMTP forwarding, Mailbox Rule (or Inbox rule) redirection, Transport Rule redirection.
  2. Messages that are auto-forwarded (or redirected) from our customer’s on-premises environments and relayed through Office 365.

Note: SRS rewriting would also rewrite the P1 From address of messages that are relayed from our customer’s on-premises environment, where the P1 From domain is NOT a verified domain. Customers should only be sending messages from domains in their Accepted Domains list. Find out more about Accepted Domains in Office 365 here.

This change results in Non-Delivery Reports (NDRs) returning to Office 365 instead of the original sender as it occurs today without SRS. Part of the SRS implementation, therefore, is to reroute returning NDRs to the original sender in the case where a message could not be delivered.


Auto-forwarding emails for an Office 365 hosted mailbox

A message auto-forwarded for a hosted mailbox by mechanisms such as SMTP forwarding or Mailbox Rule redirection or Transport Rule redirection will have the P1 From rewritten before it leaves Office 365 using the following pattern:

<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>

Example: A message is sent from Bob ( to John's mailbox in Office 365 ( John has set up auto-forwarding to his home email address (
Original message Auto-forwarded message
P1 From
From header

Relaying from a customer's on-premises server

A message relayed from a customer's on-premises server or application through Office 365 from a non-verified domain will have the P1 From address rewritten before leaving Office 365 using the following pattern:

bounces+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Customer's Default Accepted Domain>

Important: In order to receive NDRs for relayed messages that are rewritten by SRS, a mailbox (either hosted or on-premises) needs to be created with the username 'bounces' and the domain being the default Accepted Domain of the customer. Example: A message is sent from Bob ( to John's mailbox ( on his company's own Exchange server. John has set up auto-forwarding to his home email address (
Original message Relayed message received by Office 365 Relayed message sent from Office 365
P1 From
From header
Find out more about the draft SRS standard that this change took design ideas from, here: Sean Stevenson
Not applicable
That's a good start. can you clarify how is this TIMESTAMP used and how long is the expiry. However it doesn't solve the problem on the senders having DMARC implementation which would continue to fail. What are the plans around that, Authenticated Received Chain (ARC) is suppose to sort that out.
Not applicable
on-premise? I believe the correct grammar is on-premises or on-prem for short.

Also, I believe there is a typo in the last sentence as it doesn't make any sense.

Not applicable
@Keith - thanks, all fixed!
Not applicable
If the P1 address has been re-written, it will be different from P2 address, which will bring the risk to fail the DMARC validation, is this a potential problem caused by SRS?
Not applicable
How will we know that this has been rolled out to us?
Not applicable
Is this going to work with distribution groups as well?
Not applicable
Yes, this works for Distribution Group which has external contact as member
Not applicable
How can I check if SRS has rolled out to a particular instance of Office365? Is this available on on-prem versions of Exchange as well?
Not applicable
Any status update on the roll-out of SRS. I'm not seeing any evidence of this on our tenant, but this post suggest it was to start rolling out in July
Not applicable
Will an Exchange Online Admin be able to force this. Like a address rewrite transport rule?

Not applicable
Any update on this? The roadmap still shows Q2.

I don't see this working in our tenant yet.

Any update on this? I am not seeing this working in our tenant

@Dan Myhre - Hey Dan, I checked in with engineering and there are a few places it isn't yet turned on due to a technical challenge we hit - aim is to resolve by end of August. Sorry for the delay. 

@greg Taylor - thanks for the update! Will look to re-test this in early September then. Thanks!
Occasional Visitor

@Greg Taylor - EXCHANGE  @Dan Myhre Hello Greg, Dan, I am also noticing the SRS does not seem to be active on multiple of my tenants. Is there any way to test/check this function and Dan, did it start working for you already? I notice it is no longer in the roadmap but available as a regular function described in


Thanks so much in advance!



@sietseklomp - The final SRS rollout to still going (it takes a while to touch every server we have) but most EXO tenants should have it enabled. SRS can be tested by setting up forwarding and checking forwarded emails for the rewriting of the Return Path header.


If you don't see SRS in a month, let us know and we can investigate.

Occasional Visitor

Dear @Greg Taylor - EXCHANGE,


Thank for your quick reply. 


Checking the return path, the SRS seems to work: 


 What I do not understand is that even though SRS seems to work, mails from sending.domain sent to a distribution list on our server and delivered to a different mailbox on sending.domain are bounced (by the mail server at sending.domain) due to spf violation. Our spf setting does not give problems if we send a message directly to sending.domain mailboxes, and their spf record should not be relevant due to the SRS. 


Looking further down in the mail headers I do notice a second Return Path field showing the actual sender address (no SRS) and the From field remains set to the actual sender address also. Any hints where I can check this: "The SRS feature rewrites the P1 From address (also known as the Envelope From address) for all applicable messages that are sent externally from Office 365"


Anyway, I am afraid to over-ask here and am already happy with the above feedback you gave me and the confirmation that SRS works and something else is causing these problems.


Thanks again! 



Occasional Visitor

Dear @Greg Taylor - EXCHANGE ,


We have identified the problem. It is not due to SRS failing (works fine and rewrites the P1 header). Problem is that the P2 header remains unchanged and Sender ID protection causes the message to bounce. We understand Microsoft has been working on implementing ARC to prevent this from happening, so we are hoping this becomes available soon. 


Thanks again for your support. 



Senior Member

Hi, Can the SRS rewrites the envelop-from address with primary address of the mailbox with auto-forward to external address?


If a message is forwarded in this way and the destination MTA rejects the message (for example, a large message size), Exchange Online sends the NDR to the address of the original recipient instead of the original sender.

In case of spam forwarding it is more interesting.


Is it possible to disable SRS on a specific tenant?

Occasional Contributor

@Greg Taylor - EXCHANGE 

Ist SRS still active in Exchange Online? Don't see the Headers wen autoforwarding Mails.


Regards Andres


Hi @Andres Bohren 


Yes, SRS is very much still being used. We are continuing to work on refining its behaviour.

We've documented the feature here: Sender Rewriting Scheme (SRS) in Office 365 - Office 365 | Microsoft Docs


As it mentions there are some scenarios where forwarded messages are already rewritten and therefore SRS will no rewrite the address.

Senior Member

When this feature rollout actually? Can someone tell me how to enable it?

Occasional Contributor


There is nothing you can configure.


Upcoming changes:

  • Starting in July 2021, we'll start to roll out a new relay IP pool, which may affect current SRS rewriting behaviour. Messages that qualify for this relay pool won't be rewritten by SRS, and be sent out of IPs that won't be part of the Microsoft 365 SPF record instead. The main change is for messages that fail SPF checks when they are sent to Office 365. SRS will no longer fix these failures. For more information, check the post about the relay pool change in Message Center or see Outbound delivery pools.
  • Starting in October 2021, we'll start to use SRS to rewrite all messages forwarded by using SMTP or mailbox forwarding. This will consolidate the behaviour to use SRS for all forwarding in the service. Due to changes in behavior, disruptions may occur. For example, messages sent to on-premises will no longer be rewritten.




Occasional Visitor

For on-premises send connectors - Does SRS rewriting parameter is available ?

Version history
Last update:
‎Jul 01 2019 04:33 PM
Updated by: