Amazon SES 530 authentication required

Amazon SES returns 530 Authentication required when your client opens a connection to the SES SMTP interface but tries to send mail without authenticating first. AWS describes this code precisely: "The application that you use to send email didn't attempt to authenticate when it connected to the Amazon SES SMTP interface." In other words, no AUTH command was issued before MAIL FROM.

This is the key distinction that most guides get wrong: 530 is not the "wrong password" error. If your username/password were wrong, SES returns 535 Authentication Credentials Invalid instead. A 530 means SES never received credentials at all.

What causes Amazon SES 530 Authentication required?

SES requires SMTP authentication on every session. RFC 4954 §6 specifies that a 530 5.7.0 reply "SHOULD be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT when server policy requires authentication... and authentication is not currently in force." Common reasons SES sees no authentication:

• SMTP auth is disabled in your client/library. The connection is opened but AUTH LOGIN/AUTH PLAIN is never sent (e.g., Nodemailer without an auth block, smtplib without login(), a Postfix relay missing smtp_sasl_auth_enable = yes).
• You hit the wrong endpoint. The SES inbound/receiving endpoint and the console are not the SMTP sending endpoint. Sending mail must go to email-smtp.{region}.amazonaws.com. Pointing a relay at the wrong host can yield a 530 because that listener expects authenticated submission.
• AUTH was attempted before TLS on a STARTTLS port. Like most SMTP AUTH servers, SES is expected not to offer the AUTH verb until the session is TLS-secured. If your client skips STARTTLS (port 587) or doesn't wrap the socket in TLS (port 465), the AUTH verb is never offered and the client proceeds unauthenticated.
• Credentials are empty/blank. If the username or password resolves to an empty string (a missing env var), many clients silently skip the AUTH exchange entirely rather than fail.

How do I fix Amazon SES 530 Authentication required?

1. Turn on SMTP authentication in your client. This is the actual fix for 530. Make sure your code or relay is configured to send credentials. Example with Nodemailer:

const transport = nodemailer.createTransport({
  host: "email-smtp.us-east-1.amazonaws.com",
  port: 587,
  secure: false,      // STARTTLS will be negotiated on 587
  requireTLS: true,   // refuse to send if TLS can't be established
  auth: {
    user: process.env.SES_SMTP_USERNAME, // SES SMTP user, NOT AWS access key
    pass: process.env.SES_SMTP_PASSWORD, // SES SMTP password, NOT AWS secret key
  },
});

For Postfix relays, set smtp_sasl_auth_enable = yes and point smtp_sasl_password_maps at your SES SMTP credentials.

2. Use real SES SMTP credentials. Per AWS, "Your SMTP password is different from your AWS secret access key." Generate SMTP credentials in the SES console under SMTP settings → Create SMTP credentials, or derive them from an IAM secret key using AWS's documented HMAC-SHA256 conversion script. These credentials are also per-Region — generate a separate set for each AWS Region you send from.

3. Connect over TLS so AUTH is offered. SES only accepts authentication on a secured connection. Use port 587 with STARTTLS or port 465 with implicit TLS (both are valid; ports 2587/2465 are alternates if 587/465 are blocked). Verify the channel before sending:

openssl s_client -connect email-smtp.us-east-1.amazonaws.com:465 -crlf
# or, for STARTTLS:
openssl s_client -starttls smtp -connect email-smtp.us-east-1.amazonaws.com:587 -crlf

After the handshake, an EHLO should list 250-AUTH PLAIN LOGIN. If it does and you still get 530, your client is not sending the AUTH command.

4. Confirm you're sending in the right Region. Because SMTP credentials are Region-scoped, credentials generated for us-east-1 will not authenticate against the eu-west-1 endpoint. Match your endpoint host's Region to the Region the credentials were created in.

Note that 530 is purely about whether you authenticated. Once auth succeeds, separate issues — unverified sender identity (554 Email address is not verified) or IAM permissions (554 ... not authorized to perform ses:SendRawEmail) — are reported with their own codes.