SMTP error 535 5.7.3: authentication unsuccessful on Microsoft 365

SMTP error 535 5.7.3, with the text "Authentication unsuccessful," is Microsoft 365 and

Exchange Online's generic permanent authentication rejection. It is the Microsoft counterpart to

Gmail's 535 5.7.8, but it is used more broadly - Microsoft folds wrong credentials, SMTP AUTH

being disabled entirely for the mailbox or tenant, and basic-authentication deprecation into the

same reply text, and the fix depends on which of those three is actually happening.

Fault: sender configuration or tenant policy, never the mail content. Figuring out which of

the three real causes applies is the entire troubleshooting task.

Why it happens

• SMTP AUTH is disabled for the specific mailbox. Microsoft 365 ships with SMTP client

submission (SmtpClientAuthenticationDisabled) disabled by default for mailboxes created after

it became the default, independent of whether the credential itself is correct.

• SMTP AUTH is disabled tenant-wide. An administrator can also turn this off at the

organisation level, which overrides any individual mailbox setting.

• Basic authentication for SMTP was deprecated for the tenant. Microsoft has been phasing out

basic (username/password) authentication for legacy protocols, including SMTP AUTH, in favour of

modern authentication (OAuth 2.0). A tenant past its deprecation date rejects password-based

SMTP AUTH outright, regardless of the password's correctness.

• The credential actually is wrong - the one straightforward case, but statistically the

least common once the two policy-based causes above are ruled out.

Treat these four causes as an ordered checklist rather than four equally likely explanations.

Policy settings are quick to check and rule out, cost nothing to verify, and are the far more

common real-world cause - jumping straight to "the password must be wrong" skips the checks most

likely to actually explain what happened.

The transcript

$ swaks --to test@mailpilots.in --server smtp.office365.com:587 \
        --auth LOGIN --auth-user sender@tenant.onmicrosoft.com -tls
-> AUTH LOGIN
<- 334 VXNlcm5hbWU6
-> c2VuZGVyQHRlbmFudC5vbm1pY3Jvc29mdC5jb20=
<- 334 UGFzc3dvcmQ6
-> ********
<- 535 5.7.3 Authentication unsuccessful, SmtpClientAuthentication is disabled for
    the Tenant.

Note the specific phrasing here: Exchange Online frequently names the exact policy cause directly

in the text, rather than leaving you to guess - this transcript already tells you the credential

was never the problem.

How the big three word it

Diagnose it

If you administer the Microsoft 365 tenant:

$ Get-TransportConfig | Select SmtpClientAuthenticationDisabled
SmtpClientAuthenticationDisabled : True

$ Get-CASMailbox -Identity sender@tenant.onmicrosoft.com | Select SmtpClientAuthenticationDisabled
SmtpClientAuthenticationDisabled : False

If the tenant-wide setting is True, no mailbox-level setting matters - SMTP AUTH is off for

everyone until an administrator changes it.

The fix, in order

1. Read the full text of the error, not just "535 5.7.3." Microsoft frequently states

"disabled for the Mailbox" or "disabled for the Tenant" directly, which tells you exactly where

to look.

1. If SMTP AUTH is tenant-wide disabled, an administrator must explicitly re-enable it (via

Set-TransportConfig -SmtpClientAuthenticationDisabled $false) - no end-user action will fix

this.

1. If disabled at the mailbox level only, an administrator enables it for that specific

mailbox via Set-CASMailbox.

1. If the tenant has moved to modern authentication only, migrate the sending integration to

OAuth 2.0 rather than attempting to re-enable deprecated basic auth, since Microsoft is actively

retiring that path.

1. **Only after confirming both policy settings allow SMTP AUTH should you suspect the

credential itself** and proceed to reset the password or app-specific credential.

What not to do

• Do not reset the account password as the first step. In the majority of real-world `535

5.7.3` cases, the credential was never the issue - a policy setting was.

• Do not assume this behaves like Gmail's `535 5.7.8`. The underlying causes differ

significantly even though the surface symptom (authentication fails) looks the same.

• Do not fight basic-auth deprecation by retrying repeatedly. Microsoft's removal of legacy

authentication protocols is a platform-wide change with a published timeline; no retry pattern

will restore access to a retired path.

• Do not grant tenant-wide SMTP AUTH as a blanket fix if only one mailbox or integration needs

it - scope the change to the mailbox level to avoid reopening a legacy authentication path

organisation-wide.

MailPilot connects Outlook and Microsoft 365 mailboxes over OAuth specifically to stay ahead of

Microsoft's basic-authentication deprecation, so a tenant-wide policy change that would break a

password-based SMTP integration does not affect mailboxes connected this way.