Exchange Online throttles and blocks outdated Exchange 2016 and 2019 servers starting in September 2026: How transport enforcement works

On September 2, 2026, the Exchange team announced an increase to the minimum version for Exchange 2016 and Exchange 2019 in hybrid mail flow. Starting in the second week of September 2026, Exchange Online will require servers that submit mail through an inbound connector of type OnPremises to be at least at the level of the last public security update from October 2025. Anything below that will be throttled and later blocked. In short: If you have not patched your hybrid servers since October 2025, you will gradually lose mail delivery to Exchange Online in the coming weeks. And the next increase, which Microsoft has indicated for the coming months, will be above every publicly available update: Then, only customers in the paid ESU program or environments with Exchange Server Subscription Edition (SE) will meet the requirement.

The announcement itself is brief. Its practical implications result from the enforcement system Microsoft has built up incrementally since 2023: which SMTP responses your server will receive, how to check the status in the Admin Center and through PowerShell, and which options remain during the transition until the ESU program ends in October 2026.

What applies starting in the second week of September 2026

The new baseline corresponds to the security updates of October 14, 2025. That was the last Patch Tuesday on which Microsoft publicly provided updates for Exchange 2016 and 2019; all SUs since December 2025 have only been available through the ESU program.

An October 2025 SU also exists for Exchange 2019 CU14 (KB5066368, build 15.2.1544.36). However, the Microsoft post explicitly names CU15 SU5 as the minimum version; CU14 has no longer been a recommended version since CU15 was released in February 2025. Include the move to CU15 in your plans if you are on CU14.

Three limitations are important:

• Only hybrid mail flow is affected. Exchange Online checks the version of submitting servers for messages that arrive through an inbound connector of type OnPremises. This is the classic hybrid configuration created by the Hybrid Configuration Wizard. Mail arriving through a third-party gateway or a connector of type Partner does not go through this enforcement.
• The version is read from message headers. An Exchange server writes its build to the Received line of every message it relays (… with Microsoft SMTP Server … id 15.1.2507.61). Exchange Online evaluates this information. Therefore, the relevant version is that of the server that actually hands the message over to Exchange Online—meaning, in many environments, the Edge Transport Server or the Mailbox server with the Send Connector to *.mail.protection.outlook.com.
• Exchange SE is not affected. The enforcement applies to Exchange 2016 and 2019; Exchange Server SE is above every baseline as long as it is patched regularly.

Background: transport enforcement since 2023

The September announcement is not a new measure, but the next stage of a system Microsoft introduced in March 2023 under the title “Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online.” Microsoft defines “persistently vulnerable” as any Exchange server that has either reached end of support or remains unpatched for known vulnerabilities. The goal is to protect Exchange Online recipients from messages originating from compromisable servers while also pressuring operators to patch or shut down those servers.

The system was enabled by version:

For Exchange 2016 and 2019, the baseline had previously been versions that were “significantly behind on security updates.” What is new is that Microsoft is setting the limit at the last public update, thereby affecting for the first time servers that were still fully patched less than a year ago.

The escalation stages

The enforcement operates in three functions Microsoft calls “reporting,” “throttling,” and “blocking.” As soon as a server falls below the baseline, a 90-day cycle begins. The stages from the 2023 overview post are:

The two responses read as follows:

450 4.7.230 Connecting Exchange server version is out-of-date;
connection to Exchange Online throttled for n mins/hr.

550 5.7.230 Connecting Exchange server version is out-of-date;
connection to Exchange Online blocked for n mins/hr.

The difference is critical operationally. With 450, Exchange Online temporarily rejects the connection; the on-premises server retains the message in its queue and tries again. At first, users notice only delays. In Queue Viewer or in Get-Queue, the queue for the Send Connector to Exchange Online grows with the status Retry and the 4.7.230 message as LastError. With 550, the rejection is final: the sender receives an NDR with code 5.7.230, and the message is lost unless it is sent again. Because blocking is initially active only for a few minutes per hour, the issue initially appears sporadic: some messages arrive, while others fail with an NDR. If you see this pattern in message tracking, check the version status first before looking for network or certificate issues.

The announcement does not say whether Microsoft will start the full 90-day cycle for the new baseline in the second week of September or begin at a later stage. The overview post states that, after a pause, the system continues at the stage previously reached. Do not rely on a 30-day grace period.

Report in the Exchange Admin Center and through PowerShell

Exchange Online lists detected on-premises servers and their versions in a dedicated report: in the Exchange Admin Center under Reports, Mail flow, the report for out-of-date connecting on-premises Exchange servers. For each server, the report shows the detected build, whether it is below the baseline, and which enforcement stage applies.

Exchange Online PowerShell provides the same information:

Connect-ExchangeOnline
Get-OnPremServerReportInfo

The report only knows servers that actually hand off mail to Exchange Online. A management server without mail flow or a machine with only management tools does not appear in it. That is irrelevant to enforcement, but not to security: These systems also need the SUs.

Pausing enforcement: 90 days per year

For environments that cannot meet the baseline in the short term, Microsoft offers a pause. It can be activated for a total of 90 days per year, either continuously or in multiple periods:

Get-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer

New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer `
  -NumberOfDays 30

Two properties of the pause are important in practice. First, when it expires, enforcement continues at the stage at which it was paused; the pause does not reset the 90-day cycle. Second, there is no cmdlet to end an active pause early: If you create a 90-day pause and finish patching after two weeks, you have used up the annual allowance. Therefore, make the pause as short as possible and extend it if necessary.

The pause is also only a solution for the current baseline. If Microsoft raises the limit above the last public update in a few months, an exhausted allowance will no longer help.

Why the next increase is the real deadline

Exchange 2016 and 2019 have been out of support since October 14, 2025. Microsoft then introduced two paid ESU periods: Period 1 through April 2026 and Period 2 from May through October 2026. With the announcement of Period 2 on April 15, 2026, the Exchange team clarified that there will be no further extension. The SUs from December 2025 through August 2026 (most recently build 15.2.1748.49 for 2019 CU15 and 15.1.2507.72 for 2016 CU23) are available exclusively to ESU customers and are not offered for public download.

This results in the following situation:

• Today, a server with the October 2025 SU meets the baseline, with or without ESU.
• With the next increase, Microsoft says the baseline will be above the October 2025 level. Without an ESU contract, there is no legal way to reach that level. Hybrid mail flow from these servers will then be throttled and blocked, regardless of how well the rest of the environment is operated.
• On October 31, 2026, Period 2 also ends. After that, there will be no more SUs for Exchange 2016 and 2019, for anyone. At the latest, the increase after next will therefore also affect ESU customers.

At best, the ESU program buys only a few months. The only permanent version that enforcement allows is Exchange Server SE. Microsoft has also announced that Exchange SE CU2 (planned for the second half of 2026) will end coexistence with Exchange 2016 and 2019: installation will stop if older servers are found in the organization. Therefore, migration is due not only because of mail flow, but also to enable continued installation of updates for SE at all.

For environments that retain Exchange On-Premises only to manage attributes in a hybrid configuration, the alternative is to remove the last server: Since Exchange 2019 CU12, recipient attributes can be managed using the management tools without a running Exchange server. There is then no on-premises mail flow, and enforcement becomes irrelevant.

Determining the version level

Get-ExchangeServer displays only the CU, not the SU, in AdminDisplayVersion. The file version of ExSetup.exe or the Exchange Health Checker is reliable; it also reports missing manual steps. For a quick overview of all servers:

Get-ExchangeServer | ForEach-Object {
  $path = "\\$($_.Name)\C$\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe"
  [pscustomobject]@{
    Server  = $_.Name
    Version = (Get-Item $path).VersionInfo.ProductVersion
  }
}

If the version is below 15.2.1748.39 (2019 CU15) or 15.1.2507.61 (2016 CU23), the server will fall below the baseline starting in the second week of September.

Recommended approach

1. Inventory the version levels as described above, including Edge Transport Servers and management servers.

2. Check the report in Exchange Online. Get-OnPremServerReportInfo shows which servers Exchange Online actually sees and whether an enforcement stage is already active. Compare the list with the inventory: Servers missing from it do not submit through the OnPremises connector.

3. Install at least the October 2025 SU. KB5066367 (2019 CU15) and KB5066369 (2016 CU23) are still publicly available from the Microsoft Download Center. SUs are cumulative; a server at the August 2025 level can be updated directly to October 2025. For CU14, install CU15 first. After installation, restart, check service status, and run the Health Checker again.

4. Use the pause only as a bridge. If the update cannot be completed in the first half of September, create New-TenantExemptionInfo with a short duration and do not treat the pause as planning reserve for the next increase.

5. Schedule the migration to Exchange SE. Without an ESU contract, the next increase is the hard deadline; with ESU, it is October 31, 2026. Exchange 2019 CU15 can be upgraded in place to SE; Exchange 2016 requires the detour of a fresh SE installation and mailbox or role moves. If you operate Exchange only for attribute management, remove the last server and continue using the management tools.