Sender Rewriting Scheme (SRS) in Microsoft 365

The Sender Rewriting Scheme (SRS) functionality was added to Microsoft 365 to resolve a problem in which autoforwarding was incompatible with SPF. The SRS feature rewrites the P1 From address (also known as the Envelope From address) for all applicable messages that are sent externally from Microsoft 365.

The SRS functionality improves the delivery of applicable messages that pass Sender Policy Framework (SPF) checks when they arrive from the original sender but fail SPF checks at the final external destination after they're forwarded.

SRS rewrites the P1 From address in the following scenarios:

• Messages in Microsoft 365 that are autoforwarded (or redirected) to an external recipient by using any of the following methods:
  • SMTP forwarding
  • Mailbox Rule (or Inbox rule) redirection
  • Mail flow (Transport) Rule redirection
  • Groups or DLs that have external members
  • Mail Contact forwarding
  • Mail User forwarding
• Messages that are autoforwarded (or redirected) from a customer's on-premises environment and relayed through Exchange Online.

It's important to note that SRS rewriting is used to prevent spoofing of unverified domains. You should send messages only from domains that you own and for which you've verified your ownership through the Accepted Domains list. For more information about Accepted Domains in Microsoft 365, see Manage accepted domains in Exchange Online.

This failure scenario along with other delivery failures cause Non-Delivery Reports (NDRs) to be returned to Exchange Online instead of to the original sender when SRS rewriting isn't used. Therefore, part of the SRS implementation is to reroute returning NDRs to the original sender if a message can't be delivered.

The following sections present different autoforwarding scenarios and information on how SRS handles them.

Autoforwarding emails for a mailbox hosted on Microsoft 365

For a message that is sent to a hosted mailbox and is autoforwarded by using mechanisms such as SMTP forwarding, Mailbox Rule redirection or Transport Rule redirection, the P1 From address is rewritten before the message leaves Exchange Online. The address is rewritten by using the following pattern:

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

In the following example, a message is sent from Bob ([email protected]) to John's mailbox in Exchange Online ([email protected]). John has autoforwarding set up from this mailbox to his home email address ([email protected]). Notice how the P1 From address is rewritten by SRS.

When SRS rewrites the P1 From address, it increases the length of the username portion of the email address. However, the email address has a limit of 64 characters. So if the length of the rewritten email address exceeds 64 characters, it takes the following form:

bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>

where <Default Accepted Domain> is the name of the default Accepted Domain set up for the tenant.

Relaying from a customer's on-premises server

When a message that originates from a non-verified domain is relayed from a customer's on-premises server, or an application through Exchange Online, the P1 From address is rewritten before it leaves Exchange Online. The address is rewritten by using the following pattern:

bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>

In the following example, a message is sent from Bob ([email protected]) to John's mailbox ([email protected]) which is on his company's server that is running Exchange Server. John has autoforwarding set up from this mailbox to his home email address ([email protected]). Notice how the P1 From address is rewritten by SRS in this scenario. Customers are encouraged to set the default accepted domain to one of their own domains.

In some situations, the relayed messages that are rewritten by SRS might not get delivered, and an NDR might be generated.

To receive those NDRs, the tenant administrator must create a mailbox named "bounces" that is hosted either on Exchange Online or on-premises. The domain for this mailbox must be set to the default accepted domain for the tenant.

Forwarded messages sent to a customer's on-premises server

By design, SRS considers on-premises servers to be within the trust boundary and doesn't rewrite forwarded messages that are bound to on-premises. However, for complex routing configurations that use on-premises servers to route messages to the Internet, the forwarded messages without SRS rewriting are subject to rejections due to SPF failure. To solve this issue, administrators can enable SRS for traffic flowing through an on-premises outbound connector. The SenderRewritingEnabled setting can be used to do this and is configurable using the New-OutboundConnector or Set-OutboundConnector cmdlets.

This setting doesn't apply for partner connectors which handle messages to external recipients and it's mandatory for these messages to have SRS applied to them if needed. The SenderRewritingEnabled setting will show as true for partner connectors and an error is returned for any attempts to set its value.

Mail Flow (Transport) redirected messages

Given that a message can be redirected by a rule for any reason, not just because of a certain recipient, there's no concept of a forwarding mailbox. With that in mind, the SRS rewritten address takes the following form:

bouncesEtr+SRS=<Hash>=<Timestamp>=<OrigSenderDomain>=<OrigSenderUser>@<Default Accepted Domain> 

To receive NDRs, your tenant must be able to receive messages addressed to a user named "bouncesETR" in order for us to redirect the message to the original sender. For example, Directory-Based Edge Blocking could interfere with returning NDRs if no such mailbox exists in your tenant.

Relay pool and skipping SRS

The relay pool feature has been introduced in Microsoft 365 which affects SRS rewriting behavior. Messages that qualify for this relay pool skip being rewritten by SRS and are sent out of IPs that aren't part of the Microsoft 365 SPF record. This mainly affects messages that fail SPF checks when they are first sent to Exchange Online as SRS shouldn't fix these failures with its rewriting. For more information, see the relay pool documentation here: Outbound delivery pools