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, disabling firewalls, 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 — nothing else. Because SMTP Tester redacts passwords and AUTH payloads, you can safely copy the full transcript into a support ticket, forum post, or team chat for help.

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.
• 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 and being phased out. 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 technically valid — it is valid for the wrong interface.

3. Wrong username format

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

• Gmail/Workspace: full email ([email protected])
• SendGrid: the literal word apikey
• Mailgun: [email protected] or another SMTP user you created for that domain
• Amazon SES: a 20-character SMTP username (not your IAM access key ID)

4. Truncated or mangled password

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

• Trailing newline or space after pasting.
• Password field has a character limit that silently truncates.
• Multi-line paste in a terminal breaks the key.
• Config file quoting ("...") that strips backslashes or special characters.

Fix: paste into a plain-text editor first, 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, try setting 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).

Less common causes

Account suspended or locked

If the account was disabled for abuse, billing, or inactivity, auth will fail. Check your provider dashboard for alerts.

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.

Rate-limited authentication

After too many failed AUTH attempts, some servers temporarily block further attempts from your IP. Wait 15–60 minutes before retrying with corrected credentials.

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 your Microsoft 365 admin center for the "SMTP AUTH" policy.

Checklist to fix a 535

1. Is 2FA enabled? → Generate and use an app password.
2. Check the username format (full email vs fixed string vs SMTP user ID).
3. Use the SMTP credential, not the REST API key, where they differ.
4. Strip stray spaces or line breaks from the pasted password.
5. Confirm the full password length was copied (no truncation).
6. Try AUTH PLAIN or LOGIN explicitly if Auto fails.
7. Verify the account is active and not locked.
8. Check IP allowlists if the provider enforces them.
9. Read the transcript in SMTP Tester — the 535 line often includes a hint (e.g., "application-specific password required", "basic authentication is not allowed").

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 with corrected credentials.
• 530 5.7.0 "Authentication required": not a failed auth — the server requires AUTH before it will accept mail, 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. This is a relay policy issue, not auth.