Skip to content

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.

Koltrix Team5 min read
Red padlock resting on a black keyboard
Photo by FlyD on Unsplash
On this page(7 sections)
  1. What does the error look like?
  2. Why does Gmail reject the login?
  3. Is the plain-password login still supported?
  4. Which method should you use instead?
  5. How do you fix it step by step?
  6. Is this a Gmail problem or a problem with your app?
  7. Does the same error happen with other SMTP services?
  8. Bottom line

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). 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:

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.

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 [email protected] 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). 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). "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 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.
  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 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):

swaks --server smtp.gmail.com --port 587 --tls \
      --auth LOGIN --auth-user [email protected] \
      --auth-password "$GMAIL_APP_PASSWORD" \
      --from [email protected] --to [email protected] \
      --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 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. Treat any key you use as a password, as covered in 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.

Start with Koltrix

Your domain, one inbox, and an API that sends.

A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.

SharePost on XLinkedIn