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:
- SMTP certificate domain on the SMTP connection; or
- SMTP envelope sender domain in the MAIL FROM command (P1 sender domain); or
- 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:
- SMTP certificate domain on the SMTP connection; or
- 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 3rd 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
