SMTP error 535 5.7.0: an unusual authentication failure pairing

535 is the base SMTP AUTH extension reply (defined in RFC 4954) for "authentication

credentials invalid". The enhanced status code attached narrows down why. By far the most common

pairing across the industry is 535 5.7.8 — a straightforward wrong username or password. `535

5.7.0 is less common and, per RFC 3463, 5.7.0` means "other or undefined security status" —

usually a sign of a *policy-level* authentication block rather than literally incorrect

credentials.

A real transcript

EHLO yourdomain.com
250-mx.example.com
AUTH LOGIN
334 VXNlcm5hbWU6
<base64 username>
334 UGFzc3dvcmQ6
<base64 password>
535 5.7.0 Authentication failed, policy restriction

How 535 5.7.0 differs from the other 535 variants

The 530 vs 535 distinction matters separately: 530 means you never authenticated; 535 means

you tried and were refused.

Why SMTP error 535 5.7.0 happens

1. Your provider stopped accepting plain account passwords — several major providers disabled

basic-auth password sign-in for mail clients and return a policy code rather than "wrong

password" when a legacy client still attempts it.

1. A tenant-level policy is blocking the sign-in — conditional access or legacy-auth-blocking

policies on the receiving mail platform reject the attempt before it ever compares credentials.

1. Repeated failures triggered a lockout — distinct from a single wrong password, a short-term

account lockout from too many recent failed attempts reports as this more generic code.

1. Port and encryption settings do not match what the server expects for this auth mechanism,

causing the server to refuse the attempt at a policy level rather than evaluate credentials at

all.

Diagnose it yourself

1. Check whether your client is using basic auth (plain username/password) or OAuth — if

basic auth, confirm the provider still supports it for this account type; several have phased

it out entirely for mail clients.

1. Check for a recent failed-attempt count on the account if you have access to its security

or sign-in logs — a lockout from repeated failures looks identical to a policy block from the

client's side.

1. Test the exact port and encryption combination manually: `openssl s_client -connect

mail.example.com:465 for implicit TLS, or -starttls smtp -connect mail.example.com:587` for

STARTTLS — confirm the handshake completes before AUTH is even attempted.

1. Confirm the account itself has no admin-level restriction (conditional access, legacy-auth

block, IP allow-list) if you administer the account or can ask someone who does.

How to fix SMTP error 535 5.7.0

1. Switch to OAuth 2.0 authentication if the provider has deprecated basic auth for this

account type — this is the permanent fix, not a workaround.

1. Check for and wait out a temporary lockout if repeated recent failures are the cause, rather

than retrying immediately and extending it.

1. Confirm port and encryption settings match the server's requirements exactly — a mismatch

here can produce a generic policy-level refusal rather than a specific error about the

mismatch itself.

1. Check conditional-access or legacy-auth policies on the receiving platform if you administer

it, since these can block an otherwise-correct authentication attempt entirely.

What the retry behaviour actually looks like

535 is a 5xx permanent SMTP AUTH failure for that specific authentication attempt — the

session is refused outright, not deferred — but most mail clients and sending libraries retry the

*connection* on their own schedule regardless, since from the application's point of view a failed

login often looks like any other transient send failure. This matters because a policy-level

535 5.7.0 will fail identically on every one of those retries: there is no backoff interval that

fixes a legacy-auth block or a conditional-access rule. If you see dozens of identical 535 5.7.0

attempts logged in a short window from your own sending infrastructure, that retry pattern is

itself often what triggers the lockout variant described above, rather than being a symptom of one.

What not to do

• Do not assume this is a simple wrong-password problem and spend time re-entering or resetting

credentials — the 5.7.0 pairing specifically suggests the credentials were never actually

evaluated.

• Do not keep retrying the same basic-auth flow if the provider has deprecated it — no number of

retries will succeed against a policy block, only a protocol change (to OAuth) will.

• Do not disable TLS or downgrade encryption to "get past" the error — this is never the actual

fix for a policy-level authentication block and introduces a real security regression.

MailPilot connects to Gmail and Outlook over OAuth specifically to avoid this entire class of

failure, and tracks SMTP/IMAP authentication health for connected mailboxes so a policy-level block

on a legacy credential path is visible before it causes a run of failed sends.