Generic SMTP
535 5.7.8 — SMTP authentication credentials invalid
535 5.7.8
535 5.7.8 is the standard SMTP reply for "authentication credentials invalid", defined in RFC 4954. Your mail client, website or app tried to log in to its outgoing (SMTP) server and the server refused the credentials. No message was sent. This is a login problem, not a deliverability or DNS problem, so fixing SPF, DKIM or DMARC won't change it.
How to fix it
- 1
Use an app password where the provider requires one
Providers such as Google don't accept your normal account password for SMTP once 2-step verification is on. Create an app password in the account's security settings and use it in the SMTP settings instead.
- 2
Check the username format
Most providers expect the full email address as the SMTP username, not just the part before the @. Check for stray spaces, and for special characters in the password that your config file or environment variable may be escaping.
- 3
Confirm SMTP login is allowed for the mailbox
Some providers turn SMTP authentication off for an account or an organization, or require OAuth instead of passwords. Microsoft 365, for example, reports its own SMTP AUTH failures with different codes, such as 535 5.7.139, when authenticated SMTP is disabled. Check the provider's settings for the mailbox.
- 4
Check the server, port and encryption
Use the provider's documented submission settings, usually port 587 with STARTTLS or port 465 with TLS. Credentials for one provider sent to another provider's server will always fail.
- 5
Check whether the account is locked
Repeated failed logins, a password change, or a security block on the account can make correct-looking credentials fail. Sign in to webmail to see whether the provider is asking for verification.
Meaning current as of 2026-10-24, cross-checked against the provider's own documentation. Providers do occasionally redefine codes — if this doesn't match what you're seeing, the source link is the authoritative reference.