Office 365 SMTP Settings After Basic Auth Died: 2026 Guide
The classic office 365 smtp settings - smtp.office365.com, port 587, username and password - still appear in ten thousand tutorials, and they now fail on most tenants by default. Microsoft spent years dismantling basic authentication, and what remains is a service that accepts the old settings only when two separate switches agree to allow it, plus an OAuth path most simple tools cannot speak.
Here is what actually works in 2026, which switch produces which error, and when to stop fighting the mailbox and use one of Microsoft's two purpose-built alternatives.
The settings that still exist
| Setting | Value |
|---|---|
| Host | smtp.office365.com |
| Port | 587 with STARTTLS (port 25 submission is not supported for this host) |
| Username | the full mailbox address doing the sending |
| Credential | OAuth 2.0 token, or the mailbox password only where SMTP AUTH is enabled |
| Sender | the mailbox itself, or an address it holds Send As rights for |
The host and port half of that table has not changed in a decade. Everything difficult lives in the credential row, because "where SMTP AUTH is enabled" now means threading two independent tenant controls.
The two switches that decide whether passwords work
Switch one: SMTP AUTH itself. Exchange Online exposes authenticated SMTP as a per-mailbox setting, with a tenant-wide default. Microsoft has been disabling it by default across tenants; a mailbox with it off refuses password logins to SMTP no matter how correct they are. The error is explicit and famous: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant. An admin can re-enable it tenant-wide or - far better - per mailbox, only for the accounts that genuinely need it.
Switch two: Security defaults. Tenants running Microsoft's security defaults block legacy authentication protocols wholesale, SMTP AUTH included, and the per-mailbox switch cannot override that policy. Organizations using Conditional Access instead can carve precise exceptions. The symptom of losing to this switch is password logins failing with authentication errors even though Exchange shows SMTP AUTH enabled - the block sits a layer above Exchange.
Password-based sending works only when switch one is on for the mailbox and switch two is not blocking legacy auth. Two yeses, or no mail.
The OAuth path, honestly assessed
Modern software authenticates to smtp.office365.com with OAuth 2.0: an app registration in Entra ID, the SMTP.Send permission, tokens instead of passwords. It coexists happily with both switches and is Microsoft's intended future.
The honesty part: OAuth SMTP is a developer feature, not a settings-screen feature. Mainstream mail clients handle it invisibly, but the population that actually uses raw SMTP settings - scanners, appliances, cron scripts, legacy line-of-business apps - mostly cannot. For that population the real-world choice is: get SMTP AUTH enabled for one dedicated service mailbox, or leave the mailbox path entirely for one of the alternatives below.
Microsoft's two official alternatives
Direct send points a device at your tenant's MX endpoint (yourdomain-com.mail.protection.outlook.com, port 25) with no authentication. It can only deliver to your own tenant's mailboxes, external delivery is refused, and messages are still subject to spam filtering. It is the right tool for the office scanner emailing staff and nothing else.
A connector-based relay lets Exchange accept mail from your registered public IP and relay it anywhere, external recipients included. It demands a static IP, careful SPF updates, and the discipline to remember the connector exists when the office changes ISPs three years later. It is the closest Microsoft equivalent to a classic relay, sized for operational volume rather than campaigns.
Between the two and the mailbox path, the decision compresses to: internal-only convenience mail, direct send; departmental operational sending with a static IP, connector; software that must act as a specific licensed mailbox, SMTP AUTH on that mailbox or OAuth if the software can.
Limits nobody reads until they hit them
Whatever path authenticates, Exchange Online's sending limits ride along: 30 messages per minute per mailbox, 10,000 recipients per mailbox per day, and 500 recipients on any single message. The per-minute throttle is the one that surprises engineers - a queue that bursts 200 messages in a minute gets tempo-limited with 4.3.2-class deferrals that look like an outage and are actually a metronome. Pace outbound to under 30 a minute per sending identity and the deferrals evaporate.
These are mailbox-path numbers; connectors carry different accounting, and none of it is designed for marketing volume. Microsoft's own documentation says bulk email belongs on third-party providers, in exactly those words.
A troubleshooting order that respects the architecture
- Prove the transport:
openssl s_client -starttls smtp -connect smtp.office365.com:587from the sending machine. Banner means the network path is fine. - Classify the failure: 535 5.7.139 means switch one; generic auth failures with SMTP AUTH enabled mean switch two; 550 5.7.60-class sender errors mean the From address is not the authenticated mailbox or lacks Send As rights.
- Check both switches in writing - Exchange admin center for the mailbox's SMTP AUTH state, Entra for security defaults or Conditional Access policy - before touching any application config twice.
- If the tool cannot do OAuth and policy will not open SMTP AUTH, stop negotiating: direct send for internal, connector for external operational, a sending platform for anything volume-shaped.
The 2026 posture in one sentence: smtp.office365.com still works, but treat password SMTP as an exception you request per mailbox with a reason attached - and treat every tutorial showing plain settings without mentioning the two switches as the archaeology it is.
Frequently asked questions
What are the correct Office 365 SMTP settings?
Host smtp.office365.com, port 587 with STARTTLS, the full mailbox address as username, and either an OAuth 2.0 token or - only where SMTP AUTH is enabled for that mailbox and not blocked by security defaults - the mailbox password.
Why does Office 365 SMTP say authentication unsuccessful?
The 535 5.7.139 SmtpClientAuthentication-disabled error means the SMTP AUTH switch is off for the tenant or mailbox. If SMTP AUTH shows enabled and passwords still fail, security defaults or Conditional Access is blocking legacy authentication one layer above Exchange.
What is the difference between SMTP AUTH, direct send, and a connector in Office 365?
SMTP AUTH sends as a licensed mailbox from anywhere with credentials; direct send delivers unauthenticated to your own tenant's mailboxes only; a connector relays from your registered static IP to any recipient. They are three different tools for personal-identity, internal-device, and operational-relay sending respectively.
How many emails can I send through Office 365 SMTP?
Mailbox-path sending carries Exchange Online's limits: about 30 messages per minute, 10,000 recipients per day per mailbox, and 500 recipients per message. Microsoft explicitly directs bulk and marketing volume to third-party sending services rather than any of these paths.