SMTP 530 5.7.1: authentication required, or authorisation denied

A 530 reply means the server refuses to accept mail from you in the current state of the

session. It is a 5xx, so it is permanent: the message will not be retried and should not be.

But permanent here describes the reply, not your situation - the cause is nearly always a setting

on your side that takes minutes to change.

The first thing to know is that the enhanced code in the wild is inconsistent. RFC 3463 and the

RFC 5248 registry pair authentication-required conditions with 5.7.0, and that is what Postfix

sends. Plenty of servers send 5.7.1 instead, which the registry reserves for "delivery not

authorised, message refused". If you received 530 5.7.1, treat the 530 as authoritative and

the enhanced code as approximate.

Authentication is not authorisation

This distinction resolves most 530 tickets.

• Authentication is proving who you are. Failing it gives you 530 (you did not try) or

535 (you tried and were wrong).

• Authorisation is being permitted to do what you asked. You can authenticate perfectly and

still be refused, because the mailbox you authenticated as is not allowed to relay to that

destination or to send as that MAIL FROM address.

Authorisation failures usually arrive as 550 5.7.1 Relay access denied or, on Microsoft 365,

550 5.7.64 TenantAttribution; Relay Access Denied. If you are seeing those, rotating credentials

will not help - there is nothing wrong with the credential.

The transcript

$ openssl s_client -starttls smtp -connect smtp.example.com:587 -quiet
250-smtp.example.com
250-STARTTLS
250-AUTH PLAIN LOGIN
250 8BITMIME
MAIL FROM:<sender@yourdomain.com>
530 5.7.0 Authentication Required

That is the textbook case: the client never sent AUTH. Compare it with the Microsoft variant,

which names the stage explicitly:

530 5.7.57 Client not authenticated to send mail. [AM0PR0302CA0036.eurprd03.prod.outlook.com]

and the TLS-ordering case, which is not about credentials at all:

MAIL FROM:<sender@yourdomain.com>
530 5.7.0 Must issue a STARTTLS command first

Six causes, in order

1. SMTP authentication is switched off in the client. The most common cause and the most

boring one. Many mail libraries and CMS plugins default SMTPAuth to false; the server then

sees MAIL FROM on an unauthenticated session and refuses. Turn authentication on and supply

a username.

1. SMTP AUTH is disabled on the mailbox or the tenant. Microsoft 365 ships new tenants with

SMTP client authentication disabled, and it is enforced both org-wide and per mailbox. A

mailbox can be refused while a colleague's works. This is a tenant setting, not a password

problem.

1. You are using a password where an app password or OAuth token is required. With two-step

verification enabled, the account password is not a valid SMTP credential. Google removed

less-secure-app access for Workspace entirely, so the only options are an app password or

OAuth. Microsoft has been progressively disabling basic authentication for SMTP AUTH across

Exchange Online, which converts previously working configurations into 530 and 535 failures

with no change on your side.

1. Wrong endpoint or port. Port 587 is the submission port and expects STARTTLS on a session

that begins in the clear. Port 465 expects TLS immediately. Port 25 on most public MX hosts

does not offer AUTH at all - it is for server-to-server delivery, and attempting to

authenticate there gets you 530 or a missing AUTH advertisement.

1. TLS not established before `AUTH`. Most submission servers advertise AUTH only after the

session is encrypted. If your client sends AUTH before STARTTLS, or sends STARTTLS and

then forgets to re-issue EHLO as RFC 3207 requires, the server's capability list never

includes AUTH and you are refused.

1. Relay denied after a successful login. You authenticated, but the destination is not one

this server will relay to, or the MAIL FROM domain is not one the authenticated account may

send as. That is authorisation. Check the server's relay policy and the sender-address

restrictions on the account.

Is 530 a hard bounce?

Not in any useful sense. It is a permanent reply, so a strict classifier will record a hard bounce

• but the recipient was never evaluated. The server refused the session before or at MAIL FROM.

Suppressing the recipient address because of a 530 is a classifier bug, and a costly one:

whichever healthy address you happened to be sending to gets permanently blacklisted in your own

system.

The ordered fix

1. Capture the real session with openssl s_client -starttls smtp or swaks so you can see

whether AUTH was ever sent and whether it was advertised.

1. Confirm the port and encryption mode match: 587 with STARTTLS, or 465 with implicit TLS.
2. Verify AUTH appears in the EHLO response *after* TLS. If it does not, the server is not

offering authentication on that endpoint.

1. Check tenant and mailbox-level SMTP AUTH settings before touching the credential.
2. Switch to an app password or, better, OAuth.
3. If authentication succeeds and the refusal moves to MAIL FROM or RCPT TO, stop looking at

credentials - you have an authorisation problem.

What not to do

• Do not retry. A 5xx is permanent and the configuration will not change itself.
• Do not suppress the recipient. No recipient was involved.
• Do not turn off TLS to get AUTH accepted on a plaintext session. If it works, your

password is now crossing the network in the clear.

• Do not switch to port 25 because 587 is failing. Public MX hosts do not accept authenticated

submission, and the attempt looks like relay probing.

• Do not keep basic authentication alive with workarounds. The deprecation is one-way. Move

the mailbox to OAuth and the problem does not come back.

MailPilot connects Gmail and Outlook mailboxes over OAuth rather than stored passwords, which

removes causes three and five entirely, and it validates SMTP/IMAP credentials for SendGrid,

Amazon SES, Mailgun, Postmark and custom servers when you add the mailbox - so a disabled tenant

setting surfaces at setup instead of halfway through a warm-up ramp.