SMTP AUTH basic authentication is being disabled in Exchange Online (end of December 2026): find and fix the apps and scanners that still use it

Microsoft is switching off SMTP AUTH basic authentication in Exchange Online in stages. The earlier schedule (March to April 2026) was replaced: the Message Center mirror says the earlier deprecation “has been put on hold” in favour of the timeline below. The date to plan for is the end of December 2026, when it is reported to be turned off by default for existing tenants, with admins still able to re-enable it. The date of final removal is not decided. Anything that sends mail by logging in with a username and password over SMTP (scanners, multifunction printers, old line-of-business apps, scripts) is affected.

Source caveat. The dates in this section come from two secondary sources that agree with each other: heise’s report of Microsoft’s timeline post, and a mirror of Microsoft’s Message Center post MC786329 (updated 27 January 2026; the Microsoft blog post shows a modified date of 29 January 2026). I could not read the body of Microsoft’s own post when writing this page, so check every date below against the Microsoft post before you act on it.

Item	What the source says	Status
Original plan	Phase-out announced in April 2024, starting in March 2026 (heise)	Replaced by the update
Until December 2026	Basic behavior “will remain unchanged” (heise)	Reported
End of December 2026	Basic is off by default for all existing tenants; admins can still re-enable it (heise)	Reported
New tenants after December 2026	Basic is not available by default; OAuth is the supported method (heise)	Reported
Final removal	Microsoft plans to announce the date in the second half of 2027 (heise, Message Center mirror)	Not decided

Microsoft’s Learn page agrees on the direction but gives no date. It says: “Although SMTP AUTH is currently available, Microsoft has announced plans to retire Basic authentication for SMTP AUTH in Exchange Online.” and sends readers to the timeline post for current milestones.

Who is affected, and what breaks?

You are affected if any client submits mail to Exchange Online with SMTP AUTH (normally TCP port 587) using basic authentication. Microsoft describes SMTP AUTH as the protocol POP3/IMAP4 clients use to send mail, and that applications, reporting servers and multifunction devices use to send email. Microsoft also says virtually all modern email clients (Outlook, Outlook on the web, iOS Mail) do not use SMTP AUTH to send. In practice that points at devices and apps, not people. That is my reading of those two statements, not a Microsoft claim.

Things that change the picture for a tenant:

• Security defaults. Microsoft says that if security defaults is enabled, SMTP AUTH is already disabled.
• Authentication policy. If an authentication policy disables basic authentication for SMTP, clients cannot use SMTP AUTH even if you enable it.
• Per-mailbox setting. It overrides the organization setting (see the options section).
• Only Exchange Online mailboxes. These settings apply only to mailboxes hosted in Exchange Online.

What the error looks like. None of the Microsoft pages I read documents the SMTP error text that a device or app receives when basic SMTP AUTH is refused, so I am not quoting one. Expect the symptom to be a failed login on submission, usually reported by the device or app itself. Capture the actual text from your own device log in a test before the change.

How do I find what still uses SMTP AUTH?

Start from the sign-in logs. Microsoft documents “Authenticated SMTP” as one of the Legacy authentication client options in the sign-in log client app filter, described as “Used by POP and IMAP clients to send email messages.” Microsoft’s docs also show ClientAppUsed as a column in SigninLogs. I did not find a Microsoft page that states the exact string stored in ClientAppUsed for that client, so list the distinct values first:

// Which client app values exist in your tenant? Run once per table.
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| summarize Rows = count() by Table = Type, ClientAppUsed
| order by Rows desc

If the value Authenticated SMTP appears (matching the portal filter name), use it. Otherwise use whatever string your tenant shows:

// Who and what authenticates with SMTP AUTH? SMTP clients often appear as non-interactive.
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed == "Authenticated SMTP"
| summarize
    SignIns = count(),
    Failures = countif(ResultType != "0"),
    IPs = make_set(IPAddress, 10),
    LastSeen = max(TimeGenerated)
    by UserPrincipalName, AppDisplayName
| order by SignIns desc

Read it like this:

• Rows with ResultType "0" are successful logins. Those accounts are your migration list.
• Group by IPAddress to find the printer or server behind an account. A fixed internal or office egress address is typically a device or app. Many varied addresses on one account looks like abuse (see the security section).
• Which log table SMTP AUTH lands in is not stated in the pages I read, so the query covers both SigninLogs and AADNonInteractiveUserSignInLogs.

The Sign-ins using legacy authentication workbook in Microsoft Entra shows legacy authentication sign-ins, including apps using POP, IMAP and SMTP AUTH, and Microsoft describes it as a way to find workflows to migrate before you shut legacy authentication off.

Exchange Online PowerShell. Microsoft documents these checks for the per-mailbox setting:

# Organization setting (True = SMTP AUTH disabled for the org)
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

# One mailbox (False = enabled, True = disabled, blank = follows the organization setting)
Get-CASMailbox -Identity <MailboxIdentity> | Format-List SmtpClientAuthenticationDisabled

# All mailboxes by state: use -eq $true, -eq $false or -eq $null
$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}

These show configuration, not usage. A mailbox with SMTP AUTH enabled is only a candidate. Use the sign-in query to see which ones actually log in.

What are my options?

Only options that the Microsoft pages above describe are listed.

1. Move the sender to OAuth. Microsoft says OAuth 2.0 support for POP, IMAP and SMTP AUTH was released in 2020, and that SMTP AUTH supports OAuth in addition to basic authentication. For in-house apps it points to “Authenticate an IMAP, POP, or SMTP connection using OAuth”. This only works if the app or device supports OAuth for SMTP.

2. Move the sender to another protocol. Microsoft names the Microsoft Graph API (user: sendMail) as an alternative for sending authenticated mail.

3. Keep basic SMTP AUTH for a short list, on purpose. Microsoft recommends disabling SMTP AUTH organization-wide and enabling it only for the mailboxes that still need it:

   Set-TransportConfig -SmtpClientAuthenticationDisabled $true
   Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

   Values for the mailbox setting are $true (disabled), $false (enabled) and $null (follow the organization setting). This is a stopgap. Per the reported timeline, basic is going away entirely, with the final date still to be announced.

4. Replace the device or the app if it supports neither OAuth nor Graph. This is my conclusion from options 1 and 2, not a Microsoft statement.

Microsoft’s Learn pages I read do not cover High Volume Email, connector-based sending or direct send, so I make no claim about them here. Check Microsoft’s current documentation for those before choosing one.

Why does this matter for security?

Microsoft’s sign-in diagnostics guidance says legacy authentication protocols like POP, SMTP, IMAP and MAPI “can’t enforce MFA, which makes them preferred entry points for adversaries to attack your organization.” The legacy authentication workbook page adds that legacy authentication does not support MFA and makes passwordless impossible.

For detection this means a password-only SMTP login is exactly what a spray tool can use. That link is my interpretation. The password spray guide covers how spraying looks in the logs, and AADSTS 50126 is the wrong-password result you will see from it.

Until you can turn SMTP AUTH off for everyone, Conditional Access can block legacy authentication for everyone else. Microsoft’s policy template selects Exchange ActiveSync clients and Other clients. Microsoft notes that legacy sign-ins can’t do MFA and so are blocked by grant controls like requiring MFA, and that accounts that must keep legacy authentication need to be excluded from the policy. Test in report-only mode first, and exclude your documented SMTP accounts rather than switching the policy off. Report-only is my suggestion for safe rollout, not something I verified in the sources above.

Checklist

1. Confirm the dates in the Microsoft post.
2. Run the distinct ClientAppUsed query, then the SMTP query over 30 days or longer.
3. Map each account and IP to a device or app and an owner.
4. Run Get-CASMailbox to list mailboxes where SMTP AUTH is enabled.
5. For each sender: OAuth, Graph, or replacement. Record the ones you cannot move.
6. Disable SMTP AUTH at organization level and enable it per mailbox only for the remainder.
7. Add a Conditional Access block for legacy authentication, excluding only the remainder.
8. Re-run the query after the change and look for new failures.

What can’t this page tell me?

• The exact date wording in Microsoft’s timeline post, which I could not read. See the caveat at the top.
• The final removal date. Reportedly not set.
• The SMTP error text your devices will show, and the exact stored ClientAppUsed string.
• Whether your specific printer or app supports OAuth. Ask the vendor.
• Whether High Volume Email, connectors or direct send fit your case.

None of these queries has been run against a lab tenant yet, so test them in your own workspace.