It has been almost 5 years since Microsoft announced the planned retirement of the SMTP AUTH protocol for Exchange Online and while there have been many improvements and attempts to completely get rid of it since, a firm date has been set.
September 2025, Microsoft have announced the permanent retirement of the SMTP Authentication protocol in Exchange Online and if you haven’t already migrated away from it, keep reading this post to learn about your options!
Page Contents
The permanent retirement of SMTP Authentication in Exchange Online
Back in April 2020, Microsoft disabled SMTP AUTH for any new Microsoft 365 tenants, while recognising they needed to take action to secure tenants that can send messages with only a username and password, but not impact those who still needed it. Microsoft also provided two additional methods to provide granular control over which mailboxes can use SMTP AUTH, these were the SmtpClientAuthenticationDisabled property of the global transport configuration and the SmtpClientAuthenticationDisabled property of a user mailbox.
Security Defaults also played its part in securing SMTP authentication in Exchange Online, by automatically disabling all legacy authentication protocols while it was enabled, and it was enabled, automatically for all tenants not utilising Conditional Access policies, way back in 2020.
In September 2022 Microsoft began their process to turn off basic authentication in Exchange Online, for all protocols except the SMTP protocol. Since then not much has changed, other than the growing need for an alternative client SMTP submission service and threat or retirement.
Now Microsoft has announced that during September 2025, all support and functionality for SMTP Authentication to the following endpoints will cease indefinitely:
- smtp.office365.com
- smtp-legacy.office365.com
Should you attempt to submit an email to the above endpoints after September 2025, you will get the following error message:
550 5.7.30 Basic authentication is not supported for Client Submission.
Not so similar to the related error: 535 5.7.139 Authentication unsuccessful that users may receive currently should SMTP be disabled in their tenant.
Audit services that use basic SMTP Authentication
You must get ahead of this announcement and begin to audit what services you have that are currently using SMTP client submission. Even if they are not using Microsoft technology for SMTP AUTH, you should consider this move.
Microsoft are leading this charge for one main reason: Security, and the same security concerns Microsoft have over SMTP AUTH, your other third-party SMTP providers should have too and if they don’t already, you should have a reason to be concerned.
Beginning in September 2024, the SMTP AUTH clients report in the Exchange Online admin center will be updated to differentiate between emails that were submitted to Exchange Online using SMTP (Legacy) AUTH or OAUTH. This will help you identify services that have yet to be migrated to a secure method of SMTP Client Submission. To view these reports, follow the steps below:
- Log in to https://admin.exchange.microsoft.com.
- Select Reports > Mail Flow > SMTP AUTH clients report.
Identify replacement services
The key problem to solve is to identify which replacement service provided by Microsoft will best suit your needs and to rule out those that don’t. Take a look at the viable (and secure), options you have to replace legacy SMTP AUTH in your environment.
High Volume Email
High Volume Email is primarily used for internal communication, but can send emails externally also. It operates identically to the legacy SMTP AUTH protocol and is a strong contender to replace it. The best part is that it does not use the existing transport configuration for your tenant and therefore, SMTP AUTH can remain fully disabled in all areas, except Security defaults or Conditional Access. HVE will certainly provide a similar experience to what you are used to, however, Microsoft have not yet released their commercial strategy for the product while it still remains in preview.
For more information on High Volume Email, including how to enable and use it in your tenant, see: Enable High Volume Email for Microsoft 365.
Azure Communication Services
Azure Communication Services is used to send emails both internally and externally. It provides APIs that enable you to add various communication services to your applications, including email via SMTP AUTH. It works slightly differently compared to traditional SMTP AUTH whereby you enable the service in Azure (utilising Azure consumption-based billing) and create an application in EntraID which is then assigned to it. You then authenticate to the SMTP service using the ClientID, TenantID and Secret Key of the EntraID Application.
For more information on enabling SMTP AUTH with Azure Communication Services, see: How to create authentication credentials for sending emails using SMTP.
On-premises Exchange Relay
While not a modern approach, if you are still using an on-premise Exchange server in a hybrid configuration, then you can still authenticate your services to the on-premises Exchange server and using a connector, relay that out to Microsoft 365 then deliver it to either internal or external recipients.
Direct send with Microsoft 365
The final and simplest option, which is free and can deliver email internally and externally, is to use the Direct Send features built into Exchange Online. Direct Send can be used even after SMTP AUTH has been fully disabled and while Security Defaults or Conditional Access is enabled in your tenant. This option is perfect for MFP devices, but may not be best suited for high-volume emails or any emails that may require a response from the recipient. To use Direct Send, you create a supporting email connector in Exchange Online, restricted by IP or Certificate, then update your SMTP to include the sending IP address, and then you can submit emails to your public Exchange Online MX Record.
For more information on setting up Direct Send, see: Configure a connector to send emails using Microsoft 365 or Office 365 (SMTP relay).
Third party services
Personally, I am still recommending that you consider third-party services for any SMTP Client submission needs, but ONLY those that you trust. What I mean by this is, DONT use dedicated SMTP services that are supposedly ‘secure’ online. Google search is quickly returning some shady pages for search terms such as ‘Secure SMTP’.
By services that you trust, I am talking about your dedicated email security providers like T-rend, M-imecast or H-ornetSecrity. If you are really stuck, reach out to your vendor for advice and/or possible alternative solutions.