530 5.7.0: Authentication or STARTTLS required

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 530: “Authentication required” (RFC 4954 §6).
• Enhanced code 5.7.0: “Other or undefined security status” in the IANA registry (RFC 3463), in the group security or policy status (RFC 3463 §3.8).

A 530 5.7.0 reply means the server will not take your mail until your app signs in, or until it switches the connection to TLS. It is a setup problem in the sending app, printer, script or device, not a problem with the recipient.

What it means

RFC 4954 §6 defines 530 5.7.0 Authentication required. A server returns it to any command other than AUTH when its policy says clients must authenticate first. RFC 3207 §4 uses the same 530 code for 530 Must issue a STARTTLS command first, the reply a server gives when it wants an encrypted connection before anything else. The enhanced code 5.7.0 is the general security or policy status of RFC 3463 §3.8. The text after the code tells you which of the two the server wants.

Common causes

• The app has SMTP authentication turned off, or the username and password fields are empty.
• The app connects without TLS, and the server requires STARTTLS first.
• A device or script sends MAIL FROM straight away, before AUTH.
• After STARTTLS the app does not send EHLO again, so it never learns that AUTH is offered.

How providers use it

Gmail lists 530 5.7.0 for both cases: authentication required, and a STARTTLS command must come first (Google's SMTP error reference). Gmail also returns 523 5.7.10 when a client pipelines commands right after STARTTLS. Microsoft 365 reports an unauthenticated client on its submission server as 5.7.57.

How to fix it

1. In the app's outgoing mail settings, turn on authentication and enter the account's username and password (or app password).
2. Turn on TLS or STARTTLS in the same settings.
3. Check the order of commands if you wrote the client yourself: EHLO, STARTTLS, then EHLO again (RFC 3207 §4.2 says the client should, and must forget the extension list it got before TLS), then AUTH, then MAIL FROM.
4. Do not pipeline commands behind STARTTLS; wait for its reply.
5. Send a test message to yourself. If the server now answers 535 instead, the sign-in is reaching it but the credentials are wrong: see 535 5.7.8.
6. A device that cannot sign in at all (some older printers and scanners) needs another way to send. Ask your mail admin which relay options your provider offers.

Related codes

• 535 5.7.8: Username and password not accepted
• 5.7.57: Client not authenticated to send anonymous mail (Microsoft 365)
• 503 5.5.1: Commands sent in the wrong order

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.