At the end of December 2026, existing Exchange Online tenants will have SMTP AUTH Basic authentication disabled by default, and admins can still enable it. Applications that send through smtp.office365.com with a mailbox username and password should move to OAuth, Microsoft Graph or an email API over HTTPS before then. The final removal date is not set yet: Microsoft will announce it in the second half of 2027. These dates come from the Exchange Team's updated timeline post, published on 27 January 2026 and last updated on 29 January 2026.
On this page
The dated timeline
The post lists four milestones, quoted here in Microsoft's words.
| When | What Microsoft says |
|---|---|
| Now to December 2026 | "SMTP AUTH Basic Authentication behavior remains unchanged." |
| End of December 2026 | "SMTP AUTH Basic Authentication will be disabled by default for existing tenants." "Administrators will still be able to enable it if needed." |
| New tenants created after December 2026 | "SMTP AUTH Basic Authentication will be unavailable by default." "OAuth will be the supported authentication method." |
| Second half of 2027 | "Microsoft will announce the final removal date for SMTP AUTH Basic Authentication." |
The post applies this timeline to tenants in all cloud environments. Microsoft Learn's Basic authentication deprecation page says SMTP AUTH is currently available and that Microsoft plans to retire Basic authentication for it. Learn gives no milestones of its own and refers readers to the latest official announcement.
Older dates still circulate, and Microsoft's own 2024 announcement still carries some of them. Its body describes submission rejections starting with a small percentage on 1 March 2026 and reaching 100% on 30 April 2026. A banner on the post says the timeline was revised on 27 January 2026, so pages that still give those dates are out of date. The same post notes that Basic authentication removal for the other Exchange Online protocols finished in late 2022, leaving SMTP AUTH as the only exception.
Who is affected
Microsoft's SMTP AUTH page describes SMTP AUTH as client submission, typically on TCP port 587, the port that RFC 6409 reserves for message submission. Among the clients that use it, the page names applications, reporting servers and multifunction devices that generate and send email.
Microsoft's guide for devices and applications describes this setup for client submission:
- A licensed Microsoft 365 or Office 365 mailbox that the application sends from.
- The host
smtp.office365.com, on port 587 (recommended) or port 25. - TLS 1.2 or TLS 1.3.
- The mailbox address as the message sender.
The change is narrow. A Dynamics 365 page on Microsoft Learn says the deprecation "only impacts the use of Microsoft 365 SMTP servers". Mail that your application sends through another provider's servers is outside it. The change is also separate from Outlook.com's rules for high-volume senders, which Gmail, Yahoo and Microsoft sender requirements covers.
SMTP AUTH is already off in many tenants. Microsoft disabled it in tenants that were not using it, and security defaults disable it as well. Organizations created after January 2020 also have it disabled, although it can be enabled per mailbox (device and application guide). The mailbox setting takes precedence over the organization-wide SmtpClientAuthenticationDisabled setting in Set-TransportConfig. These switches turn SMTP AUTH itself on or off, and the timeline post does not say whether the December default change uses them.
To find what still uses Basic authentication, open the SMTP AUTH Clients report under Reports > Mail Flow in the new Exchange admin center. It shows Basic authentication as TlsAuthLogin and OAuth as XOAUTH2, for a date range of up to 90 days. Each sender that shows TlsAuthLogin relies on the method that will be disabled by default.
What the application sees
None of the Microsoft pages linked here documents the reply for the December 2026 default change. The table shows replies reported when SMTP AUTH is off or a login fails, and the reply Microsoft planned for final removal.
| Reply | Documented or reported | Meaning |
|---|---|---|
535 5.7.139 "Authentication unsuccessful, SmtpClientAuthentication is disabled for the Mailbox" | Text documented on a Dynamics 365 page; users report it with this code on Microsoft Q&A | SMTP client authentication is disabled for the user account that signs in. |
535 5.7.139 "Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant" | Reported by a user on Microsoft Q&A | SMTP client authentication is disabled for the whole tenant. |
535 5.7.139 "Authentication unsuccessful, user is locked by your organization's security defaults policy" | Reported by a user on Microsoft Q&A | Security defaults are on, and they disable SMTP AUTH. |
| "Authentication unsuccessful, the request did not meet the criteria to be authenticated successfully" | Documented on the Dynamics 365 page, without a code | Additional sign-in criteria applied, for example because multifactor authentication (MFA) is configured. |
535 5.7.3 "Authentication unsuccessful" and 5.7.57 "Client not authenticated to send mail" | Documented on Microsoft's troubleshooting page | The login failed (5.7.3), or the client is not authenticated to send (5.7.57). Microsoft's OAuth guide shows the same 535 5.7.3 for a failed XOAUTH2 login. |
550 5.7.30 "Basic authentication is not supported for Client Submission." | Planned in the 2024 announcement | Tied to permanent removal of Basic authentication, which has no date yet. |
The standards use different codes. RFC 4954, the SMTP authentication extension, specifies 535 5.7.8 Authentication credentials invalid for a login that fails because of invalid or insufficient credentials. Microsoft's 5.7.139 and 5.7.57 are not in the IANA enhanced status code registry, last updated on 6 December 2024. The planned 5.7.30 reply reuses a registered code: IANA assigns X.7.30 to "REQUIRETLS support required" (RFC 8689), not to a Basic authentication refusal.
Microsoft's troubleshooting page also uses 5.7.139 when a federated STS service was unreachable, so the code alone does not name the cause. Branch on the 535 reply code, log the full reply line, and read the text before you change settings. A 535 answers the AUTH command, so it refuses the login during submission and is not a bounce. For replies to the message itself, see how to read a bounce reply.
Your options
Microsoft documents several other ways to send application mail, and an email API over HTTPS is one more. They differ in who can receive the mail and what an admin has to set up.
| Option | Recipients | What it needs | Limits or status |
|---|---|---|---|
| App-only OAuth on SMTP AUTH | Internal and external | An access token in SASL XOAUTH2 format, a Microsoft Entra application with SMTP.SendAsApp, and its service principal registered in Exchange Online | 10,000 recipients a day and 30 messages a minute per mailbox |
Microsoft Graph sendMail with app-only access | Internal and external, from a user's mailbox | The Mail.Send application permission | Returns 202 Accepted; delivery is still subject to Exchange Online limits and throttling |
| High Volume Email | Internal recipients only | An HVE account, with Basic authentication or OAuth, on smtp.hve.mx.microsoft | Up to 50 recipients per message; no external delivery |
| SMTP relay with a static IP | Relayed through Microsoft 365 from your own server | An inbound connector and a static IP address visible to Microsoft 365 | Reasonable limits; not for spam or bulk mail |
| Direct Send | Mailboxes in your Microsoft 365 organization | No authentication | Your server sends directly to Microsoft 365 as an external email server |
| Azure Communication Services Email | Internal and external | A standalone Azure offering | Still recommended on two Exchange pages; retiring on 30 September 2028; maintenance mode; Microsoft advises against new workloads |
| Sendtier, an email API over HTTPS | 1 to 50 to addresses per email | A sending key in an Authorization: Bearer header | Public preview today; no attachments, Reply-To, cc, bcc or custom headers |
Microsoft added OAuth 2.0 support to SMTP AUTH in 2020. Its OAuth guide for IMAP, POP and SMTP requires the access token in SASL XOAUTH2 format, and gives the string in this format:
For app-only SMTP access, an application gets the token through the client credentials flow, with a service principal in Exchange, and requests it with the scope https://outlook.office365.com/.default. The application permission to choose is SMTP.SendAsApp. After a tenant admin consents to the Microsoft Entra application, the admin must also register its service principal in Exchange through Exchange Online PowerShell. This path keeps SMTP and the mailbox, and adds admin work in Microsoft Entra and Exchange Online.
For app-only access, Microsoft Graph sends from a user's mailbox with POST /users/{id | userPrincipalName}/sendMail and the Mail.Send application permission. A successful call returns 202 Accepted, and delivery is "subject to Exchange Online limitations and throttling".
High Volume Email looks like a fit, because Microsoft designed it for "automated, transactional and operational messaging". HVE accounts cannot deliver to external recipients, though, so HVE does not help an application that mails its customers. SMTP relay and Direct Send avoid SMTP AUTH entirely: relay authenticates your server with an inbound connector, and Direct Send is unauthenticated.
Microsoft's own pages disagree about Azure Communication Services (ACS) Email. The device and application guide still recommends it for internal and external recipients. The Exchange Online limits page recommends it "for bulk or high-volume emailing to external recipients". On 23 September 2026, however, Microsoft announced the retirement of ACS as a standalone offering, effective 30 September 2028. ACS Email is on the retiring list and in maintenance mode, with "security and critical fixes only". The ACS SMTP overview also warns that "some services are being retired".
Microsoft recommends using the two years to move existing workloads off ACS Email "rather than onboarding new solutions". For its own replacements, it lists High Volume Email for internal mail and Exchange Online. ACS Email remains available until retirement, but a workload built on it now would have to move again before 30 September 2028.
Why a mailbox is a poor fit for application mail
OAuth on SMTP AUTH and Graph both send from a mailbox, so both stay inside Exchange Online's limits. The Exchange Online limits allow each mailbox 10,000 recipients in a 24-hour period and 30 messages a minute, for internal and outbound mail alike. Above that message rate, messages submitted through SMTP client submission are rejected, and the client has to retry. A mailbox that reaches its recipient limit cannot send again until the 24-hour window clears.
On top of that, a tenant-wide limit counts external recipients over a sliding 24-hour window, and its size depends on the number of licenses. Trial tenants are capped at 5,000 external recipients a day. Mail from the default onmicrosoft.com domains is limited to 100 external recipients per organization in a rolling 24-hour window. Application mail shares the tenant-wide limit with everyone else in the tenant.
Microsoft is clear about what Exchange Online is for. The limits page says it "isn't suited to accommodate bulk-mailing scenarios". The ACS retirement guide describes it as designed for user email rather than bulk delivery. For legitimate bulk commercial email, such as customer newsletters, Microsoft tells customers to use third-party providers that specialize in it. Password resets and receipts are not newsletters, but they still count against the mailbox and tenant limits above.
Sending the same email through Sendtier
With Sendtier, the application sends POST https://api.sendtier.com/v1/emails instead of signing in to a mailbox. It authenticates with Authorization: Bearer and an API key, and the key sets the mode: st_test_ for tests, st_live_ for live sending. A sending key can only call POST /v1/emails and POST /v1/emails/batch.
The request below is the receipt example from the Sendtier docs, sent with a test key, so the email never reaches the mail server. Replace the key, the sender and the recipient with your own.
A successful send returns HTTP 202. The response body holds the email's em_ ID, the status queued and created_at. Today, a 202 response means accepted, not delivered. If you repeat the request within 24 hours with the same Idempotency-Key, the API returns the first response with Idempotent-Replayed: true.
Check what your mail needs before you move it. The send request has no attachments, reply_to, cc, bcc or custom headers, so a receipt with a PDF attachment cannot move as it is. Today, public availability of Sendtier's SMTP relay is not confirmed. Use HTTP. Sendtier is in public preview today, and live sending is subject to public preview warm-up limits.
Test emails are never delivered, so you can try the API with a test key first: start free in the quickstart.
Sources were checked on 27 October 2026: Exchange Team timeline post, Basic authentication deprecation in Exchange Online, Exchange Team 2024 announcement, SMTP AUTH in Exchange Online, RFC 6409, device and application guide, Dynamics 365 email configuration, SMTP AUTH Clients report, Microsoft Q&A on the Mailbox reply, Microsoft Q&A on the Tenant reply, Microsoft Q&A on security defaults, troubleshooting page for devices and applications, RFC 4954, IANA enhanced status code registry, OAuth for IMAP, POP and SMTP, Graph sendMail, High Volume Email, Exchange Online limits, ACS retirement guide and ACS SMTP overview.