Exchange turns off basic SMTP in December and its own alternative keeps it until 2028

550 5.7.30 Basic authentication is not supported for Client Submission. That is the line Microsoft publishes as the response for when basic is switched off for good. If December's switch-off arrives through the tenant SMTP AUTH toggle, what you will see is the familiar 535 5.7.139. Microsoft has not said which of the two you get, and in practice it does not matter: the important part is not the date, nor the number behind it. It is the five at the front.

In SMTP, a 4xx means "not now, come back later": the message sits in a queue and gets retried. A 5xx means "no, and stop asking". The standard says the client should not repeat, so on most devices the mail stops existing the same second they try to send it. And none of them has anybody to complain to, because the rejection happens at authentication, before there is a message to bounce: no non-delivery report is generated, nothing bounces, no warning reaches anyone.

Everything below comes from two Exchange team announcements and four pages of their documentation. Read separately, each one is clear enough. Read together, one of them tells you that you will not be able to switch it back on, and another tells you that you will.

The date has already moved three times

Microsoft writes the reason for the latest delay without hedging, and it deserves credit for being honest about it: "We understand that many customers continue to face real challenges modernizing legacy email workflows and need sufficient time to adopt viable, secure alternatives." Translated: too many people still cannot.

Our reading, and we flag it as a reading: planning against the date means planning against the only thing that has moved. What has not moved across two years of delays is the error code, and what triggers it.

"You will not be able to turn it back on" and "you will"

The original announcement is still published, with its update notice at the top pointing to the new timeline, and its FAQ section intact. One of those questions is exactly the one you will ask in January: "Wait! I still need to use Basic auth; how can I get it re-enabled in my tenant once it gets disabled?" And the answer is: "You will not be able to do this because Basic auth will be permanently disabled. Don't waste your time engaging Support, as they cannot re-enable Basic auth for you." The next one doubles down: "We cannot offer any exceptions."

This is not a contradiction worth denouncing: one sentence describes December and the other describes the end state. But the order in which you read them changes what you do. Read only the December one and January's task is "turn it back on and close the ticket". Read both and January's task is a different task.

There is a precedent, and it sits in the official documentation rather than a forum. The other protocols (ActiveSync, POP, IMAP, EWS, remote PowerShell, the offline address book, Autodiscover) went through this in 2022, and the page that records it puts it like this: "Before December 31, 2022, you could re-enable the affected protocols if users and apps in your tenant couldn't connect. Now no one (you or Microsoft support) can re-enable Basic authentication in your tenant." The re-enable switch existed for exactly one window, and then it was gone. That is what we wrote when it was EWS's turn, when the next one on the list came up.

Who is sitting on port 587

You do not have to guess, because Microsoft lists it on its own SMTP AUTH page: "Applications, reporting servers, and multifunction devices that generate and send email messages", plus POP and IMAP clients, which need authenticated SMTP in order to send at all. The protocol lives "typically on TCP port 587" and the affected endpoints are smtp.office365.com and smtp-legacy.office365.com.

That list, translated into a real office, is the machine on the second floor that scans to email, the ERP that sends the invoices, the reporting server that mails the Monday summary, the alarm system, the time-and-attendance platform and that script somebody left in a scheduled task. Almost none of them has a human in front of it when it fails. And this is where the 5xx gets interesting: the printer lights a red indicator nobody looks at, the ERP writes a line to a log nobody reads, and the invoice you thought went out did not go out. The normal outcome is not finding out that afternoon. The normal outcome is finding out when the customer calls in February asking why nothing ever arrived.

That is why the useful question for every sender on your list is not "can it do OAuth?". It is "what does this do when the submission is permanently refused, and where does that show up?". In most places that question has never been asked, because until now the mail always went out.

The official escape hatch still accepts a password

For the devices that cannot do OAuth, Microsoft points at High Volume Email as the destination. And on the same page where it announces it, it writes this: "continued support for Basic Authentication until September 2028", with the explicit reason that "certain line-of-business (LOB) applications and devices may not support modern authentication yet".

In other words: the official answer to "my printer only knows a username and a password" is a service that keeps accepting a username and a password for twenty-one more months. There is nothing scandalous in that, it is pragmatism, but it is worth calling it by its name before you build on it: this is not modernising anything, it is moving the problem somewhere else with a new date attached. And there is genuine small print.

The row that matters is the third one, and Microsoft justifies it like this: "HVE will support exclusively internal (within the tenant) messaging capabilities. As a result, the ability to send email to external recipients will be removed." For sending outside, it points you at Azure Communication Services. So the invoice your ERP sends to a customer does not fit in there. Neither does the delivery notice to a supplier, nor the acknowledgement from your website form.

Five ways out, and the recipient decides which

Look at the whole table and you see what no headline says: the deciding column is not authentication, it is the recipient. Before you can pick a way out you have to classify each sender by where it sends — inside only, outside only, or both — and that classification is written down nowhere. A multifunction unit that scans to colleagues and to customers sits in two rows at once. And it is worth not skipping the fourth way out just because it is unglamorous: for that machine on the second floor, in an office with a fixed IP, an inbound connector is usually cheaper and faster than opening an Azure subscription, and it removes the password rather than relocating it.

Three switches, and they do not reach the same places

Microsoft says "disabled by default", and in Exchange Online "by default" has a very specific technical meaning. There are three documented mechanisms that can say no to a username and password over SMTP, and they do not reach the same mailboxes. Which of them December arrives through has not been published by anyone yet, and you do not have to deduce it: the message centre post itself closes the section saying "We will provide detailed information in a follow up Message Center Post". So the detail is still pending, and what follows is a check you can run today, not a claim about how they will implement it.

The last two rows allow hand-placed exceptions, mailbox by mailbox or user by user. And in most tenants those exceptions exist: they were put in during the 2022 cleanup so the printer would keep working, and whoever put them there may no longer work for you. That is the list worth having in front of you before December arrives, however it ends up being implemented.

There is also a report that does half the work and has been there since October 2024: in the Exchange admin centre, the SMTP AUTH client submission report has distinguished since then whether each sender authenticates with basic or with OAuth. It does not tell you where each one sends — that column is yours to add — but it gives you the names.

What we would do in November

Nothing heroic, and it fits in a morning. Pull the report and keep the senders using basic. Cross it with the mailboxes carrying a hand-placed exception, because one almost always turns up that nobody uses any more and has had a permanent password on it for four years. Add two columns to each row that no inventory ever carries: where it sends — inside only, outside only, both — and where the error would show up if tomorrow it got told no.

With that table in front of you the decisions make themselves, and half of them are decisions to switch something off: what moves to OAuth, what moves to a connector, what gets retired because it spent two years mailing an empty distribution list, and what waits with a date of its own written down. The good part is that the table does not expire when Microsoft moves the date again, and they will. Tenant policy, which mailbox each device uses and what you see when something is refused is Microsoft 365 governance; which ERP integration sends that mail, whether it can speak OAuth and what it costs to make it is data and applications territory. If you want us to look at it with you, there is the contact form.

No alarm will go off at the end of December. A 5xx does not make a sound: it is a very clean silence, and clean silences are the expensive ones. The difference between the team this costs a morning and the team it costs a customer complaint in February is not how fast they react in January. It is whether somebody sat down in November and wrote the list.

Sources. Consulted on 3 November 2026. The current timeline and its milestones, quoted verbatim, come from "Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline", by the Microsoft 365 Messaging Team, published 27 January 2026 and still the latest as of today. The previous timeline (1 March and 30 April 2026, and before that September 2025), the 550 5.7.30 code and its condition "once Basic auth is permanently disabled", the two endpoints, the alternatives and the two FAQ answers about turning it back on come from the original announcement, "Exchange Online to retire Basic auth for Client Submission (SMTP AUTH)", which is still published with its update note. The June 2025 pause ("has been put on hold") and the line about the pending detail ("We will provide detailed information in a follow up Message Center Post") come from message centre post MC786329, which also records the authentication protocol column added to the report in October 2024. The 2022 precedent, the line about nobody being able to re-enable it and the protocols affected then come from "Deprecation of Basic authentication in Exchange Online". The list of who uses SMTP AUTH, port 587, the organisation and per-mailbox settings, the mailbox precedence and the security defaults note come from "Enable or disable SMTP AUTH in Exchange Online". The AllowBasicAuthSmtp switch and the precedence of assigned policies over the default policy come from "Disable Basic authentication in Exchange Online". SMTP relay with an inbound connector, its certificate or static IP authentication, port 25 and the sentence about when it applies come from "How to set up a multifunction device or application to send email". Continued basic auth support until September 2028, the move to internal-only recipients and the limits table come from "High Volume Email: Continued support for Basic Authentication"; general availability, billing starting 1 June 2026, the $42 per million recipients and the warning about delivery interruption if billing is not configured come from MC1243552. The 535 5.7.139 is the documented error when SMTP AUTH is disabled for the tenant or the mailbox, and we cite it as the other possibility precisely because December's mechanism has not been published. Quotes are left in their original English so they can be searched verbatim. The social image photograph is "Konica Minolta Bizhub C454e photocopier", by Baron Maddock, CC BY 4.0 via Wikimedia Commons.