Exchange Online now throttles and blocks mail from 2016 and 2019 servers older than the October 2025 update. Microsoft has already said the next raise will sit above the last publicly available build — which turns a patching task into a decision about money and migration.
Since the second week of September 2026, Exchange Online has been throttling and then blocking mail from Exchange Server 2016 and 2019 servers that are older than the October 2025 public update. Microsoft announced the change on 2 September, after years of adjusting the oldest acceptable version quietly. The enforcement applies to servers connecting to Exchange Online over an inbound connector of type OnPremises; it does not apply to other connector types, and Microsoft notes it does not currently apply to every server in an organisation.
The sentence worth reading twice is not the deadline. It is the one about the next one. When Microsoft raises the oldest allowed version again — the company estimated in several months — the required build will be newer than any publicly available update. At that point, only organisations enrolled in the Extended Security Update programme, or those who have moved to the current version of Exchange Server, will have a build that is allowed to send at all.
The next time we update the oldest allowed Exchange Server version for sending email to Exchange Online, the required version of Exchange Server 2016 or Exchange Server 2019 will be newer than any publicly available update.
Microsoft Exchange Team, 2 September 2026Throttling is the worst shape a deliverability problem can take, because it is not a rejection you can count. Mail is accepted slowly, queued, retried, and sometimes dropped. The sending application reports success, the receiving side never shows the message, and the first real signal is a support ticket about a password reset that never arrived.
Nothing in a campaign report will show it as a change in performance, either, because the affected mail is usually not campaign mail. It is the mail nobody charts: receipts, confirmations, notifications, and whatever the internal billing system sends from a server in a rack.
Triggered mail is the stream that runs through relays nobody owns. Those relays are exactly what this enforcement is aimed at — and triggered mail is exactly the stream a lifecycle programme has the least visibility into. The campaign dashboard looks fine while the transaction mail rots, and the customer experience degrades in a place that does not appear on the weekly report.
There is a second-order effect worth planning for. The infrastructure that carries your transactional mail is on a clock set by a vendor's security policy, not by your roadmap. A program that only notices infrastructure when it stops working has effectively outsourced the reliability of its most important messages to somebody who will find out from a ticket.
Report triggered mail separately from campaign mail, with its own volume and failure numbers. Infrastructure enforcement never shows up as a campaign decline. It shows up as a quiet drop in a stream nobody was charting, three weeks after people started complaining about it.
Written by the team at LMR — a senior lifecycle marketing studio working in Iterable, Braze, Klaviyo and the tools you already run.
Start a project ↗