Smtp Client Authentication Is Disabled for the Tenant Fix
The bounce reads like a verdict: 535 5.7.139 Authentication unsuccessful, smtp client authentication is disabled for the tenant. A printer that scanned to email for years stops overnight; a line-of-business app that mailed invoices every Friday starts erroring; nothing in your code or config changed. That is the signature of this error - it arrives on a schedule set by Microsoft, not by you, because it announces a default that flipped rather than a mistake you made.
Here is what the message means precisely, the fifteen-minute unlock, the second layer that can keep refusing after the unlock, and the checklist for the devices that generate most of these tickets.
Smtp client authentication is disabled for the tenant: meaning
Exchange Online will not accept username-and-password SMTP logins for this organization, full stop. Not "wrong password", not "account locked" - the protocol feature itself is switched off at the tenant level, and your connection was refused before any credential was evaluated. Retyping the password, regenerating it, or trying another mailbox changes nothing while the switch stays off; every account in the tenant without an explicit override gets the same refusal.
Microsoft has been disabling SMTP AUTH by default across Exchange Online for years as part of retiring basic authentication. Tenants inherit the flip at different times, which is why the error famously appears "out of nowhere" on infrastructure that never changed.
The fifteen-minute unlock, scoped properly
The correct response is almost never re-enabling password SMTP for everyone. It is an override for the one identity that needs it:
- Pick or create a service account for the device or app - not a human's mailbox. The account needs an Exchange license and nothing else.
- Enable Authenticated SMTP for that account: Microsoft 365 admin center, Users, Active users, the account, Mail, Manage email apps, tick Authenticated SMTP. PowerShell equivalent:
Set-CASMailbox -Identity svc-scanner@domain.com -SmtpClientAuthenticationDisabled $false. - Wait out propagation - minutes usually, up to an hour occasionally - and test again from the actual device.
If the same 5.7.139 text persists past propagation, the tenant-wide transport setting may be explicitly disabled in a way that overrides expectations, or you are meeting the second layer below. Check the effective state with Get-CASMailbox for the account and Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled for the tenant.
The second refusal: when the error changes shape
After the Exchange unlock, a healthy fraction of cases fail again with different wording - generic authentication failures, or sign-in blocked messages in the account's logs. That is not the same problem wearing a hat; it is the identity layer. Security defaults block legacy authentication tenant-wide regardless of Exchange settings, and Conditional Access policies frequently do the same for all but excluded groups.
The division of labor is clean: 5.7.139 with that exact tenant wording = Exchange switch; anything else after the switch is verifiably on = Entra policy. For security-defaults tenants the honest options are turning defaults off (a real decision, not a checkbox) or moving the workload to a method that needs no legacy auth. For Conditional Access tenants, the pattern is an exclusion group containing only SMTP service accounts, ideally constrained to the office or server egress IPs.
The device checklist that closes most tickets
For the printer, scanner, or appliance that raised this error, in order:
- Point it at smtp.office365.com, port 587, STARTTLS on - older devices sometimes carry ancient endpoints or port 25 configs that add unrelated failures on top.
- Set the username to the service account's full address, and the From address to the same account (or one it has Send As rights over; mismatches produce 5.7.60-class errors once auth works).
- If the device cannot do STARTTLS at all, stop here: it cannot use this path, and direct send or a connector is its future regardless of switches.
- After the unlock, reboot the device before concluding anything - a shameful number of appliances cache SMTP sessions or auth failures until restarted.
And the alternative worth raising in the same ticket: if the device only mails your own staff, direct send (your tenant's MX endpoint, port 25, no authentication) removes the credential question forever; if it must reach outside and the site has a static IP, a connector does the same. Both sidestep every switch this error is about.
If you are the vendor whose app hit this
Software that ships SMTP-with-password as its only Microsoft integration now inherits this error as a support category. The durable fixes, in ascending effort: document the per-mailbox unlock for customers' admins with the exact PowerShell line; add OAuth 2.0 SMTP (SMTP.Send permission) so locked-down tenants work without policy surgery; or offer an HTTP-API sending path through dedicated infrastructure, which removes Exchange from the loop entirely for notification-class mail. Every month, more tenants have the switch off - the error's frequency curve only bends one way.
The wider arc, briefly
This error is one checkpoint in Microsoft's long retirement of basic authentication, and its lesson generalizes: password-shaped mail credentials are becoming exceptions that need justification, scoping, and expiry plans. Fixing today's 5.7.139 with a scoped service account is correct; scheduling the review that eventually removes even that account is what keeps the fix from becoming the next incident. Mail that exists because a program sends it - alerts, receipts, reports - increasingly belongs on sending platforms with scoped keys, where tenant authentication policy is simply not part of the failure surface.
Fifteen minutes for the unlock, one policy conversation if the second layer bites, and one architecture note for the backlog: that is the complete, honest response to the tenant that turned off your Friday invoices.
Frequently asked questions
What does 535 5.7.139 smtp client authentication is disabled mean?
Exchange Online is refusing all username-and-password SMTP logins for your organization because the SMTP AUTH feature is switched off at the tenant level. No credential is being checked - the protocol itself is disabled, which is why password changes fix nothing.
How do I enable SMTP AUTH for just one mailbox?
Admin center: Users, Active users, select the account, Mail, Manage email apps, tick Authenticated SMTP. Or PowerShell: Set-CASMailbox -Identity account@domain.com -SmtpClientAuthenticationDisabled $false. The per-mailbox override beats re-enabling passwords tenant-wide.
Why does SMTP still fail after enabling authenticated SMTP?
An identity-layer policy is blocking legacy authentication above Exchange: security defaults do it tenant-wide and Conditional Access does it selectively. The wording changes from the 5.7.139 tenant message to generic auth or sign-in-blocked errors - that shift is your clue.
What should printers use instead of SMTP AUTH in Office 365?
If scans only go to your own tenant's mailboxes, direct send via your MX endpoint needs no credentials at all. If they must reach external addresses from a site with a static IP, a connector-based relay is the supported answer. Both avoid the disabled-authentication problem entirely.