Move Exchange Online SMTP AUTH clients off Basic authentication with evidence

Source facts: the milestone changed, but the destination did not

In its January 2026 timeline update, the Microsoft Exchange Team says SMTP AUTH Basic authentication behavior remains unchanged through December 2026. At the end of December 2026, it will be disabled by default for existing Exchange Online tenants, although administrators will still be able to enable it if needed. New tenants created after December 2026 will have Basic authentication unavailable by default and OAuth will be the supported authentication method. Microsoft plans to announce the final removal date in the second half of 2027.

This is specifically about the Basic authentication method for SMTP AUTH client submission. It is not a statement that every device must be made to speak OAuth regardless of capability, nor does it make a connector, relay, or direct-send design interchangeable with authenticated client submission. Each alternative has different sender, recipient, network, authentication, and operational boundaries.

Microsoft’s Exchange developer documentation supports OAuth for SMTP AUTH, including delegated and application access patterns. An OAuth migration involves an identity application, appropriate permissions and consent, token acquisition, and the SMTP protocol’s OAuth mechanism. A successful token request does not prove that the application sends the intended message, and a test email does not prove the old password is no longer used elsewhere.

DSE recommendation: migrate workloads, not just credentials

Create an inventory in which every observed sender maps to a business service and a technical owner. Gather Exchange Online sign-in and mail evidence, source addresses, message headers, service-account usage, application configuration, network flows, and help-desk history. Include low-volume systems that send only monthly, quarterly, at year end, or during an incident; a thirty-day sample can miss the sender that matters most.

1. Classify the requirement. Record who or what sends, envelope and visible sender, internal or external recipients, volume, attachment size, delivery urgency, source network, high-availability need, and whether replies, non-delivery reports, or compliance retention matter.
2. Select a documented pattern. Prefer OAuth-capable SMTP AUTH when the product supports it and that pattern fits. Evaluate Microsoft-documented relay or submission alternatives where a device cannot use OAuth. Do not expose a broad unauthenticated relay or assume an IP address alone establishes trustworthy identity.
3. Build least privilege. Use a dedicated identity or application boundary, restrict allowed sender behavior where the chosen design permits it, minimize cloud and mailbox permissions, protect configuration, and assign both credential and application ownership.
4. Test the full mail contract. Exercise internal and external recipients as permitted, attachments, expected From and Reply-To behavior, non-delivery handling, throttling, retry after interruption, monitoring, and the recipient system that consumes the message. Capture message trace and application evidence.
5. Remove the legacy path. Disable or replace the stored password, update secret stores and recovery documentation, and observe long enough to cover the workload’s real schedule. Search again for Basic SMTP AUTH activity and investigate every recurrence before calling migration complete.
6. Keep an exception register. For any temporary re-enable, record the exact workload, approval, reason, risk, owner, compensating controls, expiry, and tested migration date. A tenant-wide switch without workload evidence is not an exception process.

Track known senders, owners assigned, target patterns, completed end-to-end tests, Basic activity by workload, failed authentication, delivery failures, and exception age. Recheck Microsoft’s timeline during each program review because the final removal date is intentionally not yet specified. The strong outcome is a smaller, observable mail surface whose identity and delivery behavior are understood before the default changes.

Before the tenant default changes, run a tabletop for a newly discovered legacy sender: who may re-enable Basic authentication, at what scope, for how long, and with which monitoring. Test the approval and rollback steps in advance. That prevents an urgent payroll, alarm, or facilities message from turning into an undocumented tenant-wide exception.

Official references

• Microsoft Exchange Team, Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline, updated January 29, 2026.
• Microsoft Learn, Authenticate an IMAP, POP or SMTP connection using OAuth.