Guide: How to verify your compliance with Microsoft's updated requirements for SMTP relay

Microsoft has recently implemented updates to the prerequisites governing SMTP relay usage within Exchange Online, which are scheduled to come into effect in November 2023. A comprehensive overview of the previous and current criteria has been detailed in the official blog post: Updated Requirements for SMTP Relay through Exchange Online - Microsoft Community Hub.

Over the past few weeks, Microsoft Support has noticed an increasing number of customer inquiries and concerns related to this topic. It has become evident that customers are facing challenges when it comes to evaluating the alignment of their SMTP relay configurations with the revised requirements.

To address these challenges, a workflow chart tailored for tenant administrators has been developed. This chart serves as a resource for confirming compliance with the specified conditions. Please refer to the workflow provided below and use it as a guiding tool to ensure that you are meeting all of the necessary criteria.

I have also included a section at the bottom with a few frequently asked questions (FAQs) that may prove helpful in navigating these updates.

1. What does the “SMTP certificate domain on the SMTP connection” refer to exactly?

• It refers to the certificate CN used in SMTP session by the remote email server. If the certificate CN is email.contoso.com, the TlsSenderCertificateName on the inbound connector of type OnPremises should match that value.
• However, it is still recommended to add email.contoso.com as an accepted domain in the tenant to avoid running into delivery issues with NDR, OOF, and other system messages where the P1 address is usually empty.

2. Can I configure the TlsSenderCertificateName with a wildcard (*.contoso.com) while the remote email server certificate CN is email.contoso.com?

• Yes, but it’s not recommended. This will match the remote email server certificate email.contoso.com and then the TlsSenderCertificateName (without any *., i.e. contoso.com) will have to be an accepted domain in the tenant to complete the attribution as Originating.
• There is a risk to configure the connector as such because you may have another certificate like email2.contoso.com which will also match the inbound connector. This configuration might cause intended mail flow issues, so this is only recommended if you want to match all certificates on the contoso.com second-level domain.

3. If the remote email server certificate CN is email.contoso.com, while that domain isn’t a part of my tenant’s accepted domains, will this still satisfy condition 1a?

• No. It’s required that you add email.contoso.com to satisfy this condition.

4. If I have an SMTP connection from on-premises to cloud and send emails with non-accepted domains, what happens?

• The email will not be relayed unless the SMTP certificate domain is also an accepted domain in the tenant.

5. If email.contoso.com is added as an accepted domain, will the new changes still affect my organization?

• In this scenario, the email will be allowed for relay.