SMTP AUTH Basic auth goes dark in December: finding the printers and scripts before they stop sending

Every Microsoft 365 tenant I’ve audited has the same quiet corner: a scanner on the third floor, a payroll system, a monitoring server and a pile of PowerShell scripts that all send mail through smtp.office365.com on port 587 with a username and password. It’s the last big piece of Basic authentication left in Exchange Online, and it has outlived several retirement dates.

The current timeline, from the Exchange team’s January 2026 update, is clear enough to plan around:

• Until the end of December 2026 nothing changes.
• At the end of December 2026 Basic auth for SMTP AUTH (Client Submission) is disabled by default in existing tenants. Admins can still turn it back on.
• Tenants created after December 2026 won’t have it available by default.
• In the second half of 2027 Microsoft says it will announce the date when it’s removed for good.

So yes, there’s an escape hatch. But “re-enable it in January” isn’t a plan. You’d be relying on a setting with an expiry date that hasn’t been announced yet. I treat the next three months as the migration window and the re-enable option as a short-term fallback for whatever turns up late.

Step 1: find out who actually uses SMTP AUTH

Start with the SMTP AUTH clients report in the new Exchange admin center (Reports > Mail flow). The column that matters is Authentication Protocol: TlsAuthLogin means Basic auth and XOAUTH2 means modern auth. The default view covers only 7 days, so widen it to the 90-day maximum and export to CSV. Monthly jobs like payroll runs and quarterly reports won’t show up in a one-week window.

The report gives you sender addresses but not the device or application behind them. To get source IPs and the account’s sign-in pattern, check the Entra sign-in logs. If you stream them to Log Analytics, this query lists every account that has authenticated over SMTP with a legacy client:

SigninLogs
| where TimeGenerated > ago(90d)
| where ClientAppUsed == "Authenticated SMTP"
| summarize Attempts = count(),
            Succeeded = countif(ResultType == "0"),
            SourceIPs = make_set(IPAddress, 20),
            LastSeen = max(TimeGenerated)
          by UserPrincipalName
| order by Attempts desc

The IP addresses are usually how you get from “[email protected]” to an actual printer on an actual subnet, and to someone who owns it.

Step 2: see where the setting is enabled today

SMTP AUTH has an org-wide switch and a per-mailbox override. The mailbox setting wins: $true disables it, $false enables it, and $null inherits the organization value. Here’s a quick snapshot:

Connect-ExchangeOnline

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

Get-CASMailbox -ResultSize Unlimited |
    Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
    Select-Object PrimarySmtpAddress, SmtpClientAuthenticationDisabled |
    Export-Csv .\smtp-auth-explicitly-enabled.csv -NoTypeInformation

Compare that list with the report. Mailboxes that are explicitly enabled but sent nothing in 90 days are easy wins: set them back to $true (or $null if the org setting is already disabled) and remove the exposure now.

Two side notes. Tenants with security defaults enabled already have SMTP AUTH disabled. And Exchange authentication policies that block Basic auth for SMTP take precedence over these settings, so check them as well if a sender works in one place and fails in another.

Step 3: pick a target for each sender

I sort the inventory into four groups. Each one needs a different fix.

1. Code you control, such as scripts and in-house apps. Move them to OAuth. If the code already speaks SMTP, Exchange Online supports the client credentials flow for SMTP AUTH: an Entra app with the SMTP.SendAsApp application permission (under Office 365 Exchange Online) and admin consent, a service principal registered in Exchange, and a token requested with the scope https://outlook.office365.com/.default, sent over SASL XOAUTH2. The Exchange side looks like this:

# Use the Object ID from the *Enterprise application* blade, not App registrations
New-ServicePrincipal -AppId <APPLICATION_ID> -ObjectId <ENTERPRISE_APP_OBJECT_ID> `
    -DisplayName "EXO SP - Payroll notifier"

$sp = Get-ServicePrincipal -Identity "EXO SP - Payroll notifier"
Add-MailboxPermission -Identity "[email protected]" `
    -User $sp.Identity -AccessRights FullAccess

The Object ID trips up almost everyone. The documentation explicitly warns that using the App registration’s Object ID instead of the enterprise application’s causes authentication failures. For PowerShell scripts I usually skip SMTP and call Microsoft Graph sendMail directly. It’s cleaner and you don’t have to think about the SMTP protocol at all.

2. Devices and apps that only send internal mail. High Volume Email (HVE) is often the best fit here. It uses dedicated, unlicensed HVE accounts on its own endpoint (smtp.hve.mx.microsoft, port 587, TLS required) and supports OAuth or basic credentials. HVE can authenticate even when SmtpClientAuthenticationDisabled is True in the transport config, because it doesn’t go through the Client Submission endpoint. The limits to plan for: internal recipients only, up to 50 recipients per message, 10 MB maximum message size and 100 HVE accounts per tenant. It’s billed pay-as-you-go through an Azure subscription, currently listed at $42 per million recipients, and an account without a billing policy can’t send at all.

New-MailUser -HVEAccount -Name "HVE - Floor 3 scanners" `
    -PrimarySmtpAddress "[email protected]"
Get-BillingPolicy -ResourceType HVE
Set-HVEAccountBillingPolicy -Identity "[email protected]" -BillingPolicyId "<GUID>"

3. Devices that need to reach external recipients. HVE won’t deliver outside your tenant. Your options are SMTP relay through a connector authenticated by static IP, Azure Communication Services Email (which Microsoft names as an alternative for internal and external mail), or a firmware update from the vendor that adds OAuth. Ask the vendor early, because their answer determines which of the other two you need.

4. Third-party SaaS that sends “as” your users. These go back to the vendor with a deadline attached. If they can’t support OAuth by December, they become one of your documented exceptions.

Step 4: flip the switch before Microsoft does

When the inventory is mostly migrated, disable SMTP AUTH at the org level yourself and re-enable it per mailbox only for the senders that are still waiting on a fix:

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

If you do it yourself in October or November, you pick the change window, the business knows what to expect, and the exceptions are written down with owners. If you leave it to Microsoft’s default change in late December, it happens over the holidays, when the people who know which scanner belongs to which department are on leave.

The takeaway

The December change isn’t the final deadline, but it’s the first one that will actually break things in production. Run the 90-day report now, connect every sender to an owner through the sign-in logs, and route each one to OAuth, HVE, relay or ACS based on what it really does. Keep the re-enable option for the few exceptions you’ve documented, not for every sender you didn’t get to.

---

Sources & further reading: Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline, Enable or disable SMTP AUTH in Exchange Online, SMTP AUTH clients report in the new EAC, Authenticate an IMAP, POP or SMTP connection using OAuth, Manage High Volume Email for Microsoft 365, Block legacy authentication with Conditional Access, Deprecation of Basic authentication in Exchange Online.