Updated requirements for SMTP Relay through Exchange Online

  • Article

This article explains how you can update your requirements for SMTP relay through Exchange Online. If your organization doesn't use Inbound connector of OnPremises type, then this change doesn't affect you.

Current requirements

To relay email through Exchange Online, the following must be true:

  1. Any of the following is an accepted domain of your organization, if:

    1. SMTP certificate domain on the SMTP connection; or
    2. SMTP envelope sender domain is in the MAIL FROM command (P1 sender domain); or
    3. SMTP header sender domain, as shown in email clients (P2 sender domain).

  2. 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, the matching condition for the SMTP P2 sender domain is removed. The following are the new requirements for relaying email through Exchange Online:

  1. Any of the following is an accepted domain of your organization, if:

    1. SMTP certificate domain on the SMTP connection; or
    2. SMTP envelope sender domain in the MAIL FROM command (P1 sender domain).

  2. The sending host's IP address or certificate domain on the SMTP connection matches your organization's Inbound connector of OnPremises type.

If either of the above conditions aren't met, the relay attempt from your on-premises environment to Exchange Online will be rejected.

This change might affect your organization's email routing or delivery. Possible scenarios that are affected by this change include, but aren't limited to:

  1. Your organization hosts email on-premises, and you need to relay nondelivery 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 domain.

  2. Your organization uses an application hosted on-premises to send email, and the SMTP envelope sender domain (P1 sender domain) isn't an accepted domain in Exchange Online.

  3. 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) is the third party service's domain (perhaps for bounce tracking), but the SMTP header domain (P2 sender domain) is your organization's domain.

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 generates an extended report specific to this scenario. The following are some examples and replace the value of NotifyAddress in the examples with your admin email address to generate a report.

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

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

Note

The SenderAddress must be an accepted domain of your organization.

Example 2:

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

Note

The 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.

Use Get-HistoricalSearch -JobId xxxx, where the xxxx is the Job ID.

If the job result (ReportStatusDescription) is "Complete – No results found", that means your organization isn't impacted by the scenario.

Minimize the effects of this change

  1. If you need to relay emails from on-premises through Exchange Online, and some of these emails apply to the scenarios indicated above, 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. For more information, see Configure a certificate-based connector to relay email messages through Microsoft 365.

  2. 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 must be an accepted domain of your organization. An example is that your organization uses a signature service to add signature/disclaimer for each email sent from your organization. For example, your organization uses a third-party CRM cloud service to send emails on behalf of your organization to mailboxes of your company or other external users. For more information, see Scenario: Integrate Exchange Online with an email add-on service.