# 535 5.7.8 Bounce: Authentication Credentials Invalid

URL: https://email-validation.org/bounce-codes/535-5-7-8/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

**At a glance**

- **Type:** permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
- **Basic code 535:** “Authentication credentials invalid” (RFC 4954 §6).
- **Enhanced code 5.7.8:** “Authentication credentials invalid” in the IANA registry (RFC 4954), in the group security or policy status (RFC 3463 §3.8).

A 535 5.7.8 reply means your app tried to sign in to the mail server and the server rejected the username, password or token. Nothing was sent. Retrying with the same login will fail the same way.

## What it means

[RFC 4954 §6](https://www.rfc-editor.org/rfc/rfc4954) defines `535 5.7.8 Authentication credentials invalid` as the answer to an AUTH command whose credentials do not check out. The RFC says the client should ask the user for new credentials, so a well-written app shows a login error instead of retrying quietly. The same section defines two close relatives that point elsewhere:

- `534 5.7.9`: the sign-in mechanism is too weak for this server.
- `538 5.7.11`: the mechanism needs an encrypted connection first.

## Common causes

- A typo in the password, or the wrong username (a different account or alias).
- The password was changed, but the app, printer or script still holds the old one.
- The account uses 2-step verification, and the server expects an app password instead of the normal one.
- The account was disabled or locked by its admin.
- A configuration file or environment variable holds a stale value after a deploy.

## How providers use it

Gmail answers 535 when the username and password are not accepted. When Google wants you to sign in through a web browser first, or needs an app password, it answers 534 instead ([Google's SMTP error reference](https://support.google.com/a/answer/3726730)).

## How to fix it

1. Sign in to the account's webmail with the same username and password. If that fails too, reset the password there first.
2. Re-enter the credentials in the app by hand. Watch for spaces copied along with the password.
3. If the account has 2-step verification and the provider offers app passwords, create one for this app and use it in place of the normal password.
4. Turn on TLS or STARTTLS in the app, so mechanisms that need encryption are allowed (538 5.7.11 above).
5. For servers and scripts, check where the secret is stored and that the running process actually reads the new value.
6. Stop a looping job until the login works; repeated failures only fill your logs.

If the server answers [530 5.7.0](https://email-validation.org/bounce-codes/530-5-7-0/) instead, the app did not try to sign in at all.

## Related codes

- [530 5.7.0](https://email-validation.org/bounce-codes/530-5-7-0/): Authentication or STARTTLS required
- [5.7.57](https://email-validation.org/bounce-codes/5-7-57/): Client not authenticated to send anonymous mail (Microsoft 365)
- [503 5.5.1](https://email-validation.org/bounce-codes/503-5-5-1/): Commands sent in the wrong order

See [every bounce code](https://email-validation.org/bounce-codes/) in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our [free email checker](https://email-validation.org/email-checker/), or [clean a whole list](https://email-validation.org/bulk-email-verification/) before you send.