Find every device still sending mail with SMTP basic auth

Microsoft has announced the retirement of Basic authentication for SMTP AUTH in Exchange Online, and the devices that break first are the ones nobody remembers configuring: scanners, multifunction printers and old application servers with a mailbox password typed into a web form. The retirement timeline has been updated, so check Microsoft's latest announcement for current milestones rather than trusting a date from a blog post, including this one. The inventory work is the same whatever the date.

Why this one is still open

Basic authentication was already switched off in Exchange Online for Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, OAB, Autodiscover and the Outlook clients. SMTP AUTH was left alone where it was in use, and disabled in tenants where it wasn't.

More than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication, according to Microsoft's analysis in its guidance on blocking legacy authentication.

SMTP AUTH is used by POP3 and IMAP4 clients that need to send, and by applications, reporting servers and multifunction devices that generate mail.

Find what is still using it

You may find nothing. If security defaults is enabled, SMTP AUTH is already disabled in Exchange Online, and it is disabled for organisations created after January 2020 unless someone enabled it per mailbox.

Otherwise start with the sign-in logs. In the Microsoft Entra admin center, go to Entra ID > Monitoring & health > Sign-in logs, add the Client App column, and filter on the legacy authentication protocols. Repeat on the User sign-ins (non-interactive) tab, because devices rarely sign in interactively. The Sign-ins using legacy authentication workbook helps with triage.

Then look at the mailboxes. Per-mailbox settings override the organisation-wide one, so list where SMTP AUTH is explicitly enabled:

$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}

A blank value means the mailbox follows the organisation setting, so check that with Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled. Then check the printer's "scan to email" page, the ERP's notification settings, monitoring and backup tools, and any scheduled script that sends a report.

Match each hit to an owner and write down the sending address, the port, whether a third party hosts the sender, and whether the recipients are internal or external. You need those facts to choose a replacement.

What each one should move to

The right target depends on what the sender can do, where it runs and who it mails.

Microsoft recommends OAuth for client SMTP submission, and points to HVE for internal-only mail and Azure Communication Services Email for internal and external mail. With an on-premises mail server you can also relay through that, using Basic authentication to it or anonymous relay (not open relay).

Check volume first. OAuth submission is throttled to 10,000 recipients per day and 30 messages per minute. SMTP relay is not subject to those limits, though it has reasonable limits of its own, and HVE has no recipient or message rate limits for internal mail.

Printers and scanners

Check the firmware first, since a vendor update may add OAuth. If not, connector-based SMTP relay is the usual answer. It needs no licensed mailbox, authenticates by TLS certificate (recommended) or a static public IP not shared with another organisation, and uses port 25 against your MX endpoint.

Relay does not save to Sent Items and does not bypass anti-spam, so suspicious mail may be filtered. Microsoft recommends an SPF record entry, and you can review the record with our DMARC and SPF checker. A device that defaults to port 465 does not support the TLS versions client SMTP submission requires, and one without TLS 1.2 cannot use it at all.

ERP systems and other applications

Line-of-business applications such as an ERP are the hardest, because the vendor owns the mail code. Ask whether the product supports OAuth 2.0 for SMTP or the Graph API. If not, a connector relay is the fallback, provided the application runs on your own network.

If the vendor hosts it, relay is out: Microsoft's table lists SMTP relay as the one method that does not support third-party hosted senders. The vendor can use client SMTP submission with OAuth, HVE if the mail goes only to internal recipients, or Azure Communication Services Email. Direct Send also works for hosted senders, but it is unauthenticated, so update your SPF record to allow the vendor to send as your domain.

If the application sends as an address other than the signing-in mailbox, grant Send As permission. Without it, messages bounce with 5.7.60 SMTP; Client doesn't have permissions to send as this sender.

Scripts

For scripts you control, Microsoft names the Graph API as an alternative for authenticated mail, or you can implement OAuth 2.0 against the IMAP, POP or SMTP endpoints.

Where to start

1. Pull the legacy sign-ins from the Entra sign-in logs, interactive and non-interactive, and list the mailboxes where SmtpClientAuthenticationDisabled is $false.
2. Name an owner for every sender and record its recipients (internal or external), port, TLS support and whether a third party hosts it.
3. Pick a target from the table above, test one device per type, and cut each over only after a successful test message.
4. After migration, run Set-TransportConfig -SmtpClientAuthenticationDisabled $true. A mailbox still set to $false overrides that, so set each one to $null (follow the organisation) or $true with Set-CASMailbox. Re-run the -eq $false filter to prove none remain, and confirm the organisation value with Get-TransportConfig.
5. Create a Conditional Access policy that blocks legacy authentication, set to Report-only first, with at least one excluded emergency account.

If the inventory turns up more than you can migrate in time, our consulting team can help with the assessment and the cutover plan.