SMTP AUTH Basic Authentication Retirement in Exchange Online: Find Every Scanner and App Before the Switch-Off

The short version: Microsoft's current timeline, published by the Exchange Team on 27 January 2026 and last revised on 29 January 2026 (version 3.0), is that SMTP AUTH Basic authentication keeps working until December 2026, is disabled by default for existing tenants at the end of December 2026 (administrators can turn it back on), and will be removed for good on a date Microsoft says it will announce in the second half of 2027. Use the next eight weeks to list every printer, scanner and application that still sends mail with a username and password, and move each one to OAuth, a connector-based relay or another sending route.

The SMTP AUTH Basic authentication retirement is one of those changes that nobody notices until the morning the multifunction printer stops scanning to email. Exchange Online stopped accepting Basic authentication for Outlook, ActiveSync, POP, IMAP and remote PowerShell back in 2022 and 2023. SMTP AUTH client submission, the protocol that scanners, line-of-business applications and older websites use to send mail through smtp.office365.com, was left for last because so much office equipment depends on it.

This article is the practical version: what Microsoft has actually announced as of 31 October 2026, how to find every device and application in your tenant that still sends with Basic authentication, and how to choose a replacement for each. It is written for the person who will be asked "why did the scanner stop working?" in January.

What exactly is being retired, and when?

The Exchange Team published the current schedule in a post titled "Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline" on 27 January 2026; the post's own version history shows a revision on 29 January 2026 (version 3.0), which is the version this article follows. That post replaced the April 2024 announcement (Message Center item MC786329), which had planned to start rejecting Basic authentication on 1 March 2026 and reach full rejection by 30 April 2026. Those two dates no longer apply. If a vendor, a forum thread or an older article quotes them, it is working from the superseded plan.

As of 31 October 2026, the January 2026 post (as revised on 29 January 2026) is the latest schedule we could find on Microsoft's own channels. It sets out three stages:

• Now until December 2026. Nothing changes. SMTP AUTH with Basic authentication behaves as it does today, wherever it is enabled.
• End of December 2026. Basic authentication for SMTP AUTH is disabled by default in existing tenants. An administrator can still enable it if a device genuinely cannot be moved in time. For new tenants created after December 2026, Basic authentication is unavailable by default and OAuth is the supported method.
• Final removal. Microsoft has not set a date. The Exchange Team post says the final removal date will be announced in the second half of 2027; the matching Message Center item (MC786329) says only "in 2027".

Two points are worth being precise about, because they cause most of the confusion.

First, Microsoft is not turning off SMTP. It is turning off Basic authentication for SMTP AUTH client submission. A device that signs in to smtp.office365.com with an OAuth 2.0 token keeps working. So does mail sent through a connector or by Direct Send, because those routes do not sign in with a mailbox password at all.

Second, "disabled by default, but you can re-enable it" is a grace period, not a solution. A tenant that flips the setting back on in January has bought time until a date Microsoft has not announced yet, and will have to do this work anyway. Check the Exchange Team blog again before you plan around any date in this article; Microsoft has moved this one once already.

Why should you care if your scanners work today?

Because the failure is silent until it is not. A scanner that cannot authenticate does not raise a ticket. Staff press "scan to email", nothing arrives, and after a few days someone mentions it. If the same tenant also has a finance application that sends remittance advice, a website contact form or a monitoring tool that emails alerts, those stop too, and some of them are not obvious.

There is also a security reason to do this regardless of Microsoft's dates. Basic authentication means a mailbox password stored in a device's settings page or an application's configuration file, often a shared "scanner@" account whose password never changes and is excluded from multi-factor authentication because the device cannot answer a prompt. That account is a standing exception in your Conditional Access design. Our Conditional Access baseline policies guide explains why blocking legacy authentication is one of the first policies a small tenant should have, and every SMTP AUTH sender is a reason somebody gave for not turning it on.

How do you find every device and app still using SMTP AUTH Basic?

Do this from three directions, because each one catches things the others miss.

Start with the SMTP AUTH clients report

The Exchange admin center has a report built for exactly this. In the new Exchange admin center, go to Reports, then Mail flow, and open the SMTP AUTH clients report. It lists the sender addresses that submitted mail over SMTP AUTH, the domain, the authentication protocol used (Basic or modern), the share of traffic on each TLS version, and the message count. It covers the last seven days by default, so widen the date range: a device that only scans at month-end will not appear in a seven-day window.

Microsoft documents the report under "SMTP AUTH clients report in the new EAC in Exchange Online". Viewing it needs one of the Exchange or security reader roles listed there; a Security Reader can run it without any write access to the tenant.

Then find out where the mail is coming from

The report tells you which mailbox sent mail, not which box on which desk. For that, open the Microsoft Entra admin center, go to sign-in logs, and filter the client app to "Authenticated SMTP". Each entry shows the account, the time and the source IP address. An office IP points to a device on site; an IP in a cloud provider's range usually means a hosted application or a website; an IP you do not recognise is worth a closer look, because SMTP AUTH is also a route attackers use to send mail from stolen credentials.

Group the results into a simple register with one row per sender: the account, what the device or application is, who owns it, where it sits, how often it sends, and whether it sends to internal or external recipients. That last column decides which replacement is available.

Finally, check which mailboxes are allowed to use SMTP AUTH at all

In Exchange Online PowerShell, Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled shows the organisation-wide setting. Get-CASMailbox -ResultSize Unlimited | Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } lists the mailboxes on which SMTP AUTH has been explicitly enabled. Microsoft's article "Enable or disable SMTP AUTH in Exchange Online" explains the precedence: a per-mailbox value of true or false overrides the organisation setting, and a blank value means the mailbox follows it.

Compare that list with your register. A mailbox that is enabled but sent nothing in the last month is an exception that should simply be removed. A mailbox that sent mail but is not on any list of known devices is the one to investigate first.

What are the replacement options, and how do you choose?

Microsoft's own troubleshooting article for printers, scanners and line-of-business applications describes the main routes. Which one fits depends on what the device can do and where its mail needs to go.

SMTP AUTH with OAuth, connector relay or Direct Send?

• SMTP AUTH with OAuth 2.0. The device or application keeps sending to smtp.office365.com on port 587 but signs in with a token instead of a password. This is the cleanest fix and the one Microsoft points new tenants to. Its limit is the device: many scanners from before about 2020 have no OAuth option, and some only gain it through a firmware update. Check the manufacturer's current firmware notes before assuming either way.
• SMTP relay through a connector. You create an inbound connector in Exchange Online that accepts mail from your office's static public IP address or from a certificate, and the device sends to your MX endpoint without signing in. It can deliver to external recipients. It needs a static IP, and every device behind that IP can then relay, so it belongs with a firewall rule that only lets the printers' VLAN reach port 25 outbound.
• Direct Send. The device sends straight to your MX endpoint with no authentication and no connector. It is the simplest to set up and only delivers to recipients inside your own organisation. For scan-to-own-mailbox it is often enough; for a system that emails customers it is not.
• Microsoft Graph for applications. An in-house or line-of-business application can send through the Microsoft Graph sendMail API using an app registration with the Mail.Send permission, scoped to the mailboxes it should use. This removes SMTP from the picture entirely and is the route most modern application frameworks support.
• High Volume Email for Microsoft 365. Microsoft's High Volume Email service is designed for bulk mail to internal recipients, such as system notifications to all staff. Check Microsoft Learn for its current licensing, limits and authentication options before relying on it; the service spent a long time in preview and its terms have been revised since.

A transactional email service from a third party is also a reasonable choice for applications that send large volumes to customers, but that is a separate procurement and a separate set of SPF, DKIM and DMARC records to manage.

A quick decision rule

If the device supports OAuth, use OAuth. If it does not, and it only emails your own staff, use Direct Send. If it does not and it must reach outside addresses, use a connector relay from a static IP. If it is software you control, move it to Graph. Record the decision for each row in your register, because in two years nobody will remember why the warehouse printer has its own connector.

How do you switch Basic authentication off before Microsoft does?

Doing it on your own date is better than having it done to you on Microsoft's. A planned cut-over lets you choose a quiet week, warn the people who scan, and have someone on site.

1. Move each sender in the register to its new route and confirm a test message arrives, both internally and, where it matters, externally.
2. Remove the per-mailbox exception with Set-CASMailbox -Identity scanner@yourdomain.com -SmtpClientAuthenticationDisabled $true, or set it back to $null so it follows the organisation setting.
3. Turn off SMTP AUTH for the organisation. In the Exchange admin center this is the "Turn off SMTP AUTH protocol for your organization" option on the Mail flow settings page; in PowerShell it is Set-TransportConfig -SmtpClientAuthenticationDisabled $true.
4. Watch the SMTP AUTH clients report and the Authenticated SMTP sign-ins for two weeks. Anything that still appears is a sender you missed.
5. Once nothing legitimate is left, add or confirm the Conditional Access policy that blocks legacy authentication, and remove the shared scanner account from any MFA exclusion group.

If security defaults are enabled in your tenant, SMTP AUTH is already off, and any device that works today is using one of the other routes. Microsoft also notes that an authentication policy that blocks Basic authentication can stop SMTP AUTH even where the mailbox and organisation settings allow it, which is a common reason for "we enabled it and it still fails".

What does a Microsoft 365 security audit check here?

Legacy authentication is one of the areas in our Microsoft 365 security audit checklist, and SMTP AUTH is usually where the remaining exceptions live. In an audit we read the organisation and mailbox SMTP AUTH settings, the SMTP AUTH clients report and the Authenticated SMTP sign-ins, and match them against the Conditional Access policies and their exclusions. The report lists each sender with the account it uses, whether that account is excluded from MFA, and a recommended route, so the finding comes with a plan rather than a warning.

The Microsoft 365 security audit sample report shows how this is written up for a fictitious firm: one finding, the evidence behind it, the effort to close it, and the phase of the fix plan it belongs to. The audit is read-only, delivered remotely, and returned within 5 to 7 business days after a Global Administrator grants read-only access. Pricing is fixed by headcount, from US$450 for up to 10 users; the bands and the full scope are on the Microsoft 365 security audit pricing page.

For teams in the UK, legacy authentication also matters for Cyber Essentials, which expects MFA on cloud services and gets awkward about accounts that cannot use it. For teams in Australia and elsewhere, it is a question that appears on most cyber-insurance proposals. In both cases the report is designed to be used as evidence for that conversation; the assessor or insurer makes its own decision.

If what you need is someone to look after mail flow, connectors and filtering on an ongoing basis rather than a one-off review, Brocent's managed email security service covers that.

Frequently asked questions

Is Microsoft turning off SMTP in Exchange Online?

No. Only Basic authentication for SMTP AUTH client submission is being retired. SMTP AUTH with OAuth keeps working, and so do connector-based relay and Direct Send, because they do not authenticate with a mailbox password.

What happens at the end of December 2026?

According to the Exchange Team's January 2026 update (published 27 January, revised 29 January 2026), Basic authentication for SMTP AUTH will be disabled by default in existing tenants. Administrators will still be able to enable it if needed. Microsoft says the final removal date will be announced in the second half of 2027.

Can we just re-enable Basic authentication in January?

Yes, for now, and it is a reasonable short-term step for one device that cannot be replaced in time. It is not a plan: the setting will eventually be removed, and the account it depends on remains a password-only exception to your MFA policy until then.

How do I know whether a scanner supports OAuth?

Check the manufacturer's current documentation and firmware release notes for "OAuth", "Modern Authentication" or "Microsoft 365" under the email settings. If the device's settings page only asks for a username and password, it is almost certainly using Basic authentication.

Our scanner only emails our own staff. What is the simplest fix?

Direct Send to your MX endpoint, which needs no account and no password. It only delivers inside your organisation, which is all a scan-to-email workflow usually needs.

Does this affect mail sent from our website?

It does if the website signs in to smtp.office365.com with a mailbox username and password. Check the site's mail settings or plugin configuration; moving it to Microsoft Graph or to a dedicated transactional email service is usually the better fix.

Where does Microsoft publish changes to this timeline?

On the Exchange Team blog and in the Microsoft 365 admin center's Message center. Microsoft Learn's "Deprecation of Basic authentication in Exchange Online" page also points to the current announcement.

Where to start this week

Open the SMTP AUTH clients report, set the date range to the last 90 days, and export it. That single list, matched to the Authenticated SMTP sign-ins, will tell you how much work there is between now and the end of December. If you would like someone outside your team to check the tenant and hand back a ranked list with a route for each sender, talk to a consultant.