Microsoft 365 SMTP AUTH 535 error: why every mailbox fails to sign in

You connect a batch of Microsoft 365 mailboxes to a sequencer over SMTP and every one of them fails. The passwords are correct, because you can sign in to Outlook on the web with them. The sequencer shows some version of this:

535 5.7.3 Authentication unsuccessful

When one mailbox fails, check its password. When every mailbox on a tenant fails the same way, the cause is a tenant setting, and there are four of them that can do it.

What does a 535 error from Microsoft 365 mean?

A 535 means Microsoft refused the SMTP sign-in. Either the credentials were wrong, or the tenant does not allow that kind of sign-in at all. Sequencers sending over SMTP use SMTP AUTH, which Microsoft classes as legacy authentication, and several tenant settings block it regardless of whether the password is right.

Which 535 message are you getting?

The text after the code usually tells you which setting refused you. These are the variants worth recognising:

Do not lean on the exact text too hard. In our case Security Defaults produced the plain 5.7.3 message rather than the more descriptive 5.7.139 one, so treat the table as a starting point and work through the settings in order.

What we measured

On 14 September 2026 one of our tenants failed SMTP sign-in on every mailbox with 535 5.7.3, including a licensed account. Its configuration matched the two tenants that were sending in every respect we could check: SMTP AUTH on in the transport config, mailboxes inheriting it, no authentication policies, no Conditional Access, accounts enabled, same Exchange plan.

The one difference was Security Defaults, which was on. It was turned off in Entra at 01:52 UTC. The first sign-in attempt at 01:53 returned 235 2.7.0, authentication successful. Across all ten of our tenants at the time, the two that could send had Security Defaults off and the eight that could not had it on.

This matches what Microsoft documents: if Security Defaults is enabled, SMTP AUTH is already disabled in Exchange Online, and turning it off is required to use SMTP AUTH at all. New tenants usually come with it on, which is why a brand-new tenant is the most common place to hit this.

How to fix it, in order

1. Turn off Security Defaults. In the Microsoft Entra admin center, go to Overview, then Properties, then Manage security defaults, and set it to Disabled
2. Enable SMTP AUTH for the organisation. In the Exchange admin center it is under Settings, Mail flow, as Turn off SMTP AUTH protocol for your organization, which should be unchecked
3. Check the mailboxes. A per-mailbox setting overrides the organisation one, so a mailbox explicitly disabled stays disabled whatever the tenant says
4. Check authentication policies. A policy that blocks basic authentication for SMTP stops SMTP AUTH even when both settings above are on
5. Check Conditional Access, if the tenant has it. A policy blocking legacy authentication blocks SMTP AUTH
6. Reconnect the mailboxes in the sequencer and confirm one sends before connecting the rest

Steps 2 and 3 in Exchange Online PowerShell:

# Organisation-wide: $false means SMTP AUTH is allowed
Set-TransportConfig -SmtpClientAuthenticationDisabled $false
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

# Per mailbox: $null inherits the organisation setting
Get-CASMailbox -ResultSize Unlimited | where {$_.SmtpClientAuthenticationDisabled -eq $true}
Set-CASMailbox -Identity inbox@example.com -SmtpClientAuthenticationDisabled $null

Why the toggle can look like it did nothing

Enforcement does not follow the switch instantly, and the delay is not the same in both directions. Turning Security Defaults off took effect for us in under a minute. Turning it on lagged. An earlier test of ours flipped it on and off a few minutes apart, got successful sign-ins both times, and concluded that Security Defaults does not block SMTP. It does; the test measured one state twice.

So when you test a setting, wait after changing it, and test the direction that is supposed to fail as well as the one that is supposed to work. A single passing sign-in after a toggle proves less than it seems to.

What turning Security Defaults off costs

Security Defaults is the free baseline that requires multi-factor authentication across the tenant, administrators included. Turning it off removes that baseline, so put it back where it matters: enable per-user MFA on the Global Administrator, at minimum. Tenants with an Entra ID P1 licence can use Conditional Access instead, which can allow SMTP AUTH for sending mailboxes while still requiring MFA everywhere else.

This is one of the steps in provisioning Microsoft 365 inboxes, and the reason we send real test mail from every domain before handover rather than trusting the settings page. A mailbox that cannot sign in cannot send that test, so the check catches this before a customer does.

Is Microsoft retiring SMTP AUTH?

Microsoft is retiring basic authentication for SMTP AUTH, on a timeline it has moved more than once. Under its January 2026 update, behaviour is unchanged through December 2026. At the end of December 2026 basic auth for SMTP AUTH becomes disabled by default on existing tenants, with administrators still able to turn it back on. Microsoft has said the final removal date will be announced in 2027.

OAuth sign-in for SMTP AUTH is not affected. Most cold email sequencers already offer a Microsoft OAuth connection alongside SMTP with a password, and that is the connection to prefer for anything you expect to keep running past the end of 2026.

Switching to OAuth brings its own first-time prompt: Need admin approval, cleared once per tenant by the Global Admin. The same Security Defaults setting that causes this 535 can also refuse an administrator’s sign-in outright, as AADSTS530035.