Skip to content

Field note

SMTP AUTH Basic Auth: December 2026 Plan

SMTP AUTH is rarely owned as a service. It survives inside scanners, accounts packages, monitoring tools, websites and reporting servers until a password changes or Microsoft changes the default.

Published11 Jul 2026

Updatedyesterday

Read time5 min. 897 words.

Microsoft has revised the Exchange Online SMTP AUTH Basic authentication timeline.

Basic authentication behaviour remains unchanged until December 2026. At the end of December, it will be disabled by default for existing tenants, although administrators will still be able to enable it if needed. New tenants created after December 2026 will have it unavailable by default. Microsoft says it will announce the final removal date in the second half of 2027.

That is a delay to the default change, not a cancellation of the retirement direction.

Quick answer

Use the remaining 2026 window to find every device and application that submits mail with a stored Microsoft 365 username and password.

Typical examples include:

  • multifunction printers and scan-to-email devices
  • finance and line-of-business applications
  • website contact forms
  • monitoring and alerting platforms
  • scheduled reports
  • older POP or IMAP clients that use SMTP to send

For each one, decide whether to move to OAuth, Microsoft 365 SMTP relay, another supported mail service, or retirement of the workflow.

What the new timeline does not mean

It does not mean Basic authentication is a good long-term exception.

SMTP AUTH supports OAuth, but a device that only knows a mailbox address and password cannot gain that support through a tenant setting. It may need a firmware update, a newer application version, a relay design, or replacement.

Microsoft recommends disabling SMTP AUTH for the organisation and enabling it only for mailboxes that still require it. Security Defaults already disables SMTP AUTH, and an Exchange authentication policy can block Basic authentication even if the SMTP AUTH mailbox setting is enabled.

Those overlapping controls are why an inventory needs to record both the application and the actual authentication path.

Find what is still using it

Start with the SMTP AUTH Clients Submission report in the Exchange admin centre. Then verify the result against device and application configuration.

Look for these clues:

Server is smtp.office365.comClient SMTP submission is likely
Port 587 and a mailbox passwordBasic SMTP AUTH may be in use
Static public IP and Exchange connectorMicrosoft 365 SMTP relay may be in use
Tenant MX endpoint and internal recipients onlyDirect Send may be in use
Entra app registration and token flowOAuth may already be in use

Do not infer the method from the sender address alone. Record the host, port, authentication method, sending identity, recipient scope and system owner.

Choose the replacement by requirement

The right replacement depends on what the system must do.

OAuth for SMTP AUTH

Use this where the application supports OAuth for SMTP submission and needs to send as a mailbox to internal and external recipients. Confirm the product supports the required OAuth flow; do not assume an "OAuth ready" label covers unattended SMTP.

Microsoft 365 SMTP relay

Relay can suit on-premises devices or application servers with a stable public IP address and an Exchange Online connector. It avoids putting a mailbox password into every device. It still needs controlled connector scope, mail-flow testing and ownership of the sending infrastructure.

Direct Send

Direct Send is limited to recipients in your Microsoft 365 organisation. Microsoft recommends it only for advanced customers who can take on email-server responsibilities and warns that misconfiguration can disrupt mail flow or weaken security.

A different delivery service

For application-generated mail, a transactional email service or an application-native integration may be cleaner than making Exchange Online behave like a generic relay. Check data location, authentication, domain protection, bounce handling and support ownership before moving.

Migration checklist

For every sender:

  1. Name the business process and business owner.
  2. Record current server, port, account and authentication method.
  3. Confirm whether it sends internally, externally, or both.
  4. Check vendor documentation and supported software or firmware versions.
  5. Select a replacement based on requirements, not convenience.
  6. Test normal mail, attachments, error handling and recipient limits.
  7. Monitor failed and delayed delivery after cutover.
  8. Remove the stored password and disable the old path.
  9. Record an expiry date for any temporary exception.

For printers, also test the user experience. A technically successful relay that turns every scan failure into a silent queue is not a completed migration.

Evidence to keep

A useful SMTP AUTH retirement record contains:

  • Exchange report export and collection date
  • sender inventory with owner and purpose
  • authentication method confirmed for each sender
  • selected replacement and approval
  • vendor or firmware compatibility evidence
  • test messages to internal and external recipients where required
  • message trace or delivery evidence
  • proof that old credentials and exceptions were removed

Review this again before the end of December 2026. The aim is not merely to survive the new default. It is to stop a forgotten mailbox password from remaining part of critical business infrastructure.

Mail submission accounts belong in the same ownership review as forwarding rules, delegated access and stale identities. Use the Microsoft 365 security clean-up service as the wider control path.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?