SMTP error 530, what it means and what to do

Error 530 is defined as "Authentication required", and it arrives in two well-known costumes. The plain version means the server will not accept mail from a client that has not authenticated; the sender tried to relay anonymously. The second version carries the text "530 5.7.0 Must issue a STARTTLS command first", a Gmail-famous wording, meaning the server requires the connection to be encrypted before it will discuss anything else. Both are configuration mismatches, and both are fixed on the sender's side.

The fix, in order

  1. Read which 530 it is. If the text mentions STARTTLS, go to step 3. If it says authentication required or access denied, step 2 is the fix. The code is the same; the sentence chooses the repair.
  2. Turn on outgoing authentication in the client. In the account's outgoing (SMTP) server settings, enable "My outgoing server requires authentication" and use the same credentials as the incoming server (or the full-address username and current password). Sending through port 587 with authentication on is the standard configuration this error is asking for.
  3. Set the encryption to STARTTLS on port 587. For the STARTTLS variant, the client connected in plain text. Set the outgoing encryption method to STARTTLS (sometimes labeled TLS) with port 587, not SSL/TLS on 587; the implicit-SSL variant belongs to port 465. Mismatched pairs of port and encryption are the everyday cause.
  4. Remove port 25 sending from clients. Submitting through port 25 without authentication is what public servers are configured to refuse with 530. Any client still aimed at port 25 should be moved to 587 with authentication and STARTTLS.
  5. If you run the server and users get 530: check that the submission service is actually offering AUTH and STARTTLS (an EHLO response should list both), and that relay permissions grant authenticated users submission. A server that requires authentication but does not advertise a mechanism produces 530s nobody can satisfy.
  6. Test with a fresh EHLO. Tools aside, sending one small message after the settings change is the real test; if it goes through, both the authentication and encryption prerequisites are now met.

If it still happens

Sender-versus-server ownership for 530 is unusually clear: it is a prerequisite the receiving server publishes and the sending side has not met, so the fix lives in the sender's settings in nearly every case. The exception is a server that demands authentication while offering no working way to authenticate, which is a fault for the server's operator to repair.

Common questions

Why did 530 start appearing when nothing changed in my client? Providers periodically tighten requirements: disabling unauthenticated submission, or requiring STARTTLS where plain connections used to pass. The client did not change; the server's prerequisites did, and 530 is how the new rule announces itself.

Is 530 the same as 535? No. 530 means authentication has not happened (or encryption has not started). 535 means authentication was attempted and the credentials were rejected. 530 comes first in the conversation; 535 comes during it.

Related errors

SMTP error 535 · SMTP errors on port 587 · SMTP error 550