Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled

Hi, it's BlueByte. A copier, a monitoring script or a line-of-business app that has been sending mail through smtp.office365.com for years suddenly fails on the AUTH step with 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant. (the reply also points you to aka.ms/smtp_auth_disabled). The password is right and the mailbox is fine; the SMTP AUTH protocol itself has been switched off somewhere between the client and Exchange Online. We'll walk through the three switches that produce this reply, how to tell from the wording which one you hit, the per-mailbox fix Microsoft recommends, and why you should plan the move off Basic authentication before the end of 2026.

The three wordings of 5.7.139 point at three different switches

The server tells you where it stopped, so read the whole line first:

535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant.
535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Mailbox.
535 5.7.139 Authentication unsuccessful, the request did not meet the criteria to be authenticated successfully. Contact your administrator.

for the Tenant means the organization-wide setting is off and the mailbox inherits it. for the Mailbox means it was turned off on that one mailbox, and the tenant setting no longer matters. did not meet the criteria is different: SMTP AUTH is on, but Basic authentication for SMTP is blocked by an Exchange authentication policy or by security defaults in Microsoft Entra ID, so the password is refused before Exchange looks at it. A plain 535 5.7.3 Authentication unsuccessful with none of that wording is a rejected credential or token.

Why the protocol is off: Microsoft turned it off wherever it wasn't used

Microsoft's guidance is to disable SMTP AUTH for the whole organization and enable it only on mailboxes that still need it, and two things happened on their side: tenants created after January 2020 start with SMTP AUTH disabled, and during the Basic authentication retirement Microsoft disabled SMTP AUTH in all tenants where it wasn't being used. So a recently created tenant, or a device that was idle during the measurement window, meets the Tenant wording with nobody in your organization having changed anything. Security defaults are the third layer: Client SMTP submission with Basic authentication isn't compatible with them, and that is the did not meet the criteria case.

Confirm which switch with Get-TransportConfig, Get-CASMailbox and Get-AuthenticationPolicy

Connect to Exchange Online PowerShell and check the organization first, then the mailbox the device signs in as, not the address it puts in From:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Get-CASMailbox -Identity scanner@contoso.com | Format-List SmtpClientAuthenticationDisabled

SmtpClientAuthenticationDisabled : True
 
SmtpClientAuthenticationDisabled :

The docs define the mailbox value precisely: True is disabled, False is enabled, and blank ($null) means the mailbox follows the organization setting. Blank plus an organization value of True is the Tenant wording; a mailbox value of True is the Mailbox wording. If both come back enabled and you still get did not meet the criteria, look at the policy layer:

Get-OrganizationConfig | Format-List DefaultAuthenticationPolicy
Get-User -Identity scanner@contoso.com | Format-List AuthenticationPolicy
Get-AuthenticationPolicy | Format-List Name, AllowBasicAuthSmtp

A policy with AllowBasicAuthSmtp : False assigned to the user, or set as the default, blocks the password. If no policy is assigned, check security defaults in the Microsoft Entra admin center under Properties → Manage security defaults; the docs say plainly that with security defaults enabled, SMTP AUTH is already disabled in Exchange Online.

Fix per cause: open the mailbox, not the tenant

For the Tenant and Mailbox wordings, enable SMTP AUTH on the sending mailbox only and leave the organization setting alone:

Set-CASMailbox -Identity scanner@contoso.com -SmtpClientAuthenticationDisabled $false
Get-CASMailbox -Identity scanner@contoso.com | Format-List SmtpClientAuthenticationDisabled

SmtpClientAuthenticationDisabled : False

The mailbox setting takes precedence over the organization setting, so this works even while Get-TransportConfig still says True. The same toggle is in the Microsoft 365 admin center under the user's Mail → Manage email apps → Authenticated SMTP. Set-TransportConfig -SmtpClientAuthenticationDisabled $false re-opens the protocol for every mailbox in the tenant; keep that as the last resort.

For did not meet the criteria caused by an authentication policy, give the one service account its own policy that allows Basic SMTP and nothing else, then push it live without waiting the default 24 hours:

New-AuthenticationPolicy -Name "Allow SMTP AUTH for scanners" -AllowBasicAuthSmtp
Set-User -Identity scanner@contoso.com -AuthenticationPolicy "Allow SMTP AUTH for scanners"
Set-User -Identity scanner@contoso.com -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

Specifying the switch without a value enables that protocol; everything else in a new policy stays blocked. If the block comes from security defaults instead, there is no per-user exception: either the client moves to OAuth, or the tenant moves from security defaults to Conditional Access policies that exclude the service account. Turning security defaults off to unblock one copier lowers protection for every user, so treat OAuth as the first option, not the fallback.

Client settings that also have to be right

Once the switch is open, the client still has to match the docs: smtp.office365.com (never an IP address), port 587 (25 works but ISPs often block it), STARTTLS with TLS 1.2 or 1.3, and the mailbox's own sign-in credentials. A device that insists on port 465 doesn't support the TLS versions Client SMTP submission requires. The sender is limited to 10,000 recipients per day and 30 messages per minute, and if the From address is a different mailbox the sign-in account needs Send As on it.

A worked example: the copier that stopped scanning to email

A tenant created in 2021 has a copier sending scans as copier@contoso.com. After a firmware reset the copier reports 535 5.7.139 ... disabled for the Tenant. If you check it yourself the way we described, Get-TransportConfig returns True and Get-CASMailbox -Identity copier@contoso.com returns a blank value, so the mailbox inherits the disabled state. The admin runs Set-CASMailbox -Identity copier@contoso.com -SmtpClientAuthenticationDisabled $false and tests from a laptop before touching the copier:

openssl s_client -starttls smtp -crlf -connect smtp.office365.com:587 -quiet
EHLO test.contoso.com
AUTH LOGIN
Y29waWVyQGNvbnRvc28uY29t
<base64 of the password>

235 2.7.0 Authentication successful

The base64 lines come from printf 'copier@contoso.com' | base64. Before the change the same session ended at the 535 5.7.139 line; after it, 235 2.7.0 confirms the protocol is open for that mailbox, and the copier sends again with no settings changed on its side.

Check it end to end before you close the ticket

Three checks, in order: Get-CASMailbox shows False for the sending mailbox; a manual AUTH LOGIN over port 587 returns 235 2.7.0; and a real message from the device lands, and also shows up in the sender's Sent Items, which relay methods don't do. If the manual test passes and the device still fails, the device is using a different account, port, or TLS version than it claims.

Keep it working past December 2026

Microsoft updated the retirement schedule on 27 January 2026: SMTP AUTH Basic authentication behaves as before until December 2026; at the end of December 2026 it is disabled by default for existing tenants, and administrators can still enable it if needed; tenants created after that point don't get it by default, with OAuth as the supported method; and in the second half of 2027 Microsoft will announce the final removal date. So the fix above buys time, not permanence. Inventory who still sends with passwords using the SMTP AUTH Clients Submission Report in the Exchange admin center, which shows Basic versus OAuth per client, then move each sender: an app you control can use OAuth with the https://outlook.office.com/SMTP.Send scope, or SMTP.SendAsApp with New-ServicePrincipal and Add-MailboxPermission for unattended sending; internal-only bulk mail fits High Volume Email; external mail from apps fits Azure Communication Services; a device that only speaks plain SMTP can use an SMTP relay connector authenticated by certificate or static IP. The per-mailbox switch governs the protocol, not the credential type, so an OAuth client still needs SmtpClientAuthenticationDisabled set to False on its mailbox.

How this differs from 5.7.60 and a wrong password

5.7.60 Client doesn't have permissions to send as this sender means authentication succeeded and the From address belongs to someone else without Send As. 535 5.7.3 Authentication unsuccessful is the credential itself: wrong password, expired token, or an MFA-enforced account with no way to satisfy the prompt. 5.7.139 sits before both: the protocol is closed, and nothing about the credential matters until it is opened.

Next time a device stops sending through Microsoft 365, walk these checks back in order: read the wording, query the organization and the mailbox, then the policy, open the smallest switch that fixes it, and put the sender on the list for OAuth or a relay before December 2026.