Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline

I would like to suggest a practical solution that Microsoft could potentially implement to address the challenges caused by the deprecation of Basic Authentication and the transition to OAuth.

The move to OAuth is clearly creating significant difficulties for many organisations. Implementation is often complex, and in some cases simply not feasible because many legacy devices and applications do not support modern authentication and never will. While the push toward OAuth is largely driven by the security risks associated with stolen passwords, there have also been cases where OAuth implementations have been abused or compromised. Although OAuth is undoubtedly more secure overall, it is not flawless and is considerably more complex to configure correctly.

Instead of fully removing Basic Authentication, Microsoft could enhance its security through changes within the Exchange Admin Center (EAC).

One possible approach would be for Microsoft to introduce an interface in EAC that allows administrators to create tenant-unique SMTP endpoint addresses. These tenant-specific SMTP addresses would internally route to Microsoft 365’s SMTP service to send mail, but would not be shared publicly (like smtp.office365.com)

Microsoft could enforce several security controls around these tenant-unique SMTP endpoints:

• Restrict each endpoint so it only works with specified mailboxes.
• Require regular password changes for those mailboxes.
• Make tenant-specific SMTP endpoints expire (forcing them to be renewed after 2 years for example)
• Allow administrators to revoke and regenerate tenant-unique SMTP endpoints at any time.
• Restrict the associated mailboxes so they can only send mail via SMTP (preventing interactive login and mailbox access through web browser etc).
• Require the tenant-unique SMTP endpoint value in addition to username and password for successful authentication.

This approach would mean that even if credentials were stolen, an attacker would also need the tenant-unique SMTP endpoint in order to send mail. Administrators could quickly revoke and recreate endpoints if compromise is suspected.

The core issue is not only stolen passwords, but also the shared public SMTP endpoint (smtp.office365.com), which provides a universal target. Introducing tenant-unique SMTP endpoints that Microsoft simply routes internally would significantly reduce that attack surface while preserving compatibility for legacy systems.

If implemented, this solution would:

• Improve the security of Basic Authentication.
• Allow organisations to maintain functionality for existing devices and scripts.
• Reduce reliance on a single public SMTP endpoint.
• Give administrators greater control over revocation and rotation.

This proposal is not referring to using a tenant’s MX record or configuring connectors. Rather, I’m suggesting creating a controlled, tenant-specific SMTP authentication endpoint within Microsoft 365 that preserves Basic Authentication while strengthening its security model.