Sender Rewriting Scheme (SRS) in Microsoft 365
Note
In August 2023, a change will be rolled out to SMTP or mailbox forwarded messages. Moving forward, SRS will be used to rewrite these messages instead of the forwarding mailbox. This will consolidate forwarding methods to all use SRS in Exchange Online. While SRS is designed to avoid disruptions to forwarded messages, some special cases could see issues. One case from this change is that messages being relayed to the internet via on-premises servers will not be rewritten with SRS. To avoid this behavior change, see the new setting covered here: Sender Rewriting Scheme Upcoming Changes.
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 entering Exchange Online so that SRS does not fix these failures. For more information, see the relay pool documentation here: Outbound delivery pools.
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.
Note
The From header, also known as the Display From address or P2 From address, that is displayed by email clients remains unchanged.
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.
Note
SRS rewriting doesn't fix the issue of DMARC passing for forwarded messages. Although an SPF check will now pass due to the rewritten P1 From address, DMARC also requires an alignment check for the message to pass. For forwarded messages, DKIM always fails because the signed DKIM domain doesn't match the From header domain. If an original sender sets their DMARC policy to reject forwarded messages, the forwarded messages are rejected by Message Transfer Agents (MTAs) that honor DMARC policies. The ARC standard was developed to address DKIM's issues with forwarding and has been implemented in our service to address those issues.
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 (bob@fabrikam.com) to John's mailbox in Exchange Online (john.work@contoso.com). John has autoforwarding set up from this mailbox to his home email address (john.home@example.com). Notice how the P1 From address is rewritten by SRS.
| Original message | Autoforwarded 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 |
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 (bob@fabrikam.com) to John's mailbox (john.onprem@contoso.com) 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 (john.home@example.com). 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.
| Type | Original message | Relayed message received by Exchange Online | Relayed message sent from Exchange Online |
|---|---|---|---|
| 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@contoso.com |
| From header | bob@fabrikam.com |
bob@fabrikam.com |
bob@fabrikam.com |
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