535 5.7.8 Username and Password Not Accepted: The Fix

535 5.7.8 username and password not accepted means the SMTP server understood exactly who you were trying to be — and refused. The connection arrived, the AUTH command ran, and the credentials were rejected as invalid. The problem is not the format of the login; it is what the server did with it.

Who gets it: anyone who added Gmail, Outlook or an IMAP account to a third-party client, CRM, scanner or application, especially an account that was working before. The credentials have not changed, but the server's rules have. Google and Microsoft both discontinued plain-password SMTP authentication in the past two years, and the error surfaced for users who set credentials once and forgot them.

This post covers what the code means, the most common cause per provider in a table, and step-by-step fixes for Gmail, Microsoft 365 and generic IMAP hosts.

What 535 5.7.8 actually means#

RFC 4954 defines SMTP authentication. A 535 reply means the AUTH command completed and failed — permanently. The three-part enhanced status code 5.7.8 breaks down as: 5 = permanent failure, 7 = security or policy, 8 = authentication credentials invalid. The server accepted and evaluated the credentials; it simply rejected them.

This is different from a 534 reply, where the server objects to the authentication mechanism rather than the values supplied. It is also different from 530, which signals that authentication was never attempted. A 535 5.7.8 is specific: the client reached the AUTH step, submitted credentials, and the server said no.

Gmail's full error string reads '535-5.7.8 Username and Password Not Accepted'. Microsoft 365 surfaces it as '535 5.7.8 Error: authentication credentials invalid' or 'Authentication unsuccessful'. Generic IMAP hosts show the 535 code with a short host-specific message. The code is the reliable part; the message text varies by server.

Causes, how to confirm, and the fix for each#

Work down this table in order. The Gmail row accounts for the majority of cases encountered since 2025.

Fix 1: Gmail — create an app password#

Google ended basic auth for personal Google Accounts on March 14, 2025, and for Workspace accounts on May 1, 2025. Any application storing your Gmail password for SMTP stopped working after those dates. The fix is a Gmail app password: a 16-digit code that acts as a per-application credential without exposing your account password.

App passwords require 2-Step Verification to be active on the account. If it is off, enable it before attempting the steps below.

1. 1

   Enable 2-Step Verification if it is not already on

   Go to myaccount.google.com, select Security, and turn on 2-Step Verification. App passwords cannot be created without it, and the option will not appear in the menu if this step is skipped.

2. 2

   Open the App Passwords page

   Still in Security, find the 'How you sign in to Google' section and select App Passwords. If you do not see it, 2-Step Verification is not fully enabled, or a Workspace admin has restricted it.

3. 3

   Name the app and generate the code

   Type a label that identifies the application — for example 'Thunderbird' or 'My CRM' — then select Generate. Google shows a 16-character code.

4. 4

   Enter the app password in the application

   Paste the 16-character code into the SMTP password field. Enter it without spaces, exactly as shown. Keep the username as your full Gmail address ([email protected]).

5. 5

   Test the connection

   Save and send a test message. If the error persists, confirm that the SMTP host is smtp.gmail.com and the port is 587 (STARTTLS) or 465 (SSL/TLS).

Fix 2: Microsoft 365 — enable SMTP AUTH for the mailbox#

Microsoft 365 can disable SMTP AUTH at two levels: the whole tenant, and per individual mailbox. A per-mailbox setting overrides the tenant default, so you can enable it for one account without opening it organisation-wide. This fix assumes admin access to the Microsoft 365 admin center.

1. 1

   Sign in to the Microsoft 365 admin center

   Go to admin.microsoft.com with an account that has at least Exchange Administrator rights.

2. 2

   Navigate to the affected mailbox

   Select Users, then Active Users. Click the affected user. In the flyout, select Mail, then Manage email apps.

3. 3

   Enable Authenticated SMTP

   Check the box labelled 'Authenticated SMTP', then save changes. This enables SMTP AUTH for that mailbox regardless of the tenant-wide setting.

4. 4

   Confirm the SMTP settings in the application

   Server: smtp.office365.com. Port: 587 with STARTTLS. Username: the full email address. Password: the account password, or an OAuth token if the application supports modern authentication.

5. 5

   Test and check message trace if the error persists

   Send a test message. If SMTP AUTH is enabled but 535 continues, check whether a conditional access policy or authentication policy is blocking basic auth for SMTP — those settings override the mailbox toggle.

Fix 3: generic IMAP and SMTP hosts#

Fastmail, Yahoo Mail, iCloud Mail, Zoho and most independent hosting providers support IMAP and SMTP, but many require an app-specific password when MFA is active. They document this under their own branding rather than 'app password'. The cause here is almost always a wrong credential, a wrong port, or an undiscovered per-app password requirement.

1. 1

   Verify the password works in webmail first

   Sign in to the provider's web interface with the same credentials. If that also fails, the problem is account access, not SMTP configuration. Reset the password before retrying.

2. 2

   Check whether the host issues dedicated app passwords

   Fastmail, Yahoo, iCloud and many others issue app-specific passwords when MFA is active. Search the provider's help docs for 'app password' or 'third-party SMTP'. Use that code rather than your sign-in password.

3. 3

   Confirm port and encryption settings

   Most hosts accept SMTP on port 587 with STARTTLS or port 465 with implicit TLS. Using port 25 or omitting encryption often results in 535 or a connection refusal. Match the host's documented settings exactly.

4. 4

   Re-enter the credential — do not copy-paste from a rich-text source

   A trailing space or a smart quote from a copied credential triggers 535 every time. Type the password by hand, or paste first into a plain text editor to strip formatting before pasting into the app.

5. 5

   Check for account status and quota alerts

   Some hosts cap SMTP sends per day on free plans and return an auth or rate-limit error when the cap is hit. Check the account dashboard for quota warnings before assuming a credential problem.

How to tell which cause you have#

The fastest triage is to read the SMTP host in your application's settings, then verify whether the same credentials work in the provider's webmail. Those two data points narrow the cause to one row below.

How to prevent it happening again#

• Use app passwords or OAuth rather than your account password for SMTP connections. App passwords survive most policy changes; a plain account password may not survive a provider deprecation.
• Keep a record of every application that connects via SMTP and which authentication method each one uses. When a provider announces a change, you can find every affected application in minutes rather than hours.
• After any account password change, audit SMTP connections immediately. Gmail app passwords are revoked when the account password changes, so every application that uses one needs a new code.
• For automated senders — CRMs, scanners, backup tools, monitoring services — use a dedicated service account rather than a personal login. A person's password change then cannot break a batch process.
• On Microsoft 365, enable SMTP AUTH only for mailboxes that genuinely need it, and review the list quarterly. Fewer accounts with basic auth enabled means a smaller attack surface.
• Watch provider announcements. Google's and Microsoft's auth changes both came with months of advance notice; early action is far less disruptive than emergency triage at 2 a.m.

Where AI Emaily fits#

The root of 535 5.7.8 is a mismatch between the credential type an application stores and what the provider now accepts for authentication. AI Emaily connects to Gmail, Outlook and IMAP accounts using OAuth where the provider supports it, so it does not store or submit your account password over SMTP — a plain-auth deprecation has nothing to revoke. We build AI Emaily; connect your inbox at app.aiemaily.com.