Sender Rewriting Scheme (SRS) in Office 365
Original KB number: 4490129
- 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 November 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. For more information, see Sender Rewriting Scheme Upcoming Changes.
Sender Rewriting Scheme (SRS) functionality was added to Office 365 to resolve a problem in which autoforwarding is 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 Office 365. It is important to note that the From header (also known as the Display From address or P2 From address) that is displayed by email clients remains unchanged.
This SRS change improves deliverability of applicable messages that pass Sender Policy Framework (SPF) checks when they arrive from the original sender but that then fail SPF at the final external destination after they are forwarded.
SRS rewrites the P1 From address in the following scenario:
- Messages that are autoforwarded (or redirected) in Office 365 by using any of the following methods to forward a message to an external recipient:
- SMTP forwarding*
- Mailbox Rule (or Inbox rule) redirection
- Transport Rule redirection
- Groups or DLs that have external members
- Mail Contact forwarding
- Mail User forwarding
- Messages that are autoforwarded (or redirected) from our customer's on-premises environments and relayed through Office 365.
*Some messages forwarded with SMTP Forwarding will not be rewritten with SRS as they have already been rewritten.
SRS rewriting does not fix the issue of DMARC passing for forwarded messages. Although an SPF check will now pass by using a 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 does not 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.
This change causes Non-Delivery Reports (NDRs) to return to Office 365 instead of the original sender, as they would do if SRS were not used. Therefore, part of the SRS implementation is to reroute returning NDRs to the original sender if a message cannot be delivered.
SRS rewriting is used to prevent spoofing of unverified domains. Customers are advised to send messages only from domains that they own and for which they have verified their ownership through the Accepted Domains list. For more information about Accepted Domains in Office 365, see the following TechNet topic:
Autoforwarding emails for an Office 365-hosted mailbox
A message that is autoforwarded for a hosted mailbox by mechanisms such as SMTP forwarding or Mailbox Rule redirection or Transport Rule redirection have the P1 From address rewritten before the message leaves Office 365. The address is rewritten by using the following pattern:
<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>
A message is sent from Bob (email@example.com) to John's mailbox in Office 365 (firstname.lastname@example.org). John has set up autoforwarding to his home email address (email@example.com).
|Original message||Autoforwarded message|
SRS rewriting causes the username part of an email address increasing in length. However, the email address has a limit of 64 characters. If the email address involves the SRS rewriting and exceeds 64 characters, the rewritten SRS address will take the form of "bounces" below.
Relaying from a customer's on-premises server
A message that is relayed from a customer's on-premises server or application through Office 365 from a non-verified domain has the P1 From address rewritten before it leaves Office 365. The address is rewritten by using the following pattern:
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
In order to receive NDRs for relayed messages that are rewritten by SRS, a mailbox (either hosted or on-premises) must be created by using the username of "bounces" and by having the domain be set as the default Accepted Domain of the customer.
A message is sent from Bob (firstname.lastname@example.org) to John's mailbox (email@example.com) on his company's own server that is running Exchange Server. John has set up autoforwarding to his home email address (firstname.lastname@example.org).
|Type||Original message||Relayed message received by Office 365||Relayed message sent from Office 365|
Forwarded messages sent to a customer's on-premises server
By default, SRS considers on-premises servers to be within the trust boundary, and doesn't rewrite forwarded messages bound to on-premises. However, some customers have complex routing configurations that use their on-premises servers to route messages to the Internet. Therefore, the forwarded messages won't be rewritten, and will be rejected due to SPF failure. To solve this problem, we added a setting to allow the administrators to enable SRS rewrite for traffic flowing through an on-premises outbound connector. For more information about this new connector parameter, see Sender Rewriting Scheme Upcoming Changes.
Microsoft provides third-party contact information to help you find additional information about this topic. This contact information may change without notice. Microsoft does not guarantee the accuracy of third-party contact information.