Exchange Online SMTP AUTH Basic Auth Retirement Guide

Every printer, scanner, line-of-business application and script that sends mail through smtp.office365.com with a mailbox username and password is on a retirement path, and when Basic authentication is refused it gets "550 5.7.30 Basic authentication is not supported for Client Submission" instead of a delivered message. Microsoft has already revised the SMTP AUTH timeline more than once, and its current plan, published in January 2026, disables Basic authentication for SMTP AUTH by default in existing tenants at the end of December 2026. This guide is a deep dive on SMTP AUTH only: how to find every Basic auth sender, how OAuth for SMTP works, and when to choose High Volume Email, an SMTP relay connector, Azure Communication Services Email or Microsoft Graph instead. It is for Exchange Online administrators, application owners and the people who look after multifunction devices. The wider retirement of legacy protocols is covered in the Legacy Authentication and ROPC Retirement Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

End of December 2026 is the date that matters now. Microsoft's updated timeline turns SMTP AUTH Basic authentication off by default for existing tenants then; admins can still turn it back on, and a final removal date is to be announced in the second half of 2027.
The SMTP AUTH clients report tells you who is affected. Its Authentication Protocol column separates Basic Auth (TlsAuthLogin) from Modern Auth (XOAUTH2) per sender, for up to 90 days.
OAuth keeps SMTP AUTH working. Only Basic authentication is retiring; client submission with an OAuth token through SASL XOAUTH2 remains the supported path.
Many senders should leave SMTP AUTH altogether. Devices that cannot do OAuth fit an SMTP relay connector or High Volume Email; applications you own fit Graph sendMail.
The migration swaps one credential for another. OAuth app registrations, client secrets and HVE account passwords are non-human identities that need owners, scoping and rotation.

What is changing and why

SMTP AUTH (authenticated client submission) lets a device or application hand a message to Exchange Online on port 587 or 25 after authenticating as a mailbox. Microsoft disabled Basic authentication for the other Exchange Online protocols in 2022 but left SMTP AUTH available, because so many devices depended on it. What changes now is narrow: Basic authentication (a username and password sent over the TLS session) for client submission to smtp.office365.com and smtp-legacy.office365.com. OAuth-based SMTP AUTH is not being retired.

The security reason is the credential. A Basic auth SMTP sender stores a mailbox password in a device menu, a config file or a script, often for a licensed mailbox excluded from MFA and Conditional Access so the device keeps working. Microsoft's own report page describes SMTP AUTH as susceptible to misuse from compromised accounts. Those mailboxes are attractive to password spraying (ATT&CK T1110.003) and, once compromised, to sending internal phishing that passes as genuine internal mail.

Official timeline and current status

All dates below are as stated by the Exchange team, checked on 8 November 2026. The schedule has moved before, so recheck the updated timeline post before each milestone.

When (as stated by Microsoft)	What happens	Status
15 April 2024	Retirement of Basic auth for SMTP client submission announced	Original plan, since revised
September 2025, then 1 March to 30 April 2026	Earlier planned windows for a phased rollout of rejections reaching 100%	Superseded by the January 2026 update
27 January 2026 (updated 29 January 2026)	Updated timeline published	Current plan
Now to December 2026	SMTP AUTH Basic authentication behaviour unchanged	Current
End of December 2026	Basic authentication disabled by default for existing tenants; administrators can still enable it	Announced
Tenants created after December 2026	Basic authentication unavailable by default; OAuth is the supported method	Announced
Second half of 2027	Microsoft to announce the final removal date	Not yet announced

Two practical readings follow. First, the end-of-December change is reversible for existing tenants, but re-enabling Basic auth only buys time until a removal date that will be announced with notice of unknown length. Second, the original announcement said Microsoft would not grant exceptions and that Support cannot re-enable Basic auth once removed, so do not plan on a support ticket as the fallback.

Who and what is affected

Sender type	Typical set-up today	Likely destination
Multifunction printers and scanners (scan to email)	Mailbox username and password in the device web console, port 587	OAuth firmware if offered; otherwise SMTP relay connector or HVE for internal recipients
Line-of-business and vendor-hosted applications	Service mailbox password in app config	OAuth SMTP (SMTP.SendAsApp) or the vendor's Graph integration
In-house scripts and scheduled jobs	Password in the script or a credential store	Graph sendMail with certificate or managed identity credentials
Monitoring, alerting and backup appliances	Shared alert mailbox password	HVE (internal alerts) or relay connector
Bulk or customer-facing mail (notifications, receipts)	Licensed mailbox hitting sending limits	Azure Communication Services Email or a dedicated mail service
Hybrid organisations with on-premises Exchange	Devices pointing at Exchange Online	Microsoft's alternative: point them at on-premises Exchange (Basic auth or an anonymous relay Receive connector, never open relay)

Not affected: senders already using OAuth (XOAUTH2), mail sent through an inbound connector, and Direct Send to your MX endpoint, which uses no authentication at all.

Finding affected systems and identities

Run the SMTP AUTH clients report: new Exchange admin center, Reports, Mail flow, SMTP AUTH clients. Set the date range to the maximum 90 days, filter or sort on the Authentication Protocol column, and export the CSV. Every sender address shown as Basic Auth (TlsAuthLogin) is in scope. The TLS 1.0, 1.1 and 1.2 columns flag devices that will also struggle with Microsoft's TLS requirements.
Find where SMTP AUTH is allowed: run Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled for the organisation, then list mailboxes from Get-CASMailbox where SmtpClientAuthenticationDisabled is False. Microsoft documents that the mailbox value overrides the organisation value and that a null mailbox value follows the organisation.
Check authentication policies: an Exchange authentication policy that disables Basic authentication for SMTP blocks SMTP AUTH even when the transport settings allow it. Record which users hold which policy.
Read Entra sign-in logs: filter non-interactive and interactive sign-ins for the sender accounts from step 1 to find source IP addresses, which tells you whether a sender is a device on your network, a cloud-hosted vendor or something you do not recognise.
Map each sender to a device and owner: walk the IP addresses to printers, servers and SaaS vendors. A sender with no owner and no recognisable source is an incident lead, not a migration ticket.
Flag the exclusions: list the Conditional Access and MFA exclusions that exist only so these mailboxes can use Basic auth. They are removed as part of the migration.

Migration options

Choose per sender. Microsoft's multifunction device guidance compares the options; the table summarises it.

Option	Endpoint and port	Authentication	Recipients	Choose when
SMTP AUTH with OAuth	smtp.office365.com, 587 (or 25), TLS 1.2 or 1.3	XOAUTH2 token, delegated SMTP.Send or application SMTP.SendAsApp	Internal and external; 10,000 recipients a day, 30 messages a minute	The device or app supports OAuth and needs a real mailbox and Sent Items
SMTP relay (inbound connector)	Your MX endpoint, port 25	Connector matched by TLS certificate (recommended) or static public IP	Internal and external; no licensed mailbox	On-premises devices with a static IP or certificate that cannot do OAuth; not for third-party cloud hosts
High Volume Email (HVE)	smtp.hve.mx.microsoft, 587, TLS required	HVE account password or OAuth (recommended)	Internal only; 50 recipients a message, 10 MB	Internal notifications, alerts and scan to email at volume
Azure Communication Services Email	smtp.azurecomm.net, 587 (or 25), TLS 1.2 or later, or SDK	SMTP username linked to an Entra application; password is a client secret	Internal and external, Azure-managed or custom domain	Application-to-person and bulk mail to external recipients
Microsoft Graph sendMail	Graph API over HTTPS	OAuth with Mail.Send, ideally certificate or managed identity	Internal and external	Code you own; removes the SMTP dependency entirely
Direct Send	Your MX endpoint, port 25	None	Internal only	Rarely; Microsoft says most customers do not need it and is working on an option to disable it by default

Setting up OAuth for SMTP

Register an application in Entra ID. For unattended senders, add the Office 365 Exchange Online application permission SMTP.SendAsApp and grant admin consent. For interactive clients, use the delegated scope https://outlook.office.com/SMTP.Send.
Register the service principal in Exchange Online with New-ServicePrincipal, using the object ID from the Enterprise applications node, not the App registrations node. Microsoft calls this out as a common cause of failure.
Grant the service principal access to the one sending mailbox with Add-MailboxPermission, and Add-RecipientPermission if it must send as that address. Do not grant more mailboxes than it sends from.
The client requests a token with scope https://outlook.office365.com/.default and authenticates with AUTH XOAUTH2. Success returns 235 2.7.0; failure returns 535 5.7.3 Authentication unsuccessful.
Prefer a certificate credential over a client secret where the software allows it, record an owner, and set an expiry and rotation date. See the Azure Entra Client Secrets Security Guide.

Decision guidance

Small organisations: with a handful of printers, ask the vendor for OAuth firmware first; if none exists, an inbound connector matched by your office static IP is usually simplest. HVE suits internal-only scan to email where no static IP exists.
Large organisations: standardise on two or three patterns (OAuth SMTP for vendor apps, Graph for owned code, HVE or relay for devices) and route new requests to them, so the inventory does not regrow.
External recipients: HVE and Direct Send cannot reach them; use OAuth SMTP, a relay connector, ACS Email or Graph. Microsoft's ACS pages currently carry a notice that some Azure Communication Services features are being retired, so confirm Email's status in its retirement guide before committing.
Relay hygiene: a relay connector lets anything from that IP send as any accepted domain address. Prefer certificate matching, and keep SPF, DKIM and DMARC correct. See the DMARC, SPF and DKIM Guide.

Testing and rollback

Pilot on a test mailbox: move one sender to OAuth or its new route and confirm delivery, Sent Items behaviour and the report showing Modern Auth (XOAUTH2) for that sender.
Turn Basic auth off yourself, early: disable SMTP AUTH per mailbox with Set-CASMailbox -SmtpClientAuthenticationDisabled $true as each sender is migrated, then at organisation level with Set-TransportConfig. This gives you control of the date instead of Microsoft.
Watch for 550 5.7.30 and 535 5.7.3: ask device owners to report bounce or log messages for a week after each change.
Rollback: until the final removal date, a failing sender can be restored by re-enabling SMTP AUTH on that one mailbox. After the end-of-December default change, re-enabling Basic auth is possible at tenant level according to Microsoft, but treat it as a dated exception with an owner, not a fix.
Remove what is left: after migration, delete stored passwords from devices and scripts, reset the mailbox password, and remove the old MFA and Conditional Access exclusions.

Risks of doing nothing

Silent business failure: scan to email, invoices, alerts and password reset mails stop, and many devices do not alert anyone when SMTP fails.
A rushed re-enable: teams that discover the break in January turn Basic auth back on tenant-wide, which reopens it for every mailbox, not just the device that broke.
Persistent spraying target: mailboxes kept out of MFA for SMTP remain the easiest accounts in the tenant to compromise.
Unowned senders: without the inventory, senders nobody recognises keep running, including ones an attacker set up.

Where identity fits

Every option except Direct Send authenticates a non-human identity: an app registration with SMTP.SendAsApp, an HVE account (up to 100 a tenant, with no mailbox and no licence), an ACS SMTP username backed by an Entra client secret, or a Graph application. Give each one a named owner, one purpose, the narrowest mailbox scope, a credential expiry, and a review date. Keep HVE accounts separate per application or device group so one leaked password does not expose every sender. See the Azure RBAC and Service Principals Guide.

Detection, metrics and framework mapping

Basic auth senders: count of Basic Auth (TlsAuthLogin) senders in the SMTP AUTH clients report, trending to zero before end of December 2026.
Mailboxes allowing SMTP AUTH: mailboxes with SmtpClientAuthenticationDisabled set to False, matched to a register.
Exclusions removed: Conditional Access and MFA exclusions that existed for SMTP, trending to zero.
Credential hygiene: percentage of SMTP OAuth apps using certificates, and secrets within their rotation date.
Anomalies: alert on new sender addresses in the report, sudden volume spikes from one sender, and changes to SmtpClientAuthenticationDisabled.

Framework	Reference	How it applies
NIST CSF 2.0	PR.AA-03, ID.AM-02	Senders authenticate with modern methods; senders are inventoried
NIST SP 800-53 Rev. 5	IA-2, IA-5, SC-8, CM-8	Authentication, credential management, TLS protection in transit, component inventory
ISO/IEC 27001:2022	A.5.14, A.8.5	Information transfer and secure authentication
MITRE ATT&CK	T1110.003, T1078.004	Password spraying and valid cloud account abuse against Basic auth mailboxes

Practitioner checklist

Export 90 days of the SMTP AUTH clients report and list every Basic Auth sender.
Map each sender to an IP, a device or application, and a named owner.
Choose a destination per sender: OAuth SMTP, relay connector, HVE, ACS Email or Graph.
Configure OAuth apps with SMTP.SendAsApp, New-ServicePrincipal and single-mailbox permissions.
Disable SMTP AUTH per mailbox as each sender moves, then at organisation level.
Delete stored passwords, reset the mailbox passwords and remove MFA and Conditional Access exclusions.
Register every new sending identity with owner, scope and credential expiry.
Recheck Microsoft's updated timeline post before December 2026 and again when the final date is announced.

Exchange Online SMTP AUTH Basic Auth Retirement: fix printers, apps and scripts before rejection