There’s a specific flavour of dread that comes from a server you forgot about. Not the one you patch on schedule — the quiet hybrid Exchange box that does nothing but relay mail and run the recipient management tools you never migrated off. It’s been humming along a couple of updates behind because it never caused trouble. This week, it starts causing trouble.
Microsoft is turning on graduated enforcement in Exchange Online against on-premises Exchange Server 2016 and 2019 systems that aren’t sitting on the final October 2025 security baseline. First it throttles the mail those servers send into the service. Then it blocks it. If you run a hybrid deployment, this is a mail-flow event, not a compliance nag. Let me walk the calendar, because the calendar is the whole story.
2016 and 2019: the servers that refused to die
Exchange 2016 shipped in 2015, 2019 in 2018. Both were meant to be waystations to the cloud. Instead they became permanent fixtures, because the moment you set up directory sync you discovered you can’t cleanly manage cloud mailbox attributes without a supported on-prem Exchange somewhere in the org. So the box stayed. Yours is probably a single server doing recipient management and hybrid transport, and it has been treated accordingly — which is to say, ignored.
That worked fine right up until Microsoft decided a decade-old server with unknown patch hygiene had no business injecting mail into a shared cloud platform.
October 2025 — the last update and end of the road
This is the beat that makes the rest make sense. October 2025 is where extended support for Exchange 2016 and 2019 ends. The security update that landed that month is the final one either product will ever get. There is no November fix, no 2026 cumulative update coming to save you. October 2025 is both the required baseline and the terminus.
So when Microsoft says “update to the October 2025 baseline,” read it plainly: get to the last patch that exists, because after this the only supported destination is a newer product or the cloud. The enforcement isn’t asking you to stay current. It’s asking you to reach the finish line before it locks the door behind you.
Note the scope, because people panic in the wrong direction. This hits on-premises Exchange 2016 and 2019 in hybrid. It does not touch Exchange 2013 in this wave, it does not touch Exchange Online-only tenants, and it does not touch your outbound path to the internet. If your org has no on-prem Exchange, close this tab and go enjoy your Monday. If you’re pure cloud but kept one legacy server “just for recipient management” — that server is exactly the target.
The enforcement model: report, then throttle, then block
Microsoft didn’t build a light switch. It built a dimmer that only turns one way. The mechanism runs in three stages against mail arriving over your hybrid connector from an unpatched server:
- Report — Exchange Online notes the outdated server and surfaces it to you, mail unaffected. The polite warning shot.
- Throttle — the service starts deferring messages from that server. Senders don’t bounce immediately; mail queues, retries, and arrives late. This is the stage that generates the confused help-desk tickets: “email is slow,” “did the invoice go through,” “why did that take an hour.” Nothing is broken enough to declare an outage, everything is broken enough to ruin your afternoon.
- Block — deferrals escalate into hard rejections. Mail from the unpatched server into Exchange Online stops. Now it’s an incident.
The design is deliberate and, honestly, kinder than it needed to be. Throttling gives you a window where the damage is annoyance rather than data loss, and it gives you a loud, unambiguous signal that you’re on the list. The trap is treating throttling as the problem instead of the warning. It’s the warning. Blocking is the problem, and it’s the same list, just later.
Second week of September 2026 — the dimmer starts turning
This is now. Throttling begins rolling out this week. If your hybrid server is behind, the first symptom you’ll see isn’t an error page — it’s inbound mail from on-prem taking longer than it should to land in cloud mailboxes, with retries in your on-prem transport queues. If you’ve got alerting on queue depth or message latency, watch it. If you don’t, your users are your monitoring, and they’ll tell you at the worst possible time.
I’ve been the person paged at 2 a.m. for “mail is delayed” only to spend an hour chasing connectors and DNS before someone mentions the Exchange box hasn’t been touched since a reorg two years ago. Don’t be my past self. Check the version first.
Right now — the one command that decides your week
This lives in the Exchange Management Shell on the on-prem server, not in the cloud. And no, you can’t do this bit through Microsoft Graph — Graph doesn’t manage on-prem Exchange, so anyone telling you to reach for it is guessing. The check itself is read-only, so run it without ceremony:
For anything beyond a single server, export it so you’re working from reviewed data instead of squinting at a console. This writes a file you can eyeball, sort, and hand to whoever signs off the change:
AdminDisplayVersion gives you a build number. Exchange 2016 reports as Version 15.1, Exchange 2019 as Version 15.2, each with a build that tells you which update you’re actually on. Compare that build against the published build for the October 2025 security update for your specific product — pull the exact number from Microsoft’s Exchange build numbers reference, and don’t trust a number you read in a blog post, including this one. I’m not quoting a build here on purpose; the whole point is that you verify against the source, not against my memory.
The fix, and the thing the fix doesn’t tell you
Remediation is unglamorous: apply the October 2025 update to every affected on-prem Exchange 2016 and 2019 server in the org, not just the one carrying hybrid transport today. Coexistence means mail can route through any of them, and enforcement judges each server on its own build. Miss one and you’ve left a slow leak in the boat.
Two things the announcement won’t put in bold for you. First, this is a real change window, not a hotfix you sneak in at lunch — Exchange updates want the right prerequisites, they can touch schema depending on the level you’re jumping from, and a botched CU on your only hybrid server is its own outage. Stage it, snapshot it, have a rollback. Second, October 2025 being the final update is the vendor quietly telling you the destination is somewhere else. Patching buys you continuity, not a future. If you’re patching a 2019 box this month, the migration to Exchange Server SE or full cloud should already be on a slide somewhere with a date on it.
Why Microsoft is actually doing this
The official framing is mail hygiene and trust: unpatched, out-of-support servers are a known attack surface, and Exchange Online doesn’t want mail injected by boxes carrying years of unfixed vulnerabilities. That’s genuinely true — the ProxyLogon-era wave of compromised on-prem Exchange servers was ugly, and a lot of them are still unpatched and still relaying.
The unofficial read is that Microsoft has spent years asking nicely for people to patch and migrate, and asking nicely stopped working. Throttling mail is what “we mean it” looks like when the polite emails get filtered to Deleted Items. Hard to be too mad about it. I’ve inherited enough forgotten Exchange servers to know that “nobody touches it and it just works” is exactly how the internet gets a new botnet node.
So: run the version check today, before throttling makes the decision for you. The next date on this calendar isn’t a webinar or a preview — it’s the day deferrals turn into rejections, and Microsoft has already shown it’s willing to move the dimmer. Your on-prem box has been ignored for years. Give it one more afternoon.
