Blog Post

Exchange Team Blog

4 MIN READ

Updated Requirements for SMTP Relay through Exchange Online

Platinum Contributor

Jun 19, 2023

Update 11/13/2023: We added new information on how to know when this change is released to your organization.

Today, we are announcing an update to our requirements for SMTP relay through Exchange Online. If your organization does not use Inbound Connectors of OnPremises type then this change will not affect you.

Current Requirements

Currently, to relay email through Exchange Online, two conditions must be true:

Any of the following is an accepted domain of your organization:
1. SMTP certificate domain on the SMTP connection; or
2. SMTP envelope sender domain in the MAIL FROM command (P1 sender domain); or
3. SMTP header sender domain, as shown in email clients (P2 sender domain).
The sending host’s IP address or the certificate domain on the SMTP connection matches your tenant’s Inbound Connector of OnPremises type.

New Requirements

On November 1, 2023, we are removing the matching condition for the SMTP P2 sender domain (1c above). After we remove this condition, relaying email through Exchange Online will require the following:

Any of the following is an accepted domain of your organization:
1. SMTP certificate domain on the SMTP connection; or
2. SMTP envelope sender domain in the MAIL FROM command (P1 sender domain).
The sending host’s IP address or certificate domain on the SMTP connection matches your organization’s Inbound Connector of OnPremises type.

After November 1, 2023, if either of the above conditions are not met, the relay attempt from your on-premises environment to Exchange Online will be rejected.

This change may affect your organization’s email routing or delivery.

Possible scenarios that are affected by this change

Below are some examples of scenarios that are affected by this change, but there could be more:

Your organization hosts email on-premises, and you need to relay non-delivery reports (NDRs) generated by your on-premises system through Exchange Online. In this scenario, the NDRs often have null as the SMTP envelope sender (P1 sender), but the SMTP header sender domain (P2 sender domain) is your organization’s accepted domain in Microsoft 365.
Your organization uses an application hosted on-premises to send email and the SMTP envelope sender domain (P1 sender domain) is not an accepted domain in Exchange Online.
You use a third-party cloud service to relay messages by creating an Inbound Connector of OnPremises type. For example, when you use a cloud service platform to relay emails through Exchange Online, the SMTP envelope sender domain (P1 sender domain) will be the 3^rd party service’s domain (perhaps for bounce tracking), but the SMTP header domain (P2 sender domain) is your organization’s accepted domain in Microsoft 365.

Check if your organization is affected by this change

You can use the newly created extended report type to generate the report for your organization by running Start-HistoricalSearch, it will generate an extended report specific to this scenario, (see Start-HistoricalSearch documentation.) Some examples below. Replace the value of NotifyAddress below with your email admin email address.

Example 1:

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report all emails using non accepted domains as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com

Note: When running this cmdlet, the StartDate and EndDate should not be the same.

Example 2:

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report on emails using a specific sender domain (non accepted domain) as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com -SenderAddress *@MyDomain.com

Please note that senderAddress must be an accepted domain of your organization.

Example 3:

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report on emails for a recipient domain using non accepted domains as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com -RecipientAddress *@mycustomer.com

Please note that RecipientAddress CAN contain any domain that your organization send emails to.

You can use Get-HistoricalSearch to report the status of the extended report job:

Get-HistoricalSearch -JobId xxxx (where the xxxx is the JobID.)
If the job result (ReportStatusDescription) is “Complete – No results found”, that means you organization is not impacted by the scenario.

Actions to Take

To minimize the effects of this change before November 1, 2023:

If you need to relay emails from on-premises through Exchange Online, and some of these emails apply to the scenarios in the above section Possible scenarios that are affected by this change, you must update your Inbound Connector of OnPremises type to use a certificate domain (instead of IP addresses), in addition, you must add the certificate domain as an accepted domain of your organization. To learn more, see Configure a certificate-based connector to relay email messages through Microsoft 365.
If you need to use a third-party add-on service to process email messages sent from your organization and then relay through Exchange Online, the third-party service must support a unique certificate for your organization, and the certificate domain (in Subject name or SAN) must be an accepted domain of your organization. In addition, you must update your Inbound connector of OnPremises type to use the unique certificate domain, via property TlsSenderCertificateName. An example is that your organization uses a third-party CRM cloud service to send emails on behalf your organization to mailboxes of your company or other external users. To learn more, see Scenario: Integrate Exchange Online with an email add-on service.

How to know when this change will be available for your organization?

We will be notifying customers via Office 365 Message Center when this change is about to deploy into their respective rings, with a start and expected end time. The title for the message center post will be “Deployment time for Updated Requirements for SMTP Relay through Exchange Online”. If your organization has not received any notification yet, it is either not impacted by this change based on our report, or your organization is not a part of the next batch to get the feature deployed yet.

We will be updating this blog post (as well as posting in the Office 365 Message Center) when the entire deployment is completed, which currently is set to be by 3/31/2024.

Exchange Online Transport Team

Updated Feb 22, 2024

Version 19.0

Platinum Contributor

Joined April 19, 2019

View Profile

Exchange Team Blog

You Had Me at EHLO.

138 Comments

jvanbeusekom
Brass Contributor
Jun 21, 2023
Does this also affect Hybrid configurations? Or does HCW place an certificate on the connector(s) already.

And that this is only for "manual" created connectors...
Faber
Copper Contributor
Jun 21, 2023
Carolyn_Liu thanks for the answer but I'm a bit confused. I send for example from myapp @ mydomin.tld so what I need to check to verifiy "SMTP envelop sender domain" is correct?
Paul Robinson
Brass Contributor
Jun 20, 2023
I feel like nobody who works at Microsoft on Exchange has any clue how many of us are part-time Exchange admins, and that Exchange is just a tiny part of our day-to-day work.

Now I have to wait for someone to break this down into simpler terms to figure out if it affects my organization or not. So frigging annoying.

For what it's worth - here is our scenario. Maybe someone can chime in on whether or not I have to change things up.

We have an on-premise SMTP server, the one that comes with IIS. All of our internal equipment and servers send mail to that address. It's then sent along to Exchange Online with an account email address removed for privacy reasons. We set up the "send on behalf of" properties so that we get those emails like email address removed for privacy reasons and mailto:email address removed for privacy reasons.

So everything is sent as our domain name. So that means we're good? Again - Exchange is a tiny part of my day. I don't know everything about it to be sure about all this.
Carolyn_Liu
Microsoft
Jun 20, 2023
Faber,

The internal users will always be OK. For external users, if the SMTP envelop sender domain of the device is from your organization's domain, then the emails will be fine.
Faber
Copper Contributor
Jun 20, 2023
Hi All, sorry but I dont understand new scenario in my case.
I actually use relay to send mail mail that is described in the third case of this article to send mail from my devices or applications to internal and external users:
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365

It will continue to work after 1st november, or is only limited to internal mail users only and not external?
wroot
Silver Contributor
Jun 20, 2023
On my previous job we have setup internal SMTP server based on IIS, which used certificate based inbound connector on EO side. Then we would point all on prem systems to that SMTP to send emails through. Same with scanners which do not work with certs. SMTP would allow connections based on internal IP filter.
Carolyn_Liu
Microsoft
Jun 19, 2023
__trj

"It's not completely clear: Will we still be able to relay email through Exchange Online based on the IP address or will a certificate be required (assuming the P1 MAIL FROM requirement 1b is satisfied)?"

Yes, customers still can create Inbound connectors using IP addresses. They only need to use cert based connector when the scenarios apply to them, meaning when they need to relay emails where the envelop sender domain does not belong to their organization.

"We only use the SMTP relay from on-premises applications, scanners, etc. to internal users (email is not destined for recipients outside our tenant). Unfortunately, most of our applications and devices won't be able to support certificates, so we rely on using dedicated IP addresses to route this specific SMTP traffic through at our firewall"

You are OK in this case. Either envelope sender domain or recipient domain belongs to your organization, the relay will just work fine.
__trj
Brass Contributor
Jun 19, 2023
In item #2 of the "New Requirements" section, the requirements indicate that "the sending host's IP address or certificate domain on the SMTP connection matches your organization's Inbound Connector". However, in item #1 of the "Actions to Take" section, it says that if the Inbound Connector must be updated to use a certificate domain instead of IP addresses.

It's not completely clear: Will we still be able to relay email through Exchange Online based on the IP address or will a certificate be required (assuming the P1 MAIL FROM requirement 1b is satisfied)?

We only use the SMTP relay from on-premises applications, scanners, etc. to internal users (email is not destined for recipients outside our tenant). Unfortunately, most of our applications and devices won't be able to support certificates, so we rely on using dedicated IP addresses to route this specific SMTP traffic through at our firewall.