Microsoft Is Ending Password SMTP in Exchange Online: What Senders Should Do Before the Deadline

Microsoft's retirement of Basic authentication for SMTP client submission is one of the quietest large changes in email infrastructure, and one of the most disruptive for anyone who relies on a username and password to send through Exchange Online. It was announced in April 2024, postponed twice, and re-scheduled in January 2026. For senders it raises a bigger question than a date: should business applications send through a mailbox at all? This analysis lays out what is confirmed, what depends on third-party reporting, and where the market is heading.

What is actually being retired

Exchange Online lets applications submit mail in several ways. This change affects one of them: SMTP AUTH client submission, where a device or program connects to smtp.office365.com on port 587, authenticates with a mailbox username and password, and hands over a message. Microsoft is removing the password option (Basic authentication) for that path, leaving OAuth 2.0 as the supported way to authenticate.

The kinds of senders affected are mundane, which is why the change is easy to miss:

• Multifunction printers and scanners that email scans.
• Line-of-business applications such as ERP, CRM and helpdesk tools.
• Scripts and scheduled jobs written in PowerShell, Python or shell.
• Monitoring systems, some network-attached storage and other appliances.
• Older software-as-a-service tools that never added OAuth support.

IP-based SMTP relay through an inbound connector on port 25 is a different path and is not part of this retirement, according to the reporting we reviewed.

The timeline, and why it keeps moving

The history matters because it shows how hard the change is for Microsoft's own customers. Using the CaptainDNS timeline, which summarises Microsoft's posts:

Two features of this schedule are worth noticing. First, "disabled by default" is a softer step than "removed", at least until the final date is announced. Second, two postponements in under a year suggest that the installed base of password-based senders is large and slow to move. Planning to the latest date is a gamble. Planning to the earliest plausible date costs little.

What failure looks like

When Basic authentication is refused, the sending application receives a permanent rejection. The error reported for this case is 550 5.7.30 Basic authentication is not supported for Client Submission. Because it is a 5xx response, well-behaved software will not retry, and the message is not delivered. Our guide to SMTP response codes explains why that distinction matters: a 4xx is a request to try again, while a 5xx is a final answer.

The practical risk is silence. A printer that fails to email a scan is noticed within a day. A monthly invoice script, a backup alert or a password-reset message from an old internal tool may fail without anyone seeing the error. Systems that send security or financial notices are the ones where that silence costs most.

The options Microsoft and the market offer

There are five realistic routes, each with trade-offs.

The pattern is that Microsoft's own routes either require code changes (OAuth, Graph, Azure) or are limited in scope (HVE). Anything that cannot be changed has to move to a relay.

Why sending business mail from a mailbox was always fragile

The retirement forces a question that deserves asking anyway. A mailbox is designed for a person: it has storage, a license, throttling rules and a sent-items folder. Using it as the sender for application mail brings a set of known problems.

1. Credentials in configuration. A mailbox password sits in a script, a config file or a device menu, often with broader rights than the task needs. Rotating it breaks sending until every place is updated.
2. Throttling and limits. Mailbox sending limits are designed for people. A burst of order confirmations or alerts can hit them.
3. Blurred reputation. Application mail and staff mail share one domain and often one infrastructure. A bad batch of automated mail can hurt the reputation of messages your staff send to customers.
4. Weak visibility. A mailbox gives you little in the way of delivery events, bounce handling or suppression management compared with a sending service.

None of this means every organisation must leave Exchange Online. It does mean that mail sent by systems rather than people is a separate workload with separate requirements, and the retirement date is a natural moment to separate it.

The wider trend: separating human mail from system mail

Mailbox providers' rules have pushed in the same direction for three years. Gmail, Yahoo and Microsoft's bulk-sender requirements ask for authenticated mail, low complaint rates and easy unsubscribe, and they judge the sending domain's behaviour as a whole. We traced that history in our analysis of bulk-sender rules in 2026. Once a domain's automated mail is held to a standard, it becomes sensible to isolate that mail on its own subdomain and its own sending identity, so that a problem in one stream does not drag down another.

Transactional mail has an additional claim to separation. A password reset or payment confirmation is time-sensitive and expected, so it should not queue behind a marketing send or share a throttle with a printer. Our comparison of dedicated and shared IPs covers one of the levers for that separation.

A migration plan that fits a quarter

The following plan is a suggestion, not a Microsoft procedure. Adjust it to the size of your estate.

1. Find every sender. Review sign-in logs for SMTP client submission and ask each team what sends mail. Include printers, monitoring tools, finance and HR systems, and old scripts. This step usually turns up senders nobody remembered.
2. Classify each one. For every sender, record whether it can use OAuth, whether it can call an API, or whether it can only speak SMTP with a password.
3. Move what can change. Update scripts and applications to Graph or an email API, or to OAuth where the library supports it. Test with a pilot recipient before cutting over.
4. Relay what cannot. Point password-only devices at an SMTP relay or sending service. Use credentials that are limited to sending, and keep them in a secrets store rather than a spreadsheet.
5. Authenticate the new path. Whatever you choose, make sure the sending domain or subdomain has aligned SPF, DKIM and DMARC. Our guide to authenticating a sending domain walks through the records, and the SMTP settings reference covers ports and TLS.
6. Watch the first weeks. Track bounces and rejections for each migrated sender, and keep the old route available until you have seen a full billing or reporting cycle.

Three scenarios to 2028

1. Slow squeeze. Microsoft keeps the admin override through 2027 and announces a final date late. Many organisations delay, and a long tail of printers and legacy tools keeps sending with passwords. Migration becomes urgent only when the final date lands. Probability: plausible, given two postponements so far.

2. Hard stop. The final removal arrives in 2027 or 2028 as announced, with no override. Organisations that did not inventory their senders discover failures through lost mail. Relay and sending-service providers see a wave of demand in the months before and after the date.

3. Early separation. A growing share of organisations treat the change as a reason to move system mail to dedicated sending infrastructure now, gaining delivery logs, suppression handling and domain separation. They are not affected by the final date at all. This is the scenario that costs least in total, though it takes the most deliberate effort up front.

What we do not know

We have not seen Microsoft publish how many tenants still use Basic authentication for SMTP, so the size of the problem is unmeasured. We also cannot say whether the final date will be enforced as announced, since earlier dates were not. Treat any firm claim about adoption rates, or about the date, with caution until Microsoft states them.

Bottom line

The end of password-based SMTP in Exchange Online is less a deadline than a prompt. Organisations that use it should inventory their senders now, move what can change, relay what cannot and authenticate the new path properly. The ones that treat application mail as its own stream, with its own domain, credentials and monitoring, will find the next change in mailbox rules much easier to absorb.

Sources

• Microsoft Exchange Team: Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline (January 2026)
• Microsoft Exchange Team: Exchange Online to retire Basic auth for Client Submission (SMTP AUTH)
• CaptainDNS: End of Basic Auth SMTP on Microsoft Exchange Online, timeline, 550 5.7.30 error and migration guide (source of the phase dates and option limits)