clement
Try free for 14 days

530 5.7.0: Authentication required

Your client tried to send without logging in (or without STARTTLS first), and the server requires both.

Bounce type
Hard bounce (permanent)
What to do
Fix your setup, keep the contact
Returned by
Gmail / Google Workspace; Any mail server

What 530 5.7.0 means

530 is 'Authentication required' and 5.7.0 is the generic security status. The server needs you to authenticate before it accepts MAIL FROM, and your client skipped that step. Gmail also uses 530 5.7.0 'Must issue a STARTTLS command first' when a client tries to proceed without encrypting the connection.

This is a configuration problem with your outgoing server settings; recipients are not involved.

What the bounce looks like

The wording providers document for this code. Your bounce may add an IP address, a session ID or a help link after it.

Gmail
530 5.7.0 Authentication required.
Gmail
530 5.7.0 Must issue a STARTTLS command first.

Why cold emailers see 530 5.7.0

  • SMTP authentication turned off in your client or sending tool's settings.
  • Connecting on port 587 without STARTTLS, or using the wrong port/security combination (587 uses STARTTLS, 465 uses implicit TLS).
  • Trying to submit mail to a provider's MX server (port 25) instead of its submission server.

How to fix 530 5.7.0

  1. Use the provider's submission host (e.g. smtp.gmail.com), port 587 with STARTTLS or 465 with SSL/TLS, and enable authentication.
  2. Enter the full email address as the username and the correct password, app password or OAuth.
  3. Send a test message after saving the settings.
  4. If your tool has a 'use the same credentials as IMAP' option, make sure the IMAP login itself works first.

Retry or suppress?

Don't suppress anyone. Fix your SMTP settings and resend.

Reading the code

The basic code 530 means "Authentication required" under RFC 5321. In 5.7.0, the 5 is the class (permanent failure) and the 7 is the subject (security or policy). The detail number 0 is registered in RFC 3463 / the IANA registry as "Other or undefined security status".

Class 5
Permanent failure
Resending the same message won't work. Something about the message, the recipient or the sender has to change first.
Subject 7
Security or policy
A security or policy decision: spam filtering, authentication, blocklists, permissions.
Detail 5.7.0
Other or undefined security status

Check the rest of your setup

Paste the headers of a message that did get through into the email header analyzer to confirm SPF, DKIM and DMARC pass, and check your domain with the SPF, DKIM & DMARC checker. The deliverability checklist covers the rest of a healthy sending setup.

Got a different bounce? Paste it into the SMTP error code lookup to decode it.

FAQ

Is 530 5.7.0 a hard bounce or a soft bounce?

530 5.7.0 is a permanent failure (a hard bounce): the receiving server won't accept this message if you send it again unchanged. But the cause is not the recipient's address, so treat it differently from a 'user unknown' bounce.

Should I remove the contact after a 530 5.7.0 bounce?

No. Don't suppress anyone. Fix your SMTP settings and resend.

What does 5.7.0 mean in the error code?

In 5.7.0, the 5 is the class (permanent failure) and the 7 is the subject (security or policy). The detail number 0 is registered in RFC 3463 / the IANA registry as "Other or undefined security status".

Related SMTP codes

See all SMTP error codes

Sources

Try Clement free for 14 days

Clement reads the bounces that land in your Gmail and SMTP inboxes and tells dead addresses apart from policy blocks: it suppresses the first across every campaign and keeps the contact on the second, so you don't have to decode bounces by hand.

Start free trial