Microsoft is changing SMTP AUTH: prepare for Basic Authentication being disabled

Thousands of printers, scanners, ERP systems, monitoring tools and web applications still connect to smtp.office365.com on port 587. Many authenticate with nothing more than a mailbox address and password. Microsoft is gradually retiring this method, known as Basic Authentication for SMTP AUTH.

The change needs to be described precisely: the SMTP AUTH protocol itself is not ending. SMTP AUTH can continue to work with OAuth. What is ending is reliance on a permanently stored username and password that cannot participate in modern access controls and creates unnecessary risk if the credentials are exposed.

Microsoft changed the timeline, not the direction

According to the updated Exchange Online timeline, behaviour remains unchanged through the end of December 2026. At the end of December 2026, Basic Authentication for SMTP AUTH will be disabled by default in existing tenants. Administrators will still be able to re-enable it temporarily if necessary.

For new tenants created after December 2026, Basic Authentication will be unavailable by default and OAuth will be the supported path. Microsoft plans to announce the final removal date in the second half of 2027. This does not give businesses a reason to postpone migration; it gives them time to complete it in a controlled manner without interrupting email flows.

Where legacy sign-in is usually hiding

The main problem is rarely Outlook. It is the systems that send email in the background and are not treated as part of the Microsoft 365 identity estate. Common examples include:

• multifunction printers and scanners sending documents by email,
• ERP, accounting, warehouse and time-and-attendance systems,
• server, backup, UPS and network monitoring tools,
• web forms, internal applications and automations,
• older help desk, CCTV or manufacturing platforms.

Knowing the password does not reveal the actual risk. The protocol and authentication method used by the client matter. In the Exchange admin centre, open Reports > Mail flow > SMTP AUTH Clients. The SMTP AUTH Clients report distinguishes Basic Authentication shown as TlsAuthLogin from modern authentication shown as XOAUTH2. It also shows the sender, message volume and TLS version; the selected reporting period can cover up to 90 days.

What may stop sending after Basic Authentication is disabled

If a device or application only knows a username and password, it will fail to authenticate to Exchange Online once Basic Authentication is blocked. The result is usually not a Microsoft 365-wide outage but the silent loss of one workflow: a scan never reaches the mailbox, the ERP system does not send an invoice, monitoring fails to deliver an alert, or a website does not confirm a submitted form.

An app password is not a solution because it still uses Basic Authentication. Port 587 and TLS encryption do not make authentication modern either; they protect the connection, not the stored credentials. Each sender therefore needs a supported target design.

Match the replacement to the scenario

OAuth with SMTP AUTH

If the device or application vendor supports OAuth for SMTP, this can be the smallest change to the current flow. The server and port may stay the same, while the client uses a token instead of a password. Microsoft's OAuth documentation for SMTP describes the delegated SMTP.Send scope and application access through SMTP.SendAsApp. Application access requires a correctly configured Microsoft Entra ID app registration, administrator consent and an Exchange Online service principal registration.

Microsoft Graph for custom applications

For a custom website, portal or automation, it is often better to stop imitating an email client and send through Microsoft Graph. The sendMail operation supports delegated and application Mail.Send permissions, HTML, MIME and attachments. Graph is not a value that can simply be entered into an ordinary printer, however; the application must be able to obtain tokens and call an API.

SMTP relay for on-premises devices

For devices on a stable company network, SMTP relay through an Exchange Online connector may be suitable. Authentication is tied to a certificate or a static, unshared public IP address, and the relay can send to internal and external recipients. It requires a properly configured connector, port 25 and controls that prevent the system from becoming an open relay.

HVE, Direct Send and Azure Communication Services

High Volume Email is designed for high-volume internal delivery within the organisation and, according to Microsoft, can also support third-party-hosted applications. It is not a replacement for external transactional messages. Direct Send can deliver only to recipients in the same organisation, and Microsoft positions it for advanced, tightly controlled scenarios. For external application and high-volume delivery, Microsoft recommends considering Azure Communication Services Email.

Microsoft's official decision guide compares the limits of these approaches. The choice should not be based only on what can be deployed fastest. It should account for who receives the messages, where the application runs, whether it supports OAuth, its sending volume and how access will be revoked.

Why simply re-enabling Basic Authentication is not enough

Temporary re-enablement may help during an incident or staged migration, but it is not a target state. Basic Authentication presents the same credentials on each attempt and cannot participate in multi-factor authentication in the way modern token-based access can. If an attacker obtains the password, it can be tested outside the managed device and the user's normal context.

Microsoft recommends disabling SMTP AUTH for the organisation and enabling it only for mailboxes that genuinely require it. Security Defaults and authentication policies must also be reviewed because they can block Basic Authentication regardless of a mailbox's individual SMTP AUTH setting.

A migration without disruption needs an owner and a pilot

1. Build an inventory. Combine the SMTP AUTH Clients report, Microsoft Entra ID sign-in logs, device configurations, DNS and firewall records, and interviews with application owners.
2. Assign ownership. Every sender needs an accountable owner, a business purpose, intended recipients and a vendor contact.
3. Select the target architecture. Decide between OAuth SMTP, Graph, relay, HVE, Direct Send or a specialist email service.
4. Test away from critical operations. Verify attachments, HTML, sender identity, limits, external delivery, SPF/DKIM/DMARC and failure behaviour.
5. Monitor after cutover. An API or SMTP server response is not enough. Monitor real delivery, queues, bounces and application logs.
6. Remove legacy secrets. After a successful transition, revoke passwords and exceptions, document the design and schedule certificate or client-secret renewal.

What management should receive

The output should not be only a list of technical accounts. Management needs to know which business processes may stop, the impact of an outage, who owns remediation and when it will be complete. Billing, security alerts, customer communication and operational notifications deserve the highest priority.

Yenwa can combine a Microsoft 365 audit with a network and application inventory, select the right path for each sender, and prepare both the pilot and post-migration verification. We deliver this work through our cloud services, ongoing IT management and custom application and integration development.

The best time to run the first report is not the day a scanner stops authenticating. It is now, while individual flows can be tested without pressure and the solution can be selected according to their real purpose.