SMTP authentication checker — fix error 535

A 535 response (typically 535 5.7.8 "Username and Password not accepted" or 535 Authentication credentials invalid) means the SMTP session connected, EHLO and STARTTLS succeeded, but the server rejected your credentials during the AUTH command. It is an authentication problem, not a connection or relay issue. Changing ports or switching TLS modes will not help because those steps already passed.

How to confirm it is a 535

Run your test in SMTP Tester and read the live transcript:

1. Look for a successful 220 greeting (connection is fine).
2. Confirm 250 responses after EHLO (server capabilities exchanged).
3. If using STARTTLS, look for 220 Ready to start TLS (encryption is fine).
4. The AUTH PLAIN or AUTH LOGIN command appears, followed immediately by 535.

If the transcript shows these steps clearly, your issue is credentials. Because SMTP Tester redacts passwords and AUTH payloads, you can safely paste the transcript into a support ticket or team chat.

What AUTH looks like on the wire

Understanding the wire format explains a class of 535 errors that have nothing to do with wrong credentials. SMTP AUTH (RFC 4954) sends credentials as base64, and the two common mechanisms differ in how much goes out at once.

AUTH PLAIN sends the username and password in a single base64 string in one command:

C: AUTH PLAIN AGpvaG5AZXhhbXBsZS5jb20Ac2VjcmV0MTIz
S: 235 2.7.0 Accepted

The decoded payload is three NUL-separated fields: authorization-id NUL authentication-id NUL password. Servers ignore the authorization ID, so clients send an empty first field.

AUTH LOGIN is a two-step prompt. The server asks for the username, then the password; the client answers each with a separate base64 line:

C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: am9obkBleGFtcGxlLmNvbQ==
S: 334 UGFzc3dvcmQ6
C: c2VjcmV0MTIz
S: 235 2.7.0 Accepted

The 334 responses are base64 too: VXNlcm5hbWU6 decodes to Username: and UGFzc3dvcmQ6 to Password:.

Why a trailing newline or space breaks auth

Base64 decodes the entire line you send. If your password variable contains a trailing newline (from a shell heredoc or a read command), the client base64-encodes secret123\n instead of secret123. Those are different byte sequences, so the server computes a different hash and returns 535 even though the password on screen looks correct. The same applies to a trailing space from a copy button, a carriage return (\r) from a Windows-edited config file, and quoting that preserves whitespace.

A quick check in a terminal: printf '%s' "$SMTP_PASS" | wc -c shows the exact byte count, including invisible characters. Compare it to the length in the provider dashboard.

Auth-related SMTP response codes

A 535 is one member of a family of AUTH responses. The exact code tells you which layer failed:

Two of these are easy to confuse with 535:

• 530 means you never attempted authentication; the session went from EHLO straight to MAIL FROM. Enable auth in your client.
• 534 on Gmail (5.7.9 Application-specific password required) means the server recognizes your account but rejects your normal password while 2-Step Verification is on. The fix is an app password.

If your test fails before AUTH entirely, the problem is at a different layer. See what an SMTP test covers and port 587 vs 465 if the failure is in TLS negotiation.

Most common causes

1. Missing app password (2-Step Verification)

Gmail, Microsoft 365, Yahoo, and iCloud block basic password authentication once 2-Step Verification (2FA) is enabled on the account. They require a generated app-specific password instead of your normal login password.

• Gmail: Google Account → Security → App passwords. Select Mail, generate a 16-character password.
• Microsoft 365 / Outlook.com: Security → Additional security options → App passwords. Tenant admins can also disable SMTP AUTH per-mailbox, in which case no password works and OAuth2 is required.
• Zoho: Account → Security → App Passwords; see the Zoho SMTP test guide for regional hosts.
• Yahoo: Account Info → Security → Generate app password.

If 2FA is not enabled, the normal password may still work (Google calls this "less secure app access"), but this is deprecated. Use app passwords regardless.

2. Wrong credential type (API key vs SMTP password)

Many providers issue separate credentials for their REST API and SMTP interface; using the wrong one causes 535:

If you paste a REST API key into the SMTP password field (or vice versa), you get 535 even though the credential is valid, just for the wrong interface. Keys with the wrong scope fail the same way: a SendGrid key without Mail Send permission fails SMTP auth like an invalid key.

3. Wrong username format

Some providers require the full email address; others expect a fixed string or account-specific ID:

• Gmail/Workspace: full email (you@gmail.com), not you
• SendGrid: the literal word apikey
• Resend: the literal word resend
• Mailgun: postmaster@your-domain.com or another SMTP user for that domain
• Amazon SES: a generated SMTP username from the SES console, not your IAM access key ID; see the Amazon SES SMTP test guide
• Zoho: full email address, sometimes with a region suffix

Providers in the "literal string" family (SendGrid, Resend, SparkPost) confuse people most. The username never changes; all identity is carried by the key in the password field. Pasting your account email into the username field for one of these gets you 535 every time.

4. Truncated or mangled password

Long API keys (SendGrid keys are ~69 characters, SES SMTP passwords are ~44) get truncated when copy-pasted across terminals, email clients, or config files. Common issues:

• Trailing newline or space after pasting (which breaks the base64 payload as described above).
• Password field with a character limit that silently truncates.
• Multi-line paste in a terminal breaking the key.
• Config file quoting ("...") that strips backslashes or special characters.
• Shell interpolation: an unescaped $ or backtick gets expanded before the client sees it.

Fix: paste into a plain-text editor, confirm the full length, then copy into your SMTP client.

5. Wrong auth method

Some servers support only specific AUTH mechanisms:

• KumoMTA: AUTH PLAIN only (LOGIN will fail).
• Older Exchange: may require AUTH LOGIN (PLAIN not advertised).
• Some shared hosting: CRAM-MD5 only.

If Auto-detect fails, set the auth method explicitly in SMTP Tester to match what the server advertises in its EHLO response (look for 250-AUTH PLAIN LOGIN or similar in the transcript). If the server advertises no AUTH line at all, it does not accept authentication on that port and no credentials will work.

Less common causes

Account suspended or locked

If the account was disabled for abuse, billing, or inactivity, auth will fail with 535 even though the credentials are correct. Some providers return a generic "credentials invalid" for locked accounts so attackers cannot probe account status. Check your provider dashboard for alerts and confirm the account has not exceeded its sending quota.

IP-based restrictions

Some providers (Mailgun, enterprise setups) restrict SMTP access to whitelisted IPs. Even with correct credentials, connections from non-whitelisted IPs get 535. Add your IP to the allowlist in the provider's settings, and remember: if you test from a laptop on one network and your app runs from a server or CI environment on another, the allowlist that works in one place fails in the other.

Rate-limited authentication

After too many failed AUTH attempts, some servers temporarily block further attempts from your IP. The response may be a 454 or a 535 with "too many invalid login attempts" in the text. This is where debugging goes wrong: you fix the credential problem, retry, and still fail because the temporary block is active. Wait 15–60 minutes before retrying.

OAuth2 required

Microsoft 365 is deprecating basic auth for SMTP in favor of OAuth2 (XOAUTH2). If basic auth is disabled for your tenant, no username/password combination will work; you need an OAuth2 token. Check the "SMTP AUTH" policy in your admin center; it can be disabled tenant-wide or per-mailbox.

A debugging checklist, cheapest first

Work down this list in order; most 535s are resolved before step 5.

1. Read the transcript. Confirm the failure is at AUTH (535/534), not earlier. Providers often embed a hint in the text.
2. Check whitespace. Re-enter the password by hand or trim the variable. Costs 30 seconds, fixes many cases.
3. Verify the username format against the tables above. For SendGrid, Resend, and SparkPost that means a literal string.
4. Confirm credential type. SMTP credential vs REST API key vs key with the wrong scope.
5. Generate an app password if 2FA is on (Gmail, Microsoft, Zoho, Yahoo, iCloud).
6. Pin the auth mechanism to what the EHLO response advertises.
7. Check account state: active subscription, not locked, not out of quota.
8. Check IP allowlists and test from the network that will send production mail.
9. Wait out any auth rate limit, then retry once.
10. Reset the credential entirely. If a brand-new credential fails from a clean client, the problem is policy (IP block, tenant policy, account state).

Related errors

• 534 5.7.9 "Application-specific password required": same root cause as 535; 2FA is on, use an app password.
• 454 4.7.0 "Too many login attempts": rate-limited. Wait and retry.
• 530 5.7.0 "Authentication required": not a failed auth; the server requires AUTH and you did not attempt it. Enable authentication in your client.
• 550 "Relay denied": auth may have succeeded (check for 235 earlier in the transcript) but the recipient domain is not permitted. A relay policy issue, not auth.

Provider-specific fixes

A 535 is the same failure everywhere, but the correct credential differs per provider. Check the guide for yours before retrying:

• Gmail SMTP test: App Passwords are required when 2-Step Verification is on
• Outlook / Microsoft 365 SMTP test: tenant SMTP AUTH policy and app passwords
• SendGrid SMTP test: the username is the literal string apikey
• Zoho SMTP test: app-specific passwords and regional hosts
• Brevo SMTP test: SMTP keys, not API keys
• Mailgun SMTP test: per-domain SMTP users, not API keys
• Amazon SES SMTP test: SES-generated SMTP credentials, not IAM keys

Frequently asked questions

Does 535 always mean the password is wrong?

No. It means the server rejected the authentication attempt. The password may be correct but the wrong type (API key vs SMTP key), the account may be locked or out of quota, your IP may not be allowlisted, or the tenant may have disabled basic auth. The transcript's message text usually distinguishes these.

Why does my password work in one client but fail in another?

Whitespace and encoding. Some clients trim input fields; others send exactly what you typed, including a trailing space or newline. Config loaders differ too: some strip quotes from dotenv values, some keep them. Compare the credential's byte count in both places.

Can I use my normal Gmail password for SMTP?

Only if 2-Step Verification is off and "less secure app access" is still allowed, which Google is phasing out. With 2FA on, you must use a 16-character app password; the account password never works for SMTP once 2FA is enabled.

What is the difference between 530 and 535?

530 means you did not authenticate at all; the server required AUTH before MAIL FROM and none was attempted. 535 means authentication was attempted and the credentials were rejected. If you see 530, fix your client configuration.

Why does the transcript show base64 gibberish instead of my username?

AUTH transmits credentials base64-encoded, so the transcript shows encoded strings during the exchange. SMTP Tester redacts these payloads (and passwords) before display, so a 334 prompt followed by a redacted line is expected.

I fixed the credentials but still get 535. What now?

You may be inside a temporary auth rate limit from the earlier failed attempts, or behind an IP allowlist that does not include your test network. Wait, then retest from the network that will send production mail. If a fresh credential still fails from a clean client, the cause is account or policy state.