Microsoft announced in April 2024 that it would remove Basic authentication from SMTP AUTH in Exchange Online, originally by September 2025. It later moved to a phased plan that would have started rejecting a small share of Basic authentication submissions on March 1, 2026 and reached 100 percent on April 30, 2026. On January 27, 2026, the Exchange team replaced that schedule with a new one, and the post was updated again on January 29.

What the revised timeline says

The new post sets these milestones:

  • Through December 2026, Basic authentication for SMTP AUTH keeps working as it does today.
  • At the end of December 2026, it becomes disabled by default for existing tenants, though admins can still turn it back on when needed.
  • Tenants created after December 2026 will not have it available by default, and OAuth is the supported method.
  • In the second half of 2027, Microsoft plans to announce the final removal date.

Turning it back on is a fallback, not a fix. The post describes re-enabling only for existing tenants, does not explain how it will work, and says a final removal date is still coming. Treat the end of December as your working deadline. That is about seven weeks away, with the holidays inside them. Confirm the latest Microsoft milestones before committing to a migration date, because the post's own comments questioned whether the timeline is still current and showed no official reply when we read it.

How SMTP AUTH works and why Basic is going

SMTP AUTH, which Microsoft also calls client SMTP submission, is how a scanner, a business application or a POP or IMAP mail program sends through smtp.office365.com with a mailbox's credentials, typically on port 587. With Basic authentication the sender passes a username and password. With OAuth it presents an access token issued through Microsoft Entra instead of the password itself.

Microsoft's SMTP AUTH documentation says virtually all modern email clients, Outlook included, do not use SMTP AUTH to send mail. That matters for testing: sending a normal Outlook message does not exercise the paths that are about to change.

Microsoft's security defaults documentation explains the security concern. Legacy authentication, which includes older mail protocols such as SMTP, does not support multifactor authentication, so an attacker can use it to get around an MFA policy.

What stops working and how to spot it

Microsoft's earlier announcement says that once Basic authentication is removed, a sender still using it is rejected with a 550 5.7.30 response stating that Basic authentication is not supported for Client Submission. It lists smtp.office365.com and smtp-legacy.office365.com as affected endpoints. The second is the opt-in address for devices that still need TLS 1.0 or 1.1.

A device's email settings show its route, according to Microsoft's troubleshooting guide. A server name of smtp.office365.com with a mailbox address and password means SMTP AUTH, the route this timeline covers. A name ending in mail.protection.outlook.com means Direct Send, which reaches only people inside your organization, or SMTP relay if your organization has set up a connector for that mail in Microsoft 365.

Find what still uses SMTP AUTH

Start with devices and apps that send automatically, including scanners, ticket systems and billing tools. The SMTP AUTH clients report in the Exchange admin center lists the accounts that send this way. An admin can pull it like this:

  • In the Exchange admin center, go to Reports, then Mail flow, and open the SMTP AUTH clients report.
  • Change the date range from the default 7 days to the 90-day maximum.
  • Read the Authentication Protocol column, which shows Basic Auth or Modern Auth for each sender address.
  • Select Export to save the results as a .csv file.

The report lists sender addresses, not devices, so match each address to the system that signs in with it. Microsoft notes that an empty report may only need a wider date range. A system that sends only a few times a year can fall outside even 90 days, so also ask whoever runs each system.

The report also shows the share of each sender's traffic on TLS 1.0, 1.1 and 1.2. Microsoft's setup guidance says a device must support TLS 1.2 or 1.3 for client SMTP submission, so a sender still on an older version needs attention too.

Two other views fill gaps:

  • In the Microsoft Entra admin center, open Entra ID, then Monitoring and health, then Sign-in logs, add the Client App column, filter on the legacy authentication protocols, and repeat on the User sign-ins (non-interactive) tab.
  • In Exchange Online PowerShell, Get-CASMailbox with a filter on the SmtpClientAuthenticationDisabled value can list mailboxes where it is False, meaning SMTP AUTH was switched on for that mailbox specifically.

Check two tenant settings before you choose

First, check whether your tenant uses security defaults, under Entra ID, then Overview, then Properties, then Manage security defaults in the Microsoft Entra admin center. Microsoft says Basic authentication for client submission is not compatible with them, and that SMTP AUTH is already disabled in Exchange Online while they are on. Its security defaults page also says devices that depend on device code flow, where a device shows a code you enter on another device, cannot complete sign-in while they are enabled. Ask OAuth vendors which sign-in method their setup uses.

Do not turn security defaults off just to keep an old device on Basic authentication. They require multifactor authentication and block legacy protocols across the organization. Microsoft labels the off position "Disabled (not recommended)" and says organizations that turn them off should immediately enable Conditional Access policies, which need at least Microsoft Entra ID P1.

Second, check SMTP AUTH itself. Microsoft recommends disabling it for the organization and enabling it only for the mailboxes that still need it. Organizations created after January 2020 start with it off. The organization-wide switch is labeled "Turn off SMTP AUTH protocol for your organization" and sits on the Mail flow settings page in the Exchange admin center. Each mailbox has its own Authenticated SMTP setting, which takes precedence over the organization setting.

Choose a replacement for each sender

Four questions decide each sender's route: whether it supports OAuth, whether it runs on your network or a vendor's servers, whether its mail goes only to your staff, and how much it sends at once. Ask each provider how its product authenticates and what supported alternative it offers. Microsoft documents these routes:

  • OAuth, which Microsoft recommends, keeps the sender on SMTP AUTH with the same server and port, still needs a licensed mailbox, and saves copies to Sent Items.
  • High Volume Email reaches internal recipients only, from an account with no mailbox and no license that signs in with a password or OAuth.
  • SMTP relay through an inbound connector authenticates with a certificate or a static IP address you do not share, needs no licensed mailbox and can reach outside recipients.
  • Azure Communication Services Email reaches internal and external recipients and is Microsoft's suggested route for sending to both when you cannot use the options above.
  • Direct Send delivers only to recipients in your own Microsoft 365 organization, and Microsoft says most customers do not need it.

A few limits narrow the choice. Client SMTP submission is limited to 10,000 recipients per day and 30 messages per minute, so a billing tool that sends a month of invoices at once may need relay, which has higher limits. Relay cannot be used from a third-party hosted service, and it needs port 25 open on your network and at your ISP. Without a certificate it also needs a static IP address that no other organization shares.

If a device recommends or defaults to port 465, Microsoft says it does not support the TLS versions SMTP AUTH requires. A system hosted by its vendor, such as a cloud ticket system or a hosted website form, cannot use relay. For those, the options are OAuth, Azure Communication Services, HVE for internal-only mail, or whatever sending method the vendor supports.

Move a sender to OAuth

Plan for a Microsoft 365 admin step, because Microsoft requires an application that uses OAuth to be registered with Microsoft Entra. With the vendor's instructions in hand:

  • If the vendor registered its app for use by many organizations, an admin completes a consent step in your tenant.
  • In the Microsoft 365 admin center, go to Users, then Active users, select the sending account, select Mail, then Manage email apps, and confirm Authenticated SMTP is checked.
  • If the device signs in as one mailbox but sends as another address, give the sign-in account Send As permission on the mailbox it sends as, or messages bounce with a 5.7.60 error.
  • For an app that signs in as itself rather than as a person, Microsoft's OAuth guide has an admin add the SMTP.SendAsApp application permission, register the app's service principal in Exchange with New-ServicePrincipal, and grant mailbox access with Add-MailboxPermission.

Microsoft's troubleshooting guide also notes that a copier or app that must send from many different addresses is better served by relay than by SMTP AUTH, since SMTP AUTH does not support sending as an account other than the signed-in one unless Send As is granted.

Move a sender to relay or High Volume Email

For relay, first copy your domain's MX endpoint, which ends in mail.protection.outlook.com. In the Microsoft 365 admin center, go to Settings, then Domains, select the domain, open the DNS records tab, and copy "Points to address or value" from the MX record. Then build the connector:

  • In the Exchange admin center, go to Mail flow, then Connectors, then Add a connector, and set "Connection from" to "Your organization's email server."
  • Name it, keep "Turn it on" selected, and leave "Retain internal Exchange email headers" unselected.
  • On the "Authenticating sent email" page, choose the certificate option, which Microsoft recommends, or enter a public IP address that belongs only to your organization.
  • Point the device at the MX endpoint on port 25 with TLS enabled, sending from any address in one of your accepted domains.

For an IP-based connector, Microsoft says to add the address to your domain's SPF record so messages are not flagged as spam. Edit the existing record rather than adding a second one, because Microsoft's SPF guidance says multiple SPF records for one domain cause SPF to fail. Its example record, using a sample address, reads v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all.

Relayed mail is not saved to Sent Items and can come from an address with no mailbox, so decide in advance where copies and bounces will go.

High Volume Email suits a device that sends only to staff, such as scan-to-email. Create the account in the Exchange admin center under Mail flow, then High Volume Email, then Add an HVE account. Then point the device at smtp.hve.mx.microsoft on port 587 with TLS enabled.

HVE bills through Microsoft 365 pay-as-you-go on an Azure subscription at $0.000042 per delivered recipient, so 5,000 single-recipient scans a month would cost about 21 cents. An account without a billing policy cannot send. Messages are capped at 50 recipients and 10 MB, so test your largest typical scan. The account has no mailbox, so set a Reply-To address if people may reply. With security defaults on, an HVE account can sign in only with OAuth.

Test each change and keep a record

Run a test message for each system and keep a record of the result. Plan enough time to test sender addresses, bounce handling and delivery separately, and include a recipient outside your organization, since some routes deliver only internally. Then confirm the result:

  • In the Exchange admin center, use Message trace on the device's sender address and confirm the status shows the message as delivered rather than failed, quarantined or filtered as spam.
  • Rerun the SMTP AUTH clients report, where a sender moved to OAuth should show Modern Auth and one moved to relay or HVE should stop appearing.

If a device cannot connect at all, Microsoft's troubleshooting guide suggests a Telnet test from a computer on the same network. Typing open smtp.office365.com 587 should return a line starting with 220, and no connection points to a blocked port. Microsoft's device guidance also offers an automated diagnostic in the Microsoft 365 admin center for new setups and troubleshooting.

When every sender has moved, turn SMTP AUTH off for the organization except for the mailboxes the OAuth senders use. HVE keeps working on its own endpoint. Keep the exported report, test results and each vendor's answer together for the next change.

Common mistakes and how to spot them

Watch for these shortcuts:

  • Registering the service principal with the Object ID from App registrations instead of Enterprise applications, which Microsoft says causes an authentication failure.
  • Building relay on a dynamic or shared IP address, which Microsoft does not support. If outside recipients stop getting mail after an ISP change, or a 5.7.64 TenantAttribution error appears, update the connector and the SPF record.
  • Entering an IP address in place of Microsoft's server name, which Microsoft says not to do.
  • Relaying through the SMTP server feature built into Windows Server, which Microsoft calls unsupported for relaying to Microsoft 365.
  • Switching a device to Direct Send because it needs no password. It rejects outside recipients, and where the RejectDirectSend setting is on, its mail is refused with a 550 5.7.68 error.

A worked example

Imagine a twelve-person accounting office whose 90-day report lists three Basic Auth senders: the copier's scan-to-email, an on-site billing server and a cloud-hosted ticket system. Security defaults were turned off years ago to keep the copier sending, and the office has no Conditional Access policies.

The copier's vendor supports OAuth after a firmware update, so the admin completes the consent step and confirms Authenticated SMTP is on for the copier's mailbox. A week later the report shows Modern Auth for the copier's address.

The billing server has no OAuth option and sends a few hundred invoices to customers within minutes at month-end, well past the limit of 30 messages a minute. It moves to an IP-based relay connector on the office's static IP address. The admin adds that address to the existing SPF record, and test invoices to an outside address show as delivered in message trace.

Because relayed invoices no longer land in Sent Items, the office sends them from the address of a monitored billing mailbox so bounces reach a person, and it relies on the billing software's own sent log for copies. The ticket system runs on its vendor's servers, so relay is not an option, and the vendor's supported method decides the fix.

With no Basic senders left, the office turns SMTP AUTH off for the organization except for the OAuth senders' mailboxes. Before turning security defaults back on, the admin asks the copier vendor whether its sign-in depends on device code flow.

What to do this week

Start with discovery and questions:

  • Export the 90-day SMTP AUTH clients report and give every Basic Auth sender an owner.
  • Check the Entra sign-in logs for legacy protocols on both sign-in tabs.
  • Find out why each mailbox with SMTP AUTH switched on individually needs it.
  • Ask each vendor whether it supports OAuth, which sign-in its setup uses and where its product sends from.
  • Pick an outside test address and a finish date before the holiday weeks.

Short answers to common questions

POP and IMAP mail programs send through SMTP AUTH, so they are affected too. Check whether each program supports OAuth, or whether the mailbox can be added to a current Outlook as a Microsoft 365 account instead.

A copier that sends each scan from the scanning person's own address needs Send As on each of those mailboxes. Otherwise, Microsoft's troubleshooting guide points to relay for that setup.

Where ALCO can help

ALCO's Microsoft 365 service covers Exchange and Entra ID, and its listed services include email security as well as domains and DNS. The ALCO help desk can work through the report, the vendor questions and the test messages with your staff. It is staffed 24 hours a day, including holidays, and calls are answered by a person.

Sources