# Gmail SMTP 535 5.7.8: Username and Password not accepted

> Gmail returns 535 5.7.8 when the credentials your app sends are refused: a plain account password, a wrong app password, or no OAuth token. Here is the fix.

- Published: 2026-11-08
- Author: Koltrix Team
- Category: Email API
- Source: https://koltrix.com/blog/gmail-smtp-535-5-7-8-username-and-password-not-accepted

Your app connected to Gmail, tried to log in, and got `535-5.7.8 Username and Password not accepted`. The server is saying the login itself was refused, not that the message was bad. Almost always the cause is the kind of credential: Google no longer accepts a normal account password from a script or device, so you need an app password, Google's SMTP relay service, or OAuth.

**A 535 5.7.8 is an authentication failure, and it happens before any mail is sent.** The code comes from the SMTP authentication extension, which defines 535 as "authentication credentials invalid" ([RFC 4954](https://www.rfc-editor.org/rfc/rfc4954)). Nothing was queued, nothing bounced later, and retrying the same login will fail the same way.

## What does the error look like?

Gmail's version usually reads like this, with a link to a Google help page at the end:

```text
535-5.7.8 Username and Password not accepted. For more information, go to
535 5.7.8  https://support.google.com/mail/?p=BadCredentials
```

Libraries wrap it differently (`SMTPAuthenticationError` in Python, `Invalid login` in Nodemailer, `AuthenticationFailedException` in Java), but the numbers are the same. For the general format of these codes, see [SMTP enhanced status codes](/blog/smtp-enhanced-status-codes).

## Why does Gmail reject the login?

Check these in order, because the first two cover most cases.

| Cause | How to recognize it | Fix |
| --- | --- | --- |
| You sent the normal account password | It worked years ago, or works in the browser | Stop using it: use an app password or OAuth |
| The app password is wrong or was revoked | Copied with spaces, truncated, or the account password changed or was reset | Create a new one and paste it without spaces |
| Workspace no longer allows password sign-in | Google Workspace account on a device that only supports username and password | Use OAuth, or the SMTP relay service |
| Username is not the full address | Login is `alex` instead of `alex@yourdomain.com` | Use the full email address |
| Wrong server or port for the method | Auth to `smtp-relay.gmail.com` with a password when the relay expects an IP | Match the method to the host (see below) |

### Is the plain-password login still supported?

No. Google says that since May 1, 2025, Workspace accounts no longer support less secure apps, third-party apps or devices that sign in with only a username and password, and that you must use OAuth for those ([Google Workspace guide on sending from a printer, scanner or app](https://knowledge.workspace.google.com/admin/gmail/send-email-from-a-printer-scanner-or-app)). Personal Gmail accounts follow the same direction: Google's help says it no longer supports third-party apps or devices that require sharing your username and password ([Add Gmail to other email clients](https://support.google.com/mail/answer/7126229)). "Less Secure Apps" is a setting you can no longer count on.

## Which method should you use instead?

There are three supported routes. Pick by what is doing the sending.

**An app password** is a 16-character password Google generates for one app, usable when 2-Step Verification is on. Google's own help calls app passwords "not recommended" and unnecessary in most cases, but Google's Workspace guide still lists them for `smtp.gmail.com`. It is the quickest fix for a script on a personal account.

**OAuth** replaces the password with a token your app obtains by signing in with Google. It is the recommended path for anything user-facing, and for libraries and clients that support "Sign in with Google". Our guide to [app passwords and OAuth for mail clients](/blog/app-passwords-and-oauth-for-mail-clients-what-changed-and-what-to-use) covers the trade-offs.

**The Workspace SMTP relay service** is for servers and devices in a Workspace domain. Per Google's guide it uses `smtp-relay.gmail.com` on ports 25, 465 or 587, authenticates by your server's IP address instead of a password, and may require a static IP. You set it up first in the Admin console.

Google's guide lists these limits at the time of writing: the relay allows up to 10,000 recipients per day per user, and `smtp.gmail.com` with an app password allows 2,000 messages per day. Check the page before you size a workload against them, because they change.

## How do you fix it step by step?

1. **Confirm the host and port.** For `smtp.gmail.com`, use port 465 (implicit TLS) or 587 (STARTTLS). If you are unsure which to use, see [SMTP ports 25, 465, 587 and 2525](/blog/smtp-ports-25-465-587-2525).
2. **Use the full email address as the username**, including the domain.
3. **Turn on 2-Step Verification**, then create an app password for this one app. Paste it with no spaces.
4. **Test outside your app.** A direct login removes your code from the picture. [Testing SMTP by hand with swaks and openssl](/blog/swaks-openssl-smtp-testing) shows how.
5. **If it is a Workspace account and passwords are refused outright**, switch the app to OAuth or move the sender to the relay service.
6. **If it still fails after a new app password**, the account itself may be blocked or locked. Sign in to the account in a browser and look for a security prompt.

A quick test with swaks looks like this (replace the values, and keep the password out of your shell history):

```bash
swaks --server smtp.gmail.com --port 587 --tls \
      --auth LOGIN --auth-user you@yourdomain.com \
      --auth-password "$GMAIL_APP_PASSWORD" \
      --from you@yourdomain.com --to you@example.com \
      --header "Subject: SMTP login test" --body "Login works."
```

If this prints `235 2.7.0 Accepted`, the credentials are fine and your application has a bug in how it passes them. If it prints the same 535, the credential is the problem.

## Is this a Gmail problem or a problem with your app?

Treat it as your configuration, not an outage. A 535 is a hard answer about the credentials you presented. Two other codes look similar but mean different things: a `454 4.7.0` is a temporary server-side failure (retry later), while `534 5.7.9` means the login mechanism is too weak for the account's policy (RFC 4954 again). Only the 535 asks you to supply new credentials.

## Does the same error happen with other SMTP services?

Yes, because 535 5.7.8 is a standard code, not a Gmail invention. The Koltrix [SMTP relay](https://docs.koltrix.com/smtp-relay) returns `535 5.7.8 Authentication failed` when the password is not a `kx_` API key, the key is invalid or revoked, or it lacks the `send` scope, and the text in brackets says which. The relay listens on port 2525, and ports 587 and 465 do not accept API keys. For new code, the REST API gives you JSON errors and idempotent retries; see [SMTP relay vs HTTP API](/blog/smtp-relay-vs-http-api). Treat any key you use as a password, as covered in [email API key security](/blog/email-api-key-security).

## Bottom line

A Gmail `535 5.7.8` means your login method is no longer accepted or the secret is wrong, not that the mail failed. Use the full address, replace the plain password with an app password or, better, OAuth, and use the Workspace relay for servers and devices. Test with swaks before blaming your code.