Exchange Online to Introduce Legacy SMTP Endpoint in 2022

Part of New Strategy to Move SMTP Connections to TLS 1.2

On August 18, Microsoft announced that they will disable Transport Layer Security (TLS) 1.0 and 1.1 connections to Exchange Online “in 2022.” SMTP clients will need to use TLS 1.2 to connect to Exchange and send email. This is the latest step in a journey which began in 2018 when Microsoft began advising customers to move away from TLS 1.0 and 1.1 on the basis that these versions of the protocol have known vulnerabilities. Effective October 31, 2018, Microsoft deprecated TLS 1.0 and 1.1 for Microsoft 365. Of course, deprecation doesn’t mean removal or stopping. It’s an intention that something will be removed in due course.

The Exchange Online team began to publish advice to customers to help them analyze TLS usage in their tenants in March 2019. At that point, June 2020 was the target date for disabling TLS 1.0 and 1.1 across Office 365. As it turned out, Exchange Online ceased support for TLS 1.0 and 1.1 in July 2020. The next step was the publication of MC229914 on 14 December 2020 where Microsoft announced they would gradually remove support for TLS 1.0 and 1.1 connections starting January 11, 2021, saying:

We’ll be gradually making the change and so initial impact could be messages getting delayed and only when the change is completed will messages fail to be delivered to their destinations.”

Alas, the best-laid plans of mice and men sometimes run into roadblocks. Microsoft could not proceed, possibly due to the combination of customer pushback and a global pandemic.

Microsoft’s New Plan to Encourage TLS 1.2

Although Exchange Online no longer supports TLS 1.0 and 1.1, some SMTP clients still use these versions to send email to Exchange Online mailboxes (Microsoft refers to “significant usage.” To overcome the problem of customers which haven’t been able to move away from TLS 1.0 and 1.1, Microsoft’s new plan is to:

  • Stop supporting TLS 1.0 and 1.1 connections for the regular smtp endpoint used to accept inbound email to Exchange Online (smtp.office365.com). This is what will happen sometime in 2022.
  • Allow tenants with good business reasons to continue to use obsolete TLS to accept the risk by configuring their tenant to accept these connections.

In other words, Microsoft is transferring responsibility to tenants to decide whether they want to risk accepting inbound email which might be a potential vector for attack. The risk is justifiable when organizations need some extra time to update applications (including email clients) and hardware devices which depend on TLS 1.0 or 1.1 to connect to Exchange Online to send email via SMTP.

Tenants that decide to take the risk must:

Set-TransportConfig -AllowLegacyTLSClients $True
  • Configure clients to use a new endpoint: smtp-legacy.office365.com.

I’m sure Microsoft is betting that most tenants will simply switch over to TLS 1.2. Those that need to keep using the older protocols can do so while they upgrade components (including PowerShell scripts). Overall, it seems like a plan that can work because organizations get to choose what they do.

Blocking Old TLS Connections Now

Tenants that want to switch early and block obsolete TLS connections can do so now by running Set-TransportConfig to update the setting to $False (it is $True by default until Microsoft switches off TLS 1.0 and 1.1. Before doing this, it’s a good idea to check the Inbound messages report in the Mail flow reports section of the new EAC (Figure 1). When I checked, I discovered that 2 of 700 messages delivered in the last week didn’t use TLS 1.2.

Inbound messages report in the Exchange Online admin center
Figure 1: Inbound messages report in the Exchange Online admin center

Given this level of traffic and that most inbound email to my tenant comes from other Office 365 tenants and well-known mail servers which use TLS 1.2, I am happy to force TLS 1.2. I therefore ran the command:

Set-TransportConfig -AllowLegacyTLSClients $False

The Sting in the Tail

Now that I’ve removed TLS 1.0 and 1.1 connectivity for my tenant, I won’t be affected by what Microsoft charmingly call a “new submission error speedbump,” planned for introduction in September 2021. When the speedbump is in place, Exchange Online will begin rejecting a small (unspecified) percentage of attempts to make SMTP connections using TLS 1.0 or 1.1 and issue this error message.

421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2. Visit https://aka.ms/smtp_auth_tls

This is a temporary error and clients can retry the connection. Given that Exchange Online will block only a small percentage of connections, it’s likely that the next attempt to connect will succeed. However, that small percentage of declined connections will increase over time to gradually make it more painful for clients using the older protocols to connect to Exchange Online. As Exchange Online declines more connections, clients will experience delays in transmitting email. In some cases, depending on the client’s error handling, email might not get through until someone updates the client to handle frequent retries (or even better, upgrade the client to TLS 1.2.

Eventually, Microsoft will pull the plug on TLS 1.0 and 1.1 for smtp.office365.com and it’s then up to the tenant to decide to continue with the old protocols or bite the bullet and transition to TLS 1.2. Should be a fun time ahead.


Learn about protecting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.

4 Replies to “Exchange Online to Introduce Legacy SMTP Endpoint in 2022”

  1. But what are these messages that are being sent without TLS or with 1.0 or 1.1? I can see in our tenant that we have 2 messages coming in from the internet without a connector and not using TLS at all. I’d like to see what these are but the new EAC reports aren’t interactive like the old ones were.

  2. Is it possible to block old TLS and then have an exception for a legacy system that doe snot support TLS1.2?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.