Sender Rewriting Scheme (SRS) coming to Office 365


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.

Details

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 (bob@fabrikam.com) to John's mailbox in Office 365 (john.work@contoso.com). John has set up auto-forwarding to his home email address (john.home@example.com).

Original message Auto-forwarded message
Recipient john.work@contoso.com john.home@example.com
P1 From bob@fabrikam.com john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com
From header bob@fabrikam.com bob@fabrikam.com

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 (bob@fabrikam.com) to John's mailbox (john.onprem@contoso.com) on his company's own Exchange server. John has set up auto-forwarding to his home email address (john.home@example.com).

Original message Relayed message received by Office 365 Relayed message sent from Office 365
Recipient john.onprem@contoso.com john.home@example.com john.home@example.com
P1 From bob@fabrikam.com bob@fabrikam.com bounces+SRS=44ldt=IX=fabrikam.com=
bob@contoso.com
From header bob@fabrikam.com bob@fabrikam.com bob@fabrikam.com

Find out more about the draft SRS standard that this change took design ideas from, here: http://www.openspf.org/SRS

Sean Stevenson

Comments (10)

  1. Anonymous says:
    (The content was deleted per user request)
  2. Anonymous says:
    (The content was deleted per user request)
  3. Satyajit321 says:

    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.

  4. 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.

    1. Nino Bilic says:

      @Keith – thanks, all fixed!

  5. Chao Lu says:

    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?

  6. Jan Hajek says:

    Is this going to work with distribution groups as well?

    1. Yes, this works for Distribution Group which has external contact as member

  7. Anonymous says:

    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?

  8. DK says:

    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

Skip to main content