Microsoft 365 SMTP AUTH connections using Basic authentication remain available through December 2026, subject to existing tenant policies. At the end of December, Microsoft will disable Basic authentication by default for existing tenants, although administrators can re-enable it temporarily. Identify password-based senders now and plan their replacement.
The Microsoft SMTP AUTH change concerns the authentication method, not the removal of SMTP itself. Websites, scanners and scripts may need changes even when Outlook works normally. Start with the timetable, then establish which connections your organisation uses.
What changes in December 2026?
Microsoft’s updated SMTP AUTH deprecation timeline separates the default switch-off from permanent removal. These are different events.
| Date | Change | Practical consequence |
|---|---|---|
| 16 September 2024 | Basic authentication ended for personal Outlook.com, Hotmail.com and Live.com accounts. | These accounts require Modern authentication. |
| Through December 2026 | Exchange Online SMTP AUTH Basic authentication behaviour remains unchanged. | Existing policies can still block it. |
| End of December 2026 | Basic authentication is disabled by default for existing tenants. | Administrators can re-enable it temporarily. |
| After December 2026 | New tenants have Basic authentication unavailable by default. | OAuth is the supported authentication method. |
| Second half of 2027 | Microsoft will announce the final removal date. | This is an announcement window, not the final cutoff. |
The personal-account deadline was a separate change. Microsoft’s consumer authentication guidance does not mean that every Microsoft 365 business sender lost access in 2024.
Key takeaways
- Identify authenticating accounts and their underlying devices, applications and owners.
- Disable unused SMTP AUTH access, but account for mailbox overrides and separate security policies.
- Replace Basic authentication with OAuth, Microsoft Graph or a suitable relay, then test authentication and delivery separately.
Find affected senders and effective settings
Use the SMTP AUTH clients report
Open the Exchange admin centre, select Reports, then Mail flow and the SMTP AUTH clients report. Microsoft’s report documentation describes the default 7-day window. Review sending accounts, message counts and Basic or Modern authentication.
Map each account to its actual senders. Several printers and scanners, along with applications, may share one mailbox, so an account entry doesn’t provide a complete device inventory.
Include CRM platforms, payroll notifications, website forms and scheduled scripts. Record the owner, authentication method, From address and business purpose. Extend the review beyond 7 days to capture monthly reports and occasional notifications.
Establish which settings apply
Review SmtpClientAuthenticationDisabled using Get-TransportConfig and Get-CASMailbox. At mailbox level, True disables SMTP AUTH, False enables it, and an unset value inherits the organisation setting.
Turn off SMTP AUTH for the whole organisation with Set-TransportConfig -SmtpClientAuthenticationDisabled $true; use Set-CASMailbox to disable it for an individual mailbox.
A mailbox-level enablement can override organisation-wide SMTP AUTH disablement. However, authentication policies or Security Defaults can still prevent the connection.
Microsoft 365 administrators can also manage the mailbox control in the Exchange admin center under Users, Active users, Mail, Manage email apps, Authenticated SMTP. Distinguish enabling the protocol from permitting Basic authentication.
Our Microsoft 365 and cloud support can place these exceptions alongside account ownership and wider organisation administration.
Choose a replacement that fits the sender
Basic authentication submits a reusable username and password. It cannot enforce multi-factor authentication during that exchange and remains exposed to password spraying and brute-force attacks.
OAuth tokens carry permissions and expire. You can withdraw authorisations, but an issued access token may remain valid until expiry. Unattended applications also need credential protection; OAuth doesn’t make them equivalent to an MFA-protected user session.
Choose the route according to application support and recipient requirements.
| Sending route | Suitable use | Main constraint |
|---|---|---|
| SMTP with OAuth | Compatible devices and existing SMTP applications | Client must support OAuth and token renewal. |
| Microsoft Graph | Applications that can send over HTTPS | Requires API integration and appropriate permissions. |
| Transactional SMTP relay | Password-based devices and transactional applications | Separate credentials, charges and domain authentication. |
A relay can remove the dependency on Microsoft mailbox passwords without removing password-based authentication entirely. Its credentials still need restricted access and rotation.
Move compatible SMTP clients to OAuth 2.0
Use supported integrations first
Applications offering Sign in with Microsoft normally handle their own app registration. Easy WP SMTP’s Microsoft 365 / Outlook mailer with One-Click Setup similarly avoids a custom Entra registration.
For scan-to-email, Ricoh, Canon, Kyocera, HP, Toshiba and Lexmark offer OAuth support on supported models, often through firmware updates. Manufacturer support does not establish that every older device can be upgraded.
Use smtp.office365.com, port 587, STARTTLS and OAuth authentication. Changing the host or selecting TLS does not convert a stored-password connection to OAuth.
Register a custom application where necessary
For applications your organisation develops or controls, follow Microsoft’s SMTP OAuth implementation guidance.
- Register the application in Microsoft Entra ID and configure the redirect URI required by its authentication flow.
- For delegated access, add Exchange Online’s
SMTP.Sendpermission and request thehttps://outlook.office.com/SMTP.Sendscope. Requestoffline_accesswhen refresh tokens are needed. - Obtain consent and tokens through the supported flow, then authenticate SMTP using SASL XOAUTH2 rather than a mailbox password.
For unattended app-only access, use SMTP.SendAsApp, administrator consent and the required Exchange service-principal and mailbox authorisation. Adding the Entra permission alone is insufficient.
Protect application credentials and document renewal ownership. Review consent carefully; our guidance on Microsoft device-code phishing explains why a legitimate Microsoft sign-in page does not establish that an authorisation request is safe.
Use Microsoft Graph or a transactional relay
Send through Microsoft Graph over HTTPS
The Microsoft Graph API sends mail through HTTPS rather than SMTP. Applications use POST /me/sendMail for delegated access or POST /users/{id}/sendMail for the relevant user, with the Mail.Send permission.
Microsoft’s sendMail API documentation distinguishes request acceptance from completed delivery. A successful API response isn’t proof that a recipient received the message.
Restrict application access to the required mailboxes. Graph is also useful where a web host blocks port 587. API-based WordPress mailers can send over HTTPS, although they must support the selected provider and authentication flow.
Configure a transactional SMTP service
A transactional email service using SMTP relay is often practical when an application supports SMTP credentials but can’t implement OAuth.
For SendLayer, set the SMTP server to smtp.sendlayer.net, use port 587 and TLS through STARTTLS. Enter the SMTP credentials from the provider dashboard, not Microsoft 365 credentials. The From address must use an authorised domain.
Configure the provider’s required DNS records and test SPF, DKIM and DMARC alignment. Our email authentication guidance explains why successful SMTP authentication doesn’t establish that the visible sending domain is authenticated.
Compare message allowances, retention, delivery logs and charges. Exchange mailbox limits still apply to mailbox-based sending; changing authentication doesn’t turn a mailbox into a bulk-email service.
Consider Microsoft-native relay alternatives
High Volume Email for Microsoft 365 supports internal recipients only. It is relevant to internal operational notifications, but cannot replace a route that sends invoices or customer updates externally.
Azure Communication Services Email supports internal and external delivery. Exchange Hybrid Relay can also be appropriate where an organisation already operates suitable Exchange infrastructure.
Microsoft 365 SMTP relay uses a connector and the tenant’s MX endpoint on port 25, with an approved certificate or static public IP configuration. This differs from authenticated client submission on port 587.
Direct Send can deliver to internal Microsoft 365 recipients without mailbox authentication, but does not relay to external recipients. Do not create an unrestricted relay to avoid a sign-in failure.
Resolve errors without reopening legacy access
Retain the complete error, sender, recipient and timestamp before changing settings. Similar-looking failures can have different causes.
| Error or symptom | Likely meaning | Next action |
|---|---|---|
535 5.7.139 with “Authentication unsuccessful, basic authentication is disabled” | Basic authentication is blocked. | Identify the applied policy and migrate the sender. |
550 5.7.30 Basic authentication is not supported for Client Submission | The attempted method is unsupported. | Replace Basic authentication rather than resetting the password. |
| Connection timeout on port 587 | Network, hosting or firewall restriction may prevent connection. | Test connectivity or use an HTTPS-based mailer. |
AADSTS7000222 | An application client secret has expired. | Deploy a replacement credential and test fresh token acquisition. |
A bare authentication failure does not prove that Basic authentication caused it. OAuth failures can involve token audience, consent, mailbox permissions or disabled SMTP AUTH.
Do not disable Security Defaults across the tenant simply to restore one device. Our IT security services can help assess the wider effect of authentication exceptions.
Test delivery before removing the old route
Test fresh authentication, token renewal, external delivery where required and representative attachments. An integration using a cached token may appear healthy until it requests another token.
Use Exchange message trace for Microsoft 365 delivery outcomes and provider logs for third-party routes. Message trace records mail flow, not every sign-in or subsequent mailbox action.
Then remove obsolete passwords, app secrets and temporary Basic authentication exceptions. Disable Microsoft 365 SMTP AUTH on mailboxes that no longer require the protocol.
Assign an owner to each remaining integration and credential expiry. A successful migration still needs ongoing administration.
Frequently asked questions
Will normal Outlook desktop email stop working?
Supported Outlook configurations using Modern authentication are not the target of this SMTP Basic authentication change. Review older clients, manually configured connections and add-ins separately; Outlook working normally does not establish that a scanner or website uses the same authentication.
Can an app password keep a legacy sender working?
An app password remains a Basic authentication credential. It does not add OAuth or remove the dependency on Basic authentication being permitted. Where temporary re-enablement is available, treat it as a documented migration exception rather than a permanent fix.
Give every sending connection an owner
Secure migration requires an identified sender, an appropriate authentication route and evidence that delivery works. Re-enabling Basic authentication may restore service temporarily, but it leaves the original dependency in place.
Speak to our team about business email security support to identify legacy connections, plan their replacement and remove unnecessary access without disrupting legitimate mail.
