A 535 response (often 535 5.7.8 "Username and Password not accepted" or "authentication failed") means the SMTP session and TLS were fine, but the server rejected your credentials during AUTH. It is an authentication problem, not a connection or relay problem—so changing ports or disabling the firewall will not help.
The most common cause is using a normal account password on an account that requires an app-specific password. Gmail, Microsoft 365, Yahoo, and others block basic password auth once 2-Step Verification is enabled and require a generated app password instead.
The second most common cause is pasting the wrong kind of secret. Many providers issue a separate SMTP credential that is distinct from their HTTP/REST API key: Mailgun (domain SMTP user), Brevo (SMTP key, not the v3 API key), and Postmark (Server API token used as both username and password). Others use a fixed username with the API key as the password: apikey for SendGrid, resend for Resend, SMTP_Injection for SparkPost.
To confirm it is really an auth failure, run the test in SMTP Tester and watch the transcript: a clean connect and STARTTLS followed by 535 right after the AUTH line points squarely at credentials. Because passwords are redacted, you can safely copy the transcript into a support ticket or forum post.
Checklist to fix a 535
- 2FA enabled? Generate and use an app password, not your login password
- Check the username format the provider expects (full email vs a fixed string like
apikey/resend/SMTP_Injection) - Use the SMTP credential, not the HTTP/REST API key, where they differ (Mailgun, Brevo, Postmark)
- Strip stray spaces or line breaks from a copied key or token
- Try AUTH PLAIN or LOGIN explicitly if Auto-detect fails
- Confirm the From/username domain is authorized for the account