Sender Rewriting Scheme Upcoming Changes

[The_Exchange_Team]

Starting in August 2023, the change to some forwarded messages will roll out. After the change, SRS will be used to rewrite these messages instead of the forwarding mailbox being used. This will consolidate all forwarding methods to use SRS in Exchange Online. This rollout is outlined in the Message Center post MC649482.

The implementation of SRS in Exchange Online has been available for over 2 years now, but it is something we still focus on to ensure that the feature is as comprehensive and concise as possible given the many ways there are to forward messages and different routing scenarios.

There are three upcoming changes in Exchange Online that will affect SRS:

1. New on-premises connector setting

We are introducing a new SRS parameter on outbound on-premises connectors that allow admins to turn on SRS rewrites for messages using those connectors. Today, traffic to on-premises is not rewritten, as on-premises is considered part of the trust boundary where SPF checks should not take place. With some customers routing traffic out of their on-premises environments to the Internet, this setting provides a solution and traffic can be rewritten if needed. The new setting rolling out now, which can be configured by the New-OutboundConnector or Set-OutboundConnector cmdlets, is SenderRewritingEnabled.

2. Change in rewriting for SMTP/mailbox forwarding

We are further consolidating our rewriting for message forwarding. Not all forwarded messages are rewritten using SRS today. Messages forwarded with SMTP or mailbox forwarding have their P1 Mail From address replaced with the forwarding mailbox address. This will change to using SRS rewriting instead.

This is a behavior change that may result in some disruptions. For one, SRS does not rewrite messages destined for on-premises while the current rewriting process does. This could cause forwarded messages sent to or via on-premises to be rejected by the final recipient or a filtering device along the way.  The setting in #1 has been provided to fix this gap and allow messages to still be rewritten after this change in behavior. Update: we will share more information when we start rolling out the change. Our recommendation is that customers routing messages to the Internet via their on-premises servers should proactively enable the new setting on their connectors. You can find out more about SRS here.

3. Skipping SRS if incoming message did not pass SPF

The rollout of the new relay pool (announced in the Message Center post MC266466) will result in some messages no longer being rewritten. The aim of SRS is to allow a message to pass SPF checks when it is forwarded or relayed to another destination. However, if the message did not pass SPF when it was received by Exchange Online, that result should be preserved. The relay pool rollout will ensure this. The change will also affect spoofed domains (messages sent using non-accepted domains) from on-premises which will be sent via the relay pool to break SPF. For the timeline, please refer to MC266466 and here.

The main effect to look out for with these upcoming changes is that messages leaving the service start getting rejected by the receiving party.

The Exchange Team

[triw_]

Can someone tell me how to enable this feature? Does this feature work for distribution list with on-premises external email?

[Gregor Schillinger]

@triw_ Set-OutboundConnector Name -SenderRewritingEnabled:$true

Eventually the parameter is not yet available in your tenant as it is still in rollout phase.

[WSDChristina]

Does this also affect the forwarding set for shared mailboxes?

[Rezakgharfara]

We would like to understand what changes to the forwarding message headers:

today we have the following headers in the message

SMTP fowarding:

X-MS-Exchange-ForwardingLoop:  < this has the forwarding address>

Inbox rule forwarding:

X-MS-Exchange-Inbox-Rules-Loop: <this has the forwarding address>

[Rezakgharfara]

Can MS provide more information on the messages headers and what would change there  with some samples. that would be very helpful

[Lukas Sassl]

@Rezakgharfara I'd recommend reading the following blog post to get a better understanding of these headers: 

Loop Prevention in Exchange Online Demystified - Microsoft Tech Community

[triw_]

Hi @Gregor Schillinger My understanding is the SRS feature will works with on-premises connectors only. Is it possible this feature works for outside organization distribution lists member without create a connector?

[Gregor Schillinger]

@triw_ this is not an on-prem setting. This is for cloudconnectors that route mails from cloud to on-prem via outboundconnectors. 

[Dolinhas]

My Office365 outbound connector only connects to my on-prem exchange boxes. 

We do not host any mailboxes on-prem - I think we only have these servers to create mailboxes as we are hybrid.

Do we need or do we benefit from turning this setting on?

[triw_]

Hi @Gregor Schillinger Much appreciated if you have any recommendation the best practice for distribution list including third party/external domain as the member. Currently I am facing issue with SPF fail for the external member who enable SPF check on their mail security 

[Gregor Schillinger]

@Dolinhas if you are not routing any mails over on-prem to the internet there is no benefit with #1

[Gregor Schillinger]

@triw_ I think we need more details on the setup and situation. If you like drop me a PN.

[kevets]

Same scenario as @triw_ but we are on the receiving end and our users' domain is being impersonated when they are external guest members of this distro group in a different org. So would this be a setting change in their org to accommodate for this?

[Tero Voutilainen]

Is there a way to disable the SRS when there is no on-prem Outbound Connectors in use at the tenant?

It breaks NDR delivery in auto-forward scenario for example during tenant-to-tenant mailbox migration project. Source tenant mailbox uses Quest Email Address Rewrite service to modify ReturnPath but if user has a typo on the address the NDR message’s ReturnPath header is rewritten by the target tenant SRS to bounce@defaultdomain.onmicrosoft.com and the original user is not receiving the NDR message. Therefore, this would be good to be able to disable as well during the migration project time without the option to route everything through on-prem / smarthost.

[YuriySamorodov]

Is there any way to confirm SRS is enabled on Partner connector?

[TheRealAQ]

We need to be able to enable SRS on a Partner connector. Not all companies route emails the same way. Surely MS will account for this. 

[mannychandra]

It Seems All Outbound connectors are affected whether it be to on-premise servers or Partner Connector to a third party mail filter. The default config is SenderRewritingEnabled : False

You check this on your outbound connectors

Get-OutboundConnector -Identity "Outbound connect name" | fl SenderRewritingEnabled

I think Microsoft should be a lot clearer on terminology rather then stating "On Premise Connector" they not state all Outbound Connectors

[vettamatt]

How is the domain determined that's used in the domain part of the envelope sender / return path?

This needs to match the "from domain" for DMARC compliance.

[jumpinjoey]

@vettamatt the following URL Sender Rewriting Scheme (SRS) in Microsoft 365 | Microsoft Learn mentions that it doesn't fix the DMARC issue :(

[Jim_Mueller]

I've had a case open with 365 Support for two months now and we continue to chase our tails. They pointed us to this URL about upcoming SRS features that could help us.

All our mailboxes are in the cloud, but we have ~400 DDGs spread across ~100 e-mail domains for remote offices that existed prior to migration to Exchange Online. We don't have SPF, DMARC or DKIM records on any of the domains which we do not send from.

Actual user mailboxes only send from 3 of these domains so most of those domains are receive only. Those DDGs reference OUs and custom attributes that won't sync to O365 and it'd be a nightmare to redesign them. Because the DDGs need to be expanded by the hybrid on-premise server, external email goes first to the (pre-O365) 3rd-party security service (our MX record), which relays to the Exchange 2013 hybrid server. Hybrid re-routes to final destination on O365, with no e-mail services in between hybrid and cloud. Yes, I know 2013 is out of support recently, but I've been hampered by 1) unclear directions on how to migrate it to a later Exchange on a later OS and 2) internal management's desire to place a different project higher on the priority list.

The challenge we have is that after enabling Defender for Office 365 in mid-April, we get a ton of false phishing positives being quarantined. We noticed one scenario where a message coming from an external domain such as gmail.com which was sent to a DDG, will have its sender address rewritten as the e-mail address of the DDG. In the quarantine portal, it shows that the sender was from an internal domain and not gmail.com, which I believe is at least part of our false positive problem.

We have two enabled outbound connectors on the hybrid, with different weighting. The connector which goes to O365 has a scoping cost of 1, and the one which goes direct to internet has a scoping cost of 10. 

I cannot locate anything on the hybrid outbound connectors talking about rewriting, and that doesn't surprise me due to its age. But 1) I see nothing about SRS in the HCW, 2) it's not referenced in the cloud inbound router, and 3) it's false in the cloud outbound connector. 

Will any of these upcoming SRS changes alleviate our situation? If not, any other ideas towards resolution?

[Jim_Mueller]

@Gregor Schillinger I continue to pull my hair out with MS support on my above issue. Might you have any useful information for us?

[Marshaladex]

Does this only apply to On-premises connectors or it applies to partner connectors too

[Deleted]

@The_Exchange_Team possible to enable SenderRewritingEnabled. on partner connectors?