535 5.7.8 Username and Password not accepted

Problem

Your script, printer, CRM, or backup job that has quietly sent mail for years suddenly can’t log in: 535-5.7.8 Username and Password not accepted. You check the password. It’s right. You paste it again, carefully. Still rejected. Nothing about your credentials changed — but the rule for what counts as an acceptable credential did, and almost nobody sends an email announcing it. The password you’re sending is probably correct and no longer allowed, which is a maddeningly different problem from a typo.

Symptoms

• The SMTP server returns 535 5.7.8 Username and Password not accepted (Gmail’s full form points at https://support.google.com/mail/?p=BadCredentials), or the sibling 534 5.7.9 Application-specific password required.
• The exact same username and password work when you log into the web mail UI in a browser, but fail over SMTP/IMAP.
• It broke on a date, not gradually — often right after a provider deadline, or after someone enabled 2-Step Verification on the account.
• Automated senders (cron jobs, network scanners, MFPs, legacy apps) fail while people using modern mail clients are fine.

What this error actually means

The enhanced status code is the tell. Under RFC 3463, 5.7.8 decodes as permanent (5), security or policy (7), authentication credentials invalid (8). RFC 4954, the SMTP AUTH extension, is explicit: a 535 5.7.8 reply means authentication failed because the credentials were invalid or insufficient, and the client should ask the user for new ones. It is not a spam judgment, a blocklist, a full mailbox, or a DNS problem. The server understood your login attempt and refused it.

What makes 2026 different is that “invalid” now includes credentials that are technically correct. Providers spent years killing password-only authentication for third-party apps. Google removed the “less secure apps” toggle for personal Gmail on May 30, 2022, ended password-only access and Google Sync for Workspace on September 30, 2024, and completed the shutoff across all Workspace accounts through 2025. After each of those dates, the same password that worked the day before started returning 535 5.7.8, because the connection method — plain password over SMTP AUTH — stopped being an accepted method, independent of whether the password was right.

Top 3 Causes

1. You’re sending your account password where an App Password is required. The dominant case. The account has 2-Step Verification on (or the provider has retired password-only auth entirely), so your normal password is refused. The fix is a 16-character App Password: a per-application credential you generate once and paste in as the SMTP password. On Gmail this requires 2-Step Verification to be enabled first — there’s no App Password without it. When the server can be specific, it says so with 534 5.7.9 Application-specific password required.
2. 2-Step Verification isn’t set up at all, so you can’t create an App Password and password-only login is already blocked. This is the frustrating dead end: the account is on the modern security regime enough to reject your password, but not set up enough to issue the replacement. You have to enable 2-Step Verification on the account first, then generate the App Password.
3. The credential is fine, but something else about the login is wrong. Wrong username (the server wants the full [email protected], not user), wrong SMTP host or port, an auth mechanism the server doesn’t advertise, or an account that’s locked, suspended, or flagged for suspicious activity. Here 5.7.8 is telling the truth in the strict sense — the authentication didn’t succeed — but no App Password will fix it until you correct what you’re actually sending.

Diagnose with DechoNet

• Email Check can’t test your SMTP password — nobody outside your provider can — but it does the next most useful thing: it confirms, from the outside, that the domain resolves and its mail records (MX, SPF, DKIM, DMARC) are present and sane. That matters because 535 5.7.8 is easy to confuse with delivery failures that are DNS problems. If Email Check shows your mail domain is healthy, you’ve ruled out the whole DNS class of causes and confirmed the fight is where the error says it is — at authentication, on the client side — so you fix the credential instead of chasing your DNS.

Resolution Checklist

• Generate an App Password for the sending account and use it as the SMTP password, verbatim, no spaces. On Gmail/Workspace this is the fix for the overwhelming majority of 535 5.7.8 and every 534 5.7.9.
• If you can’t find where to create one, enable 2-Step Verification on the account first — App Passwords don’t exist without it.
• Prefer OAuth 2.0 (XOAUTH2) where the client supports it. Modern mail clients let you re-add the account with “Sign in with Google” instead of a stored password; it’s the path providers actually want you on, and it survives future password-auth shutoffs.
• Check the username format — most servers expect the full email address, not just the mailbox name.
• Confirm host, port, and encryption: for Gmail, smtp.gmail.com on 587 (STARTTLS) or 465 (SSL). A wrong port or a missing TLS mode can surface as an auth failure.
• If it still fails with a correct App Password, check for an account lock or a security alert in the account’s security page — a flagged account rejects even valid credentials.

When to Escalate

• If you’ve set an App Password, confirmed the username and host, and still get 535 5.7.8, sign in to the account’s web UI and look for a security prompt or a blocked-sign-in notice; the account itself may need a human to clear a flag.
• For Microsoft 365 / Exchange Online, basic SMTP AUTH is disabled by default and Microsoft is retiring it in favor of OAuth — a 535 there usually means SMTP AUTH is off for the tenant or the mailbox, which is an admin setting, not a password you can fix from the client.
• If the account is a shared or role mailbox that many systems authenticate against, treat a sudden 535 as possible credential rotation or a policy change on the provider side, and check with whoever administers the domain’s mail before re-trying in a loop — repeated failed logins can trip a lockout that makes everything worse.