535 5.7.8 Username and Password Not Accepted: The Fix

535 5.7.8 means the SMTP server reached the login step, checked your username and password, and refused them. Gmail words it as "535-5.7.8 Username and Password not accepted. For more information, go to https://support.google.com/mail/?p=BadCredentials". Your own mail server may say "535 5.7.8 Error: authentication failed" instead.

The shortest fix for Gmail: create an app password (or switch the app to Sign in with Google), use smtp.gmail.com on port 587 with STARTTLS or 465 with SSL, and log in with your full email address. Microsoft 365, self-hosted servers and a code example for developers are covered below.

Causes and fixes at a glance#

Find your SMTP host in the app's settings, then work down the rows that match it.

Why Gmail rejects your normal password#

Gmail no longer accepts your regular Google password from third-party apps, scanners or scripts. Google turned off this password-only access (which it called less secure apps) for personal accounts in 2022, and for Google Workspace accounts in 2025, after postponing several earlier dates; its final Workspace date was May 1, 2025. IMAP, POP and SMTP still work, but only with OAuth (Sign in with Google) or an app password.

If a device or app set up years ago suddenly fails with 535 5.7.8, this is the most likely reason. If you just set it up and typed your normal password, it is almost certainly the reason. Google's own help now suggests choosing Sign in with Google wherever an app offers it, and keeping app passwords for apps and devices that cannot do OAuth.

• You used your normal Google password instead of an app password.
• 2-Step Verification is off, so the App passwords option never appears.
• You changed your Google password, which revokes every app password you had.
• The app password was pasted with spaces or a trailing character. Paste it as one 16-character string.
• On a work or school account, the admin does not allow app passwords. Ask them for OAuth or a relay option.
• The username is not your full address ([email protected] or [email protected]).

Gmail app password: step by step#

An app password is a 16-character code that lets one app sign in to your Google Account without your real password. Google requires 2-Step Verification before you can create one. The option is also missing on accounts enrolled in Advanced Protection and on accounts where 2-Step Verification uses only security keys. If you cannot find it, see Gmail app password option missing.

1. 1

   Turn on 2-Step Verification

   Go to myaccount.google.com, open Security, and turn on 2-Step Verification if it is off.

2. 2

   Open App passwords

   Search for "App passwords" in your Google Account, or go to myaccount.google.com/apppasswords. Google moves this entry around, so search is the most reliable way in.

3. 3

   Name the app and create the code

   Type a label you will recognise later, such as "Office scanner" or "CRM", then select Create. Google shows the 16-character code once.

4. 4

   Replace the password in the app

   Paste the code into the app's SMTP password field as one string, with no spaces. Keep the username as your full email address.

5. 5

   Check host and port, then send a test

   Use smtp.gmail.com with port 587 and STARTTLS, or port 465 with SSL/TLS. See Gmail SMTP settings for the full list.

For developers: Python and Node settings#

The same rule applies to code: a script that logs in with your normal Gmail password gets 535 5.7.8 back, even when the password is correct. Some libraries and apps word the rejection differently, such as "configured password was not accepted" or Python's SMTPAuthenticationError with b'5.7.8 Username and Password not accepted'. The fix is the same.

Use these values. Port 587 starts in plain text and upgrades with STARTTLS; port 465 is encrypted from the first byte. Mixing them up (for example, port 465 with STARTTLS) usually fails with a connection or TLS error rather than 535. For a sending service rather than a personal mailbox, Gmail's OAuth 2.0 support for SMTP avoids storing any password at all.

Microsoft 365: enable authenticated SMTP#

Exchange Online often reports this failure with its own codes, such as 535 5.7.139 or 535 5.7.3 Authentication unsuccessful, but the cause is the same family: the login was refused. Microsoft has an organisation-wide SMTP AUTH setting and a per-mailbox setting, and the mailbox setting wins. Microsoft recommends leaving SMTP AUTH off for the organisation and enabling it only for the mailboxes that still need it, such as a scanner or line-of-business app.

1. 1

   Open the user in the Microsoft 365 admin center

   Go to admin.microsoft.com, then Users, then Active users, and select the mailbox that sends.

2. 2

   Open Manage email apps

   In the flyout, select Mail, then Manage email apps in the Email apps section.

3. 3

   Check Authenticated SMTP and save

   Tick Authenticated SMTP and select Save changes. In PowerShell the same switch is Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false.

4. 4

   Match the app settings

   Host smtp.office365.com, port 587 with STARTTLS, username = the full email address. Use OAuth if the app supports it.

5. 5

   If it still fails, check security defaults and authentication policies

   If Microsoft Entra security defaults are on, SMTP AUTH is already disabled, and an authentication policy that blocks basic auth for SMTP overrides the mailbox setting. Both are admin decisions with security trade-offs.

535 5.7.8 Error: authentication failed (non-Gmail servers)#

"535 5.7.8 Error: authentication failed" is the wording Postfix uses when SMTP AUTH fails, usually with Dovecot or Cyrus SASL checking the password behind it. Variants such as "authentication failed: authentication failure" or "authentication failed: (reason unavailable)" mean the same thing: the password check failed, and the client was not told why. The reason is in the server's log, not the error. New to the stack? Start with Postfix and Dovecot explained.

1. 1

   Read the mail log at the time of the failure

   Postfix logs a line such as "SASL LOGIN authentication failed" or "SASL PLAIN authentication failed". The Dovecot auth log next to it usually names the real problem, such as unknown user or password mismatch.

2. 2

   Check the username format

   Many hosts, including cPanel servers, expect the full address ([email protected]), while some setups expect only the local part. Try the format the host documents.

3. 3

   Test the credential outside the app

   Log in to webmail or IMAP with the same pair. On a server you run, doveadm auth test [email protected] checks the password against Dovecot directly.

4. 4

   Check the SASL wiring

   If every account fails, confirm Postfix's smtpd_sasl_path points at Dovecot's auth socket and that Postfix can read it. A broken socket or wrong user database fails everyone, not one user.

5. 5

   Reset the password if needed

   If only one account fails and the log shows a password mismatch, reset it in the host's control panel and enter the new one in the app by hand.

How to stop it happening again#

• Use OAuth where the app supports it, and app passwords only where it does not. Give each app its own code so you can revoke one without breaking the rest.
• Keep a short list of every device, app and script that sends through your account. After a password change, create new app passwords for each one straight away.
• Send automated mail (scanners, CRMs, alerts) from a dedicated account or relay, not a personal login, so one person's password change cannot stop it.

Where AI Emaily fits#

We build AI Emaily, an AI-native email client. It connects Gmail and Outlook through OAuth, so there is no SMTP password for those accounts to expire or get revoked; some IMAP providers, such as iCloud, still need an app password. It will not fix a scanner or script that sends over SMTP; for those, the steps above are the fix.