Microsoft is about to make an old Exchange server visible in the place its operator can least ignore: the mail queue.
Starting in the second week of September, Exchange Online will raise the minimum accepted build for Exchange Server 2016 and 2019 machines sending through an inbound connector of type OnPremises. The floor becomes the final public update released in October 2025. Servers below it enter Microsoft’s existing transport-enforcement process, where warnings become temporary SMTP failures and eventually permanent rejection.[1][2]
The immediate requirement is almost a year old, so this round looks generous. The next round changes the economics. Microsoft says the next minimum will be newer than any public update available for Exchange 2016 or 2019. At that point, continued delivery through the covered hybrid path requires either paid Extended Security Updates or migration to Exchange Server Subscription Edition.[1]
The recipient now judges the sender’s build
Email transport usually separates message acceptance from the sender’s product lifecycle. A receiving system evaluates addresses, authentication, reputation, content, volume, and protocol behavior. It does not normally require the sending organization to run a particular paid build of the receiver operator’s software.
Microsoft can make that judgment because hybrid Exchange identifies itself to Exchange Online over a tenant relationship and an OnPremises connector. The enforcement system reads Exchange version information from connection activity. It does not require Microsoft to log into the customer’s server.[2]
That turns a cloud service into a remote patch governor for adjacent on-premises infrastructure. The mechanism is blunt enough to create urgency and gradual enough to resemble an administrative process.
A newly detected server spends 30 days in report-only mode. The next 30 days bring progressively longer periods of SMTP 450 throttling, which tells the sender to queue the message and retry. After day 60, Exchange Online adds 550 rejection windows that generate non-delivery reports. At day 90, it refuses all messages from the noncompliant server until the server is remediated.[2]
The sequence matters. A dashboard warning can live unread for months. Five minutes of queued mail per hour leaks into support tickets. Rejection reaches employees, customers, and business partners. Microsoft designed the consequence to escape the infrastructure team and enter the organization’s visible operations.
A security control with a commercially specific sensor
Microsoft calls unsupported or heavily unpatched Exchange installations “persistently vulnerable.” The risk is real. Internet-facing Exchange servers have been lucrative targets, and patches can reveal enough about a fixed flaw to accelerate exploitation against lagging systems. A cloud operator also has a legitimate interest in limiting dangerous traffic entering its service.[2]
The enforcement sensor is narrower than that security claim. Microsoft’s FAQ says the system checks the Exchange Server version. It does not check whether the underlying Windows installation is current. It does not attest configuration, endpoint protection, exposed services, compensating controls, or evidence of compromise.[2]
A server with the approved Exchange build and a neglected operating system can pass. A server below the build floor can fail even when its operator has isolated it, restricted its role, or applied other controls. Version is measurable at the connection boundary, which makes it governable. Measurability and security are related here, but they are not identical.
The scope is also easy to overstate. September’s change covers Exchange 2016 and 2019 servers that send through an inbound OnPremises connector. Microsoft says other connector types and other delivery methods are unaffected for now. The company also says the system does not currently cover every server in an organization and may expand later.[1]
That boundary creates an obvious escape route: change the route. An organization may relay through another mail transfer agent or redesign the connector path. Such workarounds remove Microsoft’s build check from that specific connection, but they can also erase hybrid assumptions, complicate support, and move responsibility into another system. A policy tied to one leg of the transport graph invites architecture changes around the checkpoint.
The pause is metered exception handling
Each affected tenant gets up to 90 days of enforcement pause per calendar year. Administrators can request it in the Exchange Admin Center or with New-TenantExemptionInfo. The pause puts servers back into report-only mode.[3]
The details reveal how Microsoft thinks about exceptions. Pause days behave like a prepaid balance. An administrator who requests 30 days and finishes the upgrade after five still burns all 30. The unused days cannot be refunded. This makes emergency continuity available while discouraging routine dependence on the exemption.[3]
It also moves part of the on-premises change calendar into Microsoft’s cloud control plane. Maintenance delays, failed upgrades, application dependencies, procurement, and internal approvals now consume a remote allowance when they collide with the transport baseline. The local server remains physically under customer control while its practical ability to participate in the hybrid mail system depends on a cloud-side counter.
Hybrid ownership has acquired an admission gate
The familiar sales pitch for hybrid infrastructure is continuity of control. Organizations keep local systems for applications, data location, staged migration, or internal dependencies while using cloud services around them. Microsoft’s enforcement model exposes the asymmetry inside that arrangement.
The customer owns the server, schedules the maintenance window, carries the migration risk, and handles any broken application. Microsoft operates the destination used by a vast share of the customer’s correspondents and can condition that destination on a build policy. Both parties hold a piece of the same mail path, but the recipient-side operator has the final packet-level veto.
The September threshold is defensible on security grounds. Running a mail server below a year-old final public update is reckless. The durable development lies in the mechanism and where it leads. Microsoft has built a graduated remote-enforcement system, expanded it across Exchange versions, and announced that its next floor will cross from publicly patchable software into a paid or migrated state.[1][4]
That creates a clean lifecycle machine. Product support defines acceptable builds. Connection telemetry identifies laggards. The admin center reports them. SMTP delays create pressure. Rejection imposes the deadline. A limited pause absorbs exceptions. Subscription or paid extended support restores admission.
A patch policy used to end at the machine. Microsoft’s now reaches the recipient.
Sources
[1] https://techcommunity.microsoft.com/blog/exchange/exchange-20162019-throttling-and-blocking-up-to-the-final-public-update-baseline/4552717 | Microsoft Exchange Team, September 2026 baseline announcement [2] https://techcommunity.microsoft.com/blog/exchange/throttling-and-blocking-email-from-persistently-vulnerable-exchange-servers-to-e/3815328 | Microsoft Exchange Team, transport-enforcement system [3] https://techcommunity.microsoft.com/blog/exchange/how-to-pause-throttling-and-blocking-of-out-of-date-on-premises-exchange-servers/4007169 | Microsoft Exchange Team, enforcement-pause mechanics [4] https://www.theregister.com/on-prem/2026/09/04/microsoft-to-bounce-mail-from-outdated-exchange-servers/5294506 | The Register, September 4 report