535 5.7.8 Username and Password Not Accepted: Six Causes, and Only One Is the Password

Gmail's SMTP server returns 535 5.7.8 username and password not accepted at the exact moment your app hands over credentials, which is why almost everyone's first move is to retype the password. That move almost never works. The refusal happens during the AUTH command, but the reason usually sits in account settings, admin policy or the endpoint you connected to — not in the string you pasted.

There are six things that produce this bounce against Gmail and Google Workspace. Exactly one of them is a mistyped secret. The other five look identical from your application's log, which is what makes the error so expensive to debug: the same eleven words cover a missing app password, a revoked one, a dead OAuth token, a domain-wide policy change, a malformed username and a wrong hostname.

Reading the bounce line Gmail actually sent you

The full reply is longer than the part most people paste into a search box. It arrives as a multi-line SMTP response, with the status repeated on every line and a link to Google's BadCredentials page in the middle of it.

Three pieces are worth separating:

• 535 is the SMTP status class: authentication credentials are invalid. It is permanent, so no retry schedule helps.
• 5.7.8 is the enhanced status code — a security-and-policy failure, specifically "authentication credentials invalid". The leading 5 confirms permanence a second time.
• The trailing token before - gsmtp, something like d2sm1043284pfh.9, is Gmail's identifier for that one SMTP session. It is not an error code and it changes on every connection. It is the only part worth quoting to Google Workspace support, and the only part that is useless to search for.

Some libraries surface the reply mangled — 535 b5.7.8, or AuthenticationFailedException: 535 5.7.8, or just Password command failed. The wrapping differs by client; the underlying refusal does not.

Six causes, ranked by how often they turn out to be it

#	Cause	Tell-tale sign	Where you fix it
1	No app password exists because 2-Step Verification is off	The App passwords page is missing entirely	Google Account, Security
2	App password was revoked, or the account password changed	Worked for weeks, then stopped overnight	Google Account, Security, App passwords
3	OAuth refresh token expired or was invalidated	Token refresh returns invalid_grant, often exactly 7 days after setup	Google Cloud console, OAuth consent screen
4	Password-based SMTP is off for the whole domain	Personal Gmail works, the work account does not	Workspace Admin console
5	Username is not the full email address	Fails instantly on every account you try	Your app's SMTP config
6	Connected to the wrong Gmail endpoint	Credentials are right but the relay route rejects them	Your app's SMTP config

The ranking reflects what a working credential looks like when it breaks. Causes 1 and 2 dominate new setups and long-running scripts respectively; 3 catches teams who did the "right" thing and used OAuth; 4 catches anyone on a managed domain; 5 and 6 are configuration slips that fail on the first attempt and never intermittently.

The app password that cannot exist, and the one that quietly stopped existing

An app password is a sixteen-character secret that replaces your Google password for a single client. It has one hard prerequisite: Google's app password documentation states that you need 2-Step Verification on the account before the option appears at all. If 2SV is off, there is no App passwords page to visit — which is why so many people conclude the feature was removed. It was not removed; it was never available to that account.

Two further conditions block it even with 2SV switched on:

• The account uses security keys only for its second factor.
• The account is enrolled in Advanced Protection, or an administrator has restricted the option on a work or school account.

The revocation case is more annoying because it breaks something that used to work. An app password dies when:

• Someone deletes it from the App passwords screen.
• The account's main Google password is changed, which invalidates app passwords issued before the change.
• The account's 2-Step Verification is turned off and back on.

Two practical details cause needless rounds of retyping. Google displays the secret in four groups of four with spaces for legibility; the spaces are not part of the password, and some SMTP libraries pass them through literally. Strip them. And an app password cannot be viewed again after it is created, so a lost one is regenerated, never recovered.

OAuth refresh tokens carry a seven-day fuse in testing mode

Teams that skip app passwords for OAuth 2.0 hit 535 5.7.8 in a different way: the access token presented over XOAUTH2 is stale because the refresh token behind it stopped working.

Google's OAuth 2.0 documentation lists the conditions, and the first one accounts for most surprise failures a week after launch:

• A Cloud project whose OAuth consent screen is set to external user type with a publishing status of Testing is issued a refresh token that expires in 7 days. Publish the app, or keep it internal, and the fuse goes away.
• The user revoked the app's access.
• The token went six months without being used.
• The user changed their Google password and the token carries Gmail scopes.
• The account hit the limit of 100 refresh tokens per Google Account per OAuth client ID; older tokens are invalidated as new ones are issued.
• An administrator restricted a service the app requests.

A refresh attempt that returns invalid_grant and an SMTP session that returns 535 5.7.8 are the same failure seen from two levels of the stack. If your app logs only the SMTP side, you will spend the debugging session in the wrong place.

Your domain may have switched off password logins in 2024

This is the cause almost no troubleshooting post covers, and it is the one that makes a previously working integration fail for an entire company at once.

Google retired password-only access to Gmail on a published timeline. Per the Workspace Updates announcement, the less secure apps settings were removed from the Admin console on June 15, 2024, and remaining password-based IMAP, POP, SMTP, CalDAV and CardDAV access ended on September 30, 2024. Google's stated preference in that announcement is OAuth, with app passwords named as the fallback for devices such as scanners that cannot do OAuth.

What this means in practice for a Workspace domain:

• There is no longer a toggle an admin can flip to allow a plain account password over SMTP. That path is closed permanently.
• App passwords remain the password-shaped option, and they depend on 2SV being permitted for that user by policy.
• If your admin enforces security keys, or blocks app passwords for the organisational unit your account sits in, your only route is OAuth. No amount of credential regeneration will change the answer.

The fast diagnostic: run the identical code against a personal gmail.com account with a fresh app password. If the personal account authenticates and the work account does not, the problem is policy, and the next conversation is with your Workspace admin rather than with your code.

The username form: full address, not the part before the @

Gmail's SMTP AUTH expects the complete address as the username, so alice@yourdomain.com rather than alice. The forms that get rejected:

• The local part alone, with no domain.
• An alias that is not the account's primary address and has not been added as a send-as identity.
• A group or shared-mailbox address paired with an individual's password.
• A domain alias address where the account is registered under the primary domain.

This failure is consistent rather than intermittent: it never works once and breaks later. If the error appeared on the very first attempt of a brand-new integration, check this before touching anything else, because it costs ten seconds to rule out.

smtp.gmail.com and smtp-relay.gmail.com are different doors

These two endpoints accept different credentials and enforce different rules, and mixing them produces authentication failures that look exactly like bad passwords.

smtp.gmail.com is the per-user path: port 587 with STARTTLS or 465 with SSL, authenticated as one mailbox and sending as that mailbox.

smtp-relay.gmail.com is the Workspace relay, configured by an administrator in the Gmail routing settings. Google's SMTP relay documentation describes the parts that matter here:

• Allowed senders is set to one of three values: registered Workspace users only, any address in your domains, or any address at all.
• Authentication is by IP allowlist, SMTP authentication, or both. If the route was configured for IP allowlist only, correct credentials presented from an unlisted address still fail.
• SMTP authentication on the relay requires a TLS connection, on smtp-relay.gmail.com port 587.
• Capacity is organisation-wide: 4.6 million recipients per 24 hours, 319,444 per rolling 10 minutes, with 10,000 messages per user per day and 100 recipients per individual SMTP transaction.

Two mixups account for most relay-related 535s. Pointing an app at smtp-relay.gmail.com when no relay route exists for the domain leaves nothing to authenticate against. Pointing it at smtp.gmail.com with credentials that only the relay route recognises produces the same eleven words.

A ten-minute order of checks

Work down this list and stop at the first failure. It is ordered by cost rather than by likelihood, so the cheap eliminations come first.

1. Read the username. Is it the full email address? Fix and retest before anything else.
2. Read the host and port. smtp.gmail.com on 587 with STARTTLS, or 465 with SSL. If it says smtp-relay, confirm with your admin that a relay route exists and how it authenticates.
3. Check for spaces in the app password your config actually loads. Print its length; it should be 16 characters.
4. Open the Google Account security page. If there is no App passwords section, 2-Step Verification is off or policy blocks it. That is your answer.
5. Generate a fresh app password and test with it directly, not through your deployment pipeline's secret store. This separates a bad credential from a stale secret in your environment.
6. If you use OAuth, log the refresh response, not only the SMTP error. An invalid_grant plus a consent screen in Testing status plus an integration that worked for exactly a week is the seven-day expiry.
7. Test the same code against a personal Gmail account. Works there and not on the work domain means admin policy.

When Gmail SMTP is the wrong tool for the job

Gmail's SMTP endpoint is built for a person's mailbox, and it behaves like one. Credentials are tied to a human account, they stop working when that human changes their password, and they disappear when the account is offboarded. The relay is better suited to application sending but requires admin configuration and inherits the domain's policies.

Once an application is sending on a schedule — receipts, notifications, campaigns — the authentication problem is worth designing away rather than debugging repeatedly. A dedicated sending service issues an API key that belongs to the application rather than to a person, does not depend on anyone's 2FA setup, and does not stop working because someone rotated a password on a Friday afternoon.

Frequently asked questions

Why does 535 5.7.8 happen even though my password is correct?

Because the error is Gmail refusing the AUTH command, not a character-by-character verdict on your string. Five of the six causes — a missing or revoked app password, an expired OAuth refresh token, domain policy, a username that is not the full email address, and the wrong SMTP endpoint — all produce exactly the same message as a genuinely wrong password.

Can I still use my normal Gmail password for SMTP?

No. Google removed the less secure apps settings from the Admin console on June 15, 2024 and ended remaining password-based SMTP, IMAP, POP, CalDAV and CardDAV access on September 30, 2024. Your options now are an app password or OAuth 2.0.

Why is there no App passwords option in my Google Account?

App passwords require 2-Step Verification on the account, so the page does not appear at all when 2SV is off. It is also unavailable when the account's only second factor is a security key, when Advanced Protection is enrolled, and when a work or school administrator has restricted it.

My OAuth setup worked for a week and then stopped. What happened?

A Google Cloud project with an external OAuth consent screen in Testing publishing status is issued a refresh token that expires after seven days. Moving the consent screen to published, or making the app internal, removes that expiry.

Should I use smtp.gmail.com or smtp-relay.gmail.com?

Use smtp.gmail.com on port 587 with STARTTLS or 465 with SSL when you are authenticating as a single mailbox. Use smtp-relay.gmail.com on port 587 only when a Workspace administrator has configured a relay route for your domain, since the relay applies its own allowed-senders rule and may authenticate by IP allowlist rather than credentials.