SMTP server authentication error

An "SMTP server authentication error" is the generic name for any failure during the SMTP AUTH exchange — the step where your client proves its identity before being allowed to send mail. The server's actual response is what tells you why, so the first move is always to capture the real reply code and enhanced status code.

What does "SMTP server authentication error" mean?

SMTP authentication is defined by RFC 4954 (SMTP Service Extension for Authentication). After EHLO, the server advertises an AUTH line listing the mechanisms it supports (e.g. AUTH LOGIN PLAIN XOAUTH2). Your client picks one, sends credentials, and the server replies with a code. An "authentication error" is any non-235 reply to that AUTH command.

The most common one is 535 5.7.8 — "Authentication credentials invalid." But RFC 4954 defines a whole family of auth replies, and the enhanced status code (the 5.7.x part, per RFC 3463 and the IANA SMTP Enhanced Status Codes registry) tells you exactly which problem you hit:

• 235 — Enhanced: 2.7.0; Meaning (RFC 4954): Authentication succeeded; What it points to: Not an error
• 432 — Enhanced: 4.7.12; Meaning (RFC 4954): Password transition needed; What it points to: User must change/migrate password
• 454 — Enhanced: 4.7.0; Meaning (RFC 4954): Temporary auth failure; What it points to: Transient — retry later
• 504 — Enhanced: 5.5.4; Meaning (RFC 4954): Unrecognized/unsupported mechanism; What it points to: You asked for an AUTH method the server doesn't offer
• 530 — Enhanced: 5.7.0; Meaning (RFC 4954): Authentication required; What it points to: You tried to send before authenticating
• 534 — Enhanced: 5.7.9; Meaning (RFC 4954): Mechanism too weak; What it points to: Server policy requires a stronger mechanism
• 535 — Enhanced: 5.7.8; Meaning (RFC 4954): Invalid or insufficient credentials; What it points to: Wrong username/password or wrong credential type
• 538 — Enhanced: 5.7.11; Meaning (RFC 4954): Encryption required for the mechanism; What it points to: Historical code — see note below

The 4.x.x codes are temporary (retry); the 5.x.x codes are permanent (fix the config). Reading the code first saves you from blindly resetting a password when the real problem is, say, 530 (you need TLS before authenticating) or 504 (you picked an unsupported mechanism).

Note on 538: RFC 4954 Section 6 says this code is "documented here for historical purposes only" and that modern servers should not even advertise a mechanism that requires encryption it doesn't have — they should simply omit it from the AUTH line rather than let you attempt it and fail with 538. In practice, on a current mail server you're far more likely to hit 530 5.7.0 (auth required, i.e. no TLS yet) or a connection-level TLS failure than to ever see a literal 538.

How do I fix an SMTP authentication error?

1. Read the exact server reply. Don't troubleshoot "an auth error" — troubleshoot 535 5.7.8 or 530 5.7.0 specifically. In Nodemailer this surfaces as an EAUTH error whose responseCode and command (e.g. AUTH LOGIN, AUTH XOAUTH2) name the failing step (see the Nodemailer error reference).

2. Verify the credentials and the right kind of credential. A 535 almost always means the username/password is wrong — but for many providers the credential is not your account password:

• Gmail / Google Workspace: Google removed basic-password ("less secure apps") SMTP sign-in for personal Gmail in May 2022. For Google Workspace accounts, the cutover was a multi-stage rollout — announced for September 2024, delayed twice, and finally enforced on May 1, 2025, after which basic-password SMTP/IMAP/POP access stopped working entirely. You must either enable 2-Step Verification and generate a 16-character App Password, or use OAuth2 (AUTH XOAUTH2). Username is the full address; password is the App Password, not your normal one.
• SendGrid: The SMTP username is the literal string apikey and the password is an API key — Twilio/SendGrid's API key permissions documentation specifies Mail Send as the minimum scope needed for sending mail, not your SendGrid login. (SendGrid: 535 Authentication failed — confirm the key has full or Mail Send permissions.)
• Amazon SES: Use the SMTP credentials generated in the SES console, not your AWS IAM username/password — they are different strings, and they are Region-specific. (AWS: SES authentication credentials invalid.)

3. Use a mechanism the server actually advertises. If you get 504 5.5.4, your client requested an AUTH method (e.g. CRAM-MD5) the server doesn't list after EHLO. Match your client to the advertised list, or let the library negotiate automatically.

4. Authenticate over TLS. Many servers refuse AUTH on a plaintext connection and return 530 5.7.0. Connect with STARTTLS on port 587 or implicit TLS on port 465 — both are standards-compliant per RFC 8314; neither is deprecated. Don't disable TLS to "make auth work."

5. Distinguish temporary from permanent. A 454 4.7.0 is the server saying "try again later" (often rate-limiting or a transient backend issue) — back off and retry rather than rotating credentials.

S: 250-smtp.example.com Hello
S: 250-STARTTLS
S: 250 AUTH LOGIN PLAIN XOAUTH2
C: AUTH LOGIN
C: <base64 username>
C: <base64 password>
S: 535 5.7.8 Authentication credentials invalid   <-- wrong/incorrect credential

If you've confirmed the credential type, the TLS port, and a supported mechanism and still see 535, regenerate the credential at the provider (rotate the API key, create a new App Password, or re-issue SES SMTP credentials) — leaked or revoked secrets fail identically to mistyped ones.