Fix Gmail “Invalid Credentials (Failure)” for IMAP and SMTP

If your IMAP or SMTP client throws Invalid Credentials (Failure) when connecting to Gmail, the password is almost certainly correct. Google removed Basic Auth for personal Gmail accounts in May 2022, so legacy clients get rejected even with the right credentials. This DevAnswers fix shows the canonical App Password recipe, an openssl diagnostic, and the deprecated DisplayUnlockCaptcha flag older guides still recommend.

What “Invalid Credentials (Failure)” Actually Means #

Google’s “Invalid Credentials” rejection is misleading wording. It almost never means a typo or a wrong password. It means Google has refused the AUTH METHOD your client used. Per Google’s own account-security page:

To help keep your account secure, from May 30, 2022, Google no longer supports the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password.

support.google.com: Less secure apps & your Google Account

That blanket change is what your client is hitting. For personal Gmail accounts in 2026, two auth methods work for IMAP/SMTP: OAuth2 (which requires Google Sign-in support in your client), or an App Password (a 16-character Google-generated token that lets older clients bypass the OAuth2 requirement). Almost every legacy client (Outlook 2019/2021, Thunderbird without OAuth2, all PHP/Python/Node SMTP libraries, fetchmail, isync, mutt) needs the App Password path. Google Workspace accounts have a third path: admins can re-enable Less Secure Apps at the org level for legacy devices (covered in the Workspace section below); for personal Gmail accounts the LSA toggle no longer exists. Seeing “invalid credentials” even though Less Secure Apps was already on? Same root cause: the fix is switching that device to an App Password.

Prerequisites #

• A Gmail or Google Workspace account
• An IMAP/SMTP client returning Invalid Credentials (Failure) or AUTHENTICATIONFAILED (Outlook, Thunderbird, fetchmail, isync, mutt, PHPMailer, nodemailer, etc.)
• Web access to your Google Account settings at myaccount.google.com
• Optional: openssl on the client machine for the diagnostic step

The Fix: 2-Step Verification + App Password #

The canonical fix for 99% of “Invalid Credentials” errors is to enable 2-Step Verification on the Google Account, then generate an App Password and paste it into your client’s password field. App Passwords are gated behind 2SV; per Google’s documentation, app passwords “can only be used with accounts that have 2-Step Verification turned on.” If 2SV is off, the App Passwords menu will not appear at all.

• Sign in at myaccount.google.com.
• Open Security in the left sidebar.
• Find 2-Step Verification. If it is off, turn it on now (Google walks you through the SMS or authenticator setup). See the full 2-Step Verification setup guide if you need the per-step walkthrough.
• Once 2SV is on, return to Security and search for App passwords at the top of the page. Google hides this option deep in the settings tree, so the in-page search is faster than scrolling.
• Click App passwords, type a label (your client name, e.g. “fetchmail-srv1”), and click Create.
• Google generates a 16-character password and shows it once. Copy it. Paste it into your client’s password field. The App Password walkthrough covers the screen-by-screen flow if anything looks different.

If you see the related Outlook-specific error “Application-specific password required”, the same App Password resolves it.

Confirm IMAP Is Enabled in Gmail Settings #

Even with a correct App Password, the connection will fail if Gmail’s IMAP transport is disabled at the account level. Google turns IMAP off by default on many new accounts to encourage webmail use. Check the setting:

• Open Gmail in a browser.
• Click the gear icon (top right), then See all settings.
• Open the Forwarding and POP/IMAP tab.
• Under IMAP access, confirm Enable IMAP is selected.
• Click Save Changes at the bottom of the page.

Diagnose Connection vs Auth with openssl #

If App Password is set + IMAP is enabled but the client still fails, the next question is whether the network can even reach Gmail’s IMAP endpoint. Use openssl s_client to open a manual IMAPS handshake bypassing your email client entirely:

openssl s_client -connect imap.gmail.com:993 -crlf -quiet

A successful handshake completes the TLS negotiation and prints Gmail’s IMAP server banner:

* OK Gimap ready for requests from <your-ip> (server-id)

If you see the banner, the network path is clear and the auth problem is somewhere in your client config (wrong username, missing App Password, IMAP-disabled in Gmail). If the connection TIMES OUT or refuses, you have a network-level block: a corporate firewall, an aggressive UFW rule, AWS Security Group, or ISP filtering on port 993 (and/or 587 for SMTP). The -crlf flag matters: IMAP requires CRLF line endings, so omitting it makes any manual LOGIN command you try afterward look malformed to the server.

DisplayUnlockCaptcha Is Deprecated (Skip It) #

Older guides recommend visiting https://accounts.google.com/DisplayUnlockCaptcha after a suspicious-login lockout to temporarily relax Google’s security heuristics. That endpoint existed to help third-party Basic-Auth clients re-establish trust, and it became obsolete when Google removed Basic Auth support for personal accounts in May 2022. The endpoint may still respond, but it has no effect on the modern App Password / OAuth2 auth path. If you hit a suspicious-login lockout today, the resolution is to sign in via the web first (which clears the lock), then re-issue the App Password if you suspect the old one was scoped to the locked session.

Google Workspace Admins: The Legacy LSA Toggle #

Google Workspace administrators have one path personal-account users do not: an organization-level Less Secure Apps toggle. Per the Workspace admin documentation:

As an administrator, you can choose whether to allow your users to use less secure apps to access their Google accounts.

support.google.com (Workspace): Control access to less secure apps

The toggle lives at admin.google.com → Security → Access and data control → Less secure apps. Use it only for legacy devices that physically cannot use App Password or OAuth2 (a few embedded scanners and multi-function printers still need it). For every other case, the App Password path is the canonical solution. The full Less Secure Apps context article covers the Workspace admin flow in detail plus the OAuth2 alternatives for modern devices.

Conclusion #

“Invalid Credentials (Failure)” almost never means the password is wrong. Since Google removed Basic Auth for personal accounts in May 2022, the canonical fix is: enable 2-Step Verification, generate a 16-character App Password (Google’s RNG, not yours), and paste it into your client without the display spaces. If the error persists, confirm IMAP is enabled in Gmail’s settings, then run the openssl IMAPS handshake to rule out network filtering.

Common follow-on: if you’re configuring server-side mail (Postfix relay through Gmail), the next class of error to expect is Gmail’s SPF/DKIM/DMARC enforcement. See the Postfix Gmail bounce 5.7.26 fix for the canonical SPF/DKIM setup readers usually hit next.