SMTP Error 535

SMTP error 535 is the server's response to the AUTH command. Per RFC 4954 §6 it is defined as 535 5.7.8 Authentication credentials invalid — "this response to the AUTH command indicates that the authentication failed due to invalid or insufficient authentication credentials." The RFC adds that on receiving 535 "the client SHOULD ask the user to supply new credentials." It is a permanent (5.x.x) failure: the username/password (or API key/token) you presented was not accepted. It is not a recipient, DNS, or content problem.

You will most often see it as a full text line such as 535-5.7.8 Username and Password not accepted (Gmail) or 535 Authentication failed (SendGrid, SES).

What causes SMTP error 535?

The X.7 "Security or Policy Status" class and its numbering scheme originate in RFC 3463 (which itself only defines codes through X.7.7); RFC 5248 later established the actual IANA registry for these enhanced status codes, and RFC 4954 registered 5.7.8 Authentication credentials invalid in that registry. Either way, it signals a security/authentication failure. Distinct, common triggers:

• Wrong or stale username/password. Credentials are case-sensitive; the username is usually the full email address, not the local part.
• Basic password auth no longer allowed. Google removed the "Less Secure Apps" toggle for personal Gmail accounts in 2022, and separately phased out legacy password-based SMTP/IMAP/POP authentication for Google Workspace, with full enforcement completing March 14, 2025 — a raw account password will return 535 even when correct.
• Wrong credential type for the provider. Using an AWS IAM access key with Amazon SES, or your real password instead of an API key with SendGrid, fails authentication even though the value is valid elsewhere.
• 2-Step Verification enabled without an App Password / OAuth2.
• Whitespace or newlines in the credential. SMTP is line-oriented; a stray linefeed inside a base64-encoded API key breaks the AUTH exchange (SendGrid documents this explicitly).
• Region mismatch. Amazon SES SMTP credentials are valid only in the Region that generated them.
• TLS too old. Some providers (e.g. SendGrid) require TLS 1.2+; an older client can surface as a 535.

Note: 535 is authentication invalid. If you instead saw 530 5.7.0 (auth required) you skipped AUTH entirely; 534 5.7.9 (mechanism too weak) or 538 5.7.11 (encryption required) point at the wrong mechanism/encryption rather than bad credentials. Enhanced code 5.7.8 is most commonly paired with basic code 535, though some servers may report it alongside 554.

How do I fix SMTP error 535?

Start by confirming which mail service you authenticate against, then apply the matching fix.

Gmail / Google Workspace — Do not re-enable "Less Secure Apps" (it no longer exists). Enable 2-Step Verification, then create an App Password and use it as the SMTP password with your full address as the username. On Google Workspace, App Passwords may be disabled by your admin (Admin Console → Security → Authentication → 2-Step Verification); if the App Passwords option is missing, or you administer many accounts, use OAuth2 / XOAUTH2 instead — Google now recommends OAuth2 as the primary method for Workspace, not just for server-to-server sending. Host smtp.gmail.com, port 587 (STARTTLS) or 465 (implicit TLS) — both are valid per RFC 8314.

SendGrid — Set the username to the literal string apikey (not your email) and the password to the full API key. Per SendGrid's 535 guide, ensure no whitespace/newlines crept into a base64-encoded key, that ports 25/587/465/2525 aren't blocked, and that your client negotiates TLS 1.2+.

Amazon SES — Use credentials generated in the SES console ("Create SMTP credentials"), not your IAM access key/secret. Connect to the same Region the credentials were created in. See AWS's SMTP troubleshooting guide.

Generic verification — Reproduce the AUTH exchange manually to isolate the credential from your app:

$ openssl s_client -connect smtp.example.com:587 -starttls smtp
EHLO test
AUTH LOGIN
<base64 username>
<base64 password>

A 235 2.7.0 Authentication Succeeded confirms the credentials are good and the problem is in your application config; a repeat 535 confirms the credential itself is rejected.