Blog Post

Exchange Team Blog
4 MIN READ

Exchange Online to retire Basic auth for Client Submission (SMTP AUTH)

The_Exchange_Team's avatar
The_Exchange_Team
Icon for Microsoft rankMicrosoft
Apr 15, 2024

Today, we are announcing that Exchange Online will permanently remove support for Basic authentication with Client Submission (SMTP AUTH) in September 2025. After this time, applications and devices will no longer be able to use Basic auth as an authentication method and must use OAuth when using SMTP AUTH to send email.

In 2019, Exchange Online began a multi-year effort to disable Basic auth. This process completed in late 2022, with Client Submission (SMTP AUTH) being the only exception. We are now removing Basic auth from Client Submission.

Basic auth is a legacy authentication method that sends usernames and passwords in plain text over the network. This makes it vulnerable to credential theft, phishing, and brute force attacks. To improve the protection of our customers and their data, we are retiring Basic auth from Client Submission (SMTP AUTH) and encouraging customers to use modern authentication methods that are more secure.

How will this change happen

In mid-October 2024, we will update the SMTP AUTH Clients Submission Report in the Exchange admin center to show if Basic auth or OAuth is being used to submit email to Exchange Online. In January 2025, we will send a Message Center post to tenants who are using Basic auth with Client Submission (SMTP AUTH) to alert them to the upcoming change. In August 2025, about 30 days before we disable Basic auth we will send another Message Center post to tenants who are still using Basic auth with Client Submission (SMTP AUTH).

During September 2025, we will remove support for Basic auth with the Client Submission (SMTP AUTH) endpoints:

smtp.office365.com
smtp-legacy.office365.com 

Once Basic auth is permanently disabled, any clients or apps connecting using Basic auth with Client Submission (SMTP AUTH) will receive this response:

550 5.7.30 Basic authentication is not supported for Client Submission.

What do I need to do if I can use OAuth with Client Submission (SMTP AUTH)?

If your client supports OAuth, follow these steps:

What are the alternatives for customers who want to continue using Basic auth with Client Submission (SMTP AUTH)?

If you are a customer who must use Basic auth with Client Submission (SMTP AUTH), you will need to switch to one of the following alternatives before September 2025:

  • If you are using Basic auth with Client Submission (SMTP AUTH) to send emails to recipients internal to your tenant, you can use High Volume Email for Microsoft 365.
  • If you are using Basic auth with Client Submission (SMTP AUTH) to send emails to recipients internal and external to your tenant, you can use Azure Communication Services Email.
  • If you have an Exchange Server on-premises in a hybrid configuration, you can use Basic auth to authenticate with the Exchange Server on-premises or configure the Exchange Server on-premises with a Receive connector that Allow anonymous relay on Exchange servers | Microsoft Learn

Regardless of the volume of email, if you must use Basic auth to send email with Exchange Online, then you must use High Volume Email for Microsoft 365, Azure Communication Services for Email, or an Exchange Server on-premises in a hybrid configuration.

How to onboard to High Volume Email

High Volume Email for Microsoft 365 is a new service designed primarily for line of business applications and other high-volume SMTP Auth submissions that enables you to reliably send internal messages within Exchange Online at high volume. Customers using on-premises servers in an Exchange hybrid configuration to send a large volume of internal messages can use this service instead and decommission their on-premises servers. HVE is in Public Preview currently.

You can find detailed onboarding instructions at Manage high volume emails for Microsoft 365 in Exchange Online Public preview.

How to onboard to Azure Communication Services for Email

Azure Communication Services for Email offers businesses a centralized platform that lets them manage outgoing emails for all B2C communications and get insights into email traffic. You can use the SMTP support in Azure Communication Services to send emails easily and have more control over outgoing communications.

You can find detailed onboarding instructions at Email SMTP as service overview in Azure Communication Services.

Frequently Asked Questions

Why are you making this change?
We’re making this change to strengthen the protection of our service and your data from the increasing risks associated with Basic auth. The reasons to do this are many.

Wait! I still need to use Basic auth; how can I get it re-enabled in my tenant once it gets disabled in September 2025?
You will not be able to do this because Basic auth will be permanently disabled. Don’t waste your time engaging Support, as they cannot re-enable Basic auth for you.

What about an exception?! 
We cannot offer any exceptions; Basic auth will be permanently disabled. Please do not reach out to Support either, as they cannot grant an exception for you to use Basic auth.

Where can I read more about this?
Our official documentation is at Deprecation of Basic authentication in Exchange Online.

Summary

The only remediation for this is to update your client or app to support OAuth, use a different client or app that supports OAuth, or use a different email solution such as High Volume Email or Azure Communication Services for Email.

We understand that this change requires some adjustments, but we believe that this is a necessary step to enhance the security and reliability of our email service and your data.

Thank you for helping make Exchange Online more secure!

Exchange Online Transport Team

Updated Sep 25, 2024
Version 2.0
announcements
exchange online
security
transport
  • Manish-StrategicPM's avatar
    Manish-StrategicPM
    Icon for Microsoft rankMicrosoft
    Nov 11, 2024

    Numerous customers have approached the ACS email team with requests for shorter usernames for SMTP authentication. Currently, the format for SMTP usernames is: ""<Azure Communication Services Resource name>|<Entra Application Id>|<Entra Application Tenant Id>". However, there are legacy applications interfacing with ACS over SMTP that are constrained by a 40-character limit for usernames, which makes the lengthy ACS email username format a significant barrier to adopting our service.

    To address this issue, our team is committed to developing a solution for shorter usernames for SMTP authentication. By January 2025, we expect to launch a private preview that will allow select customers to utilize shortened usernames for establishing connections to ACS, on the condition that their ACS and email service configurations are complete and operational. This feature will allow applications to define their usernames with less characters and even use email-id as usernames.

    Once we launch the feature in public preview, I will post the details in this forum. 

    • Tobsn's avatar
      Tobsn
      Copper Contributor
      Dec 11, 2024

      Is there a way to get into the private preview? 

  • Jorgen_Hjartenflo's avatar
    Jorgen_Hjartenflo
    Copper Contributor
    Jul 26, 2024

    "Did some testing today; it works fine to use the Azure Communication Service. The biggest issue might be the actual username and password configuration on the printer/scanner.

    The username is a construct of the following three segments: <Azure Communication Services Resource Name>.<Entra Application ID>.<Entra Tenant ID>. The Azure Communication Services Resource Name is a global name in Azure and can be fairly short; mine was 12 characters. However, the other two are GUID-like, so my username became 86 characters long.

    The secrets for an Azure app are also very complex, which can be a challenge for some devices. The length is 40 characters and very complex.

    It might be easier to use SendGrid SaaS in Azure for this."

     

    Jörgen Hjärtenflo

     

  • Danourcloudnetwork's avatar
    Danourcloudnetwork
    Iron Contributor
    Apr 15, 2024

    Regarding this comment:

     

    If you are using Basic auth with Client Submission (SMTP AUTH) to send emails to recipients internal to your tenant, you can use High Volume Email for Microsoft 365.

     

    I understand you CAN send emails externally with High Volume Email, as per the MS Docs.

  • jc98jc's avatar
    jc98jc
    Copper Contributor
    Apr 17, 2024

    Will this page be updated with additional supported methods as well or will the only supported methods to send mail from a multi function device be options 2 and 3, after September 2025?  While that is almost 18 months away, multifunction device vendors are not the quickest in updating there software.

     

    https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#option-1-authenticate-your-device-or-application-directly-with-a-microsoft-365-or-office-365-mailbox-and-send-mail-using-smtp-auth-client-submission 

  • TSTBER's avatar
    TSTBER
    Copper Contributor
    Apr 16, 2024

    From my understanding client submission refers to TCP 587.

    https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#how-to-set-up-smtp-auth-client-submission 

     

    Device or Application setting Value

    Server/smart hostsmtp.office365.com
    PortPort 587 (recommended) or port 25

     

    OAuth will be supported for the very same endpoint.

  • IanMcDonald's avatar
    IanMcDonald
    Icon for Microsoft rankMicrosoft
    Apr 25, 2024

    Hoegi71 the endpoint smtp.office365.com will still be available but you will not be able to use basic auth as the authentication method. Please review this document then follow up if you still have questions: Deprecation of Basic authentication in Exchange Online | Microsoft Learn

     

    johndfe36540 great question! HVE will continue to support Basic Auth. HVE sends using an HVE account and not a cloud-hosted mailbox, so the only abuse from a compromised HVE account would be using the account to send spam internal to the tenant. This creates isolation, and there are significant security benefits from removing basic auth from SMTP AUTH which does use cloud-hosted mailboxes for sending. 

     

    jc98jc thanks for the question! So, you can/should use OAuth if your device supports it: https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth. Otherwise, those are the key methods that we have planned currently, no others.  Is there a specific alternative your organization is looking for?

  • Ron Ron's avatar
    Ron Ron
    Brass Contributor
    Apr 26, 2024

    Well, first they tell us that Basic authentication won't be disabled when you announced the deprecation of BA, as NateL1010 reminded you of, but a few months later MS is still deprecating it.

    Now we're facing two problems.
    First: External companies that were allowed to send from our domains with Authenticated submit accounts. That way everything was authenticated and logged what was send from that company in our names. We'll see if we can implement Azure Communication Services Email for that functionality, not yet familiar with that.

    But another big issue is all our multifunctional printers who deliver their scans with email to the user who scans a document.
    As jc98jc correctly mentions, MFP manufacturers are not the quickest in updating this, as if this is going to be adjusted at all! Direct send is killed this way.
    In my opinion the only way to keep using them is to place an Hybrid server (or other SMTP relay) with anonymous access and relay that mail through that server?
    Correct me if I'm wrong.