IMAP Password Not Working After Enabling 2FA: The Fix

The short answer
When you turn on two-factor authentication, your account password stops working for IMAP and SMTP because those protocols cannot complete the second factor. The fix is either an app password — a one-time code generated in your security settings — or OAuth 2.0 authorization. Generate one, enter it in place of your account password, and access resumes.
Why your IMAP password stopped working after enabling 2FA, and how to fix it on Gmail, Microsoft 365, iCloud and Yahoo with app passwords or OAuth.
On this page
- 01What this error literally means
- 02Causes and fixes at a glance
- 03App passwords and OAuth: the two paths that restore access
- 04Fix 1: Gmail — generate an app password
- 05Fix 2: Microsoft 365 and Outlook.com — app password or OAuth
- 06Fix 3: iCloud — app-specific password
- 07Yahoo and other IMAP providers
- 08How to tell which fix applies to you
- 09Preventing this problem next time
- 10Where AI Emaily fits
Your IMAP password stopped working the moment you enabled two-factor authentication, and the error message is not telling you why. This is a predictable and expected consequence: turning on 2FA at the provider level causes the provider to block any authentication that cannot prove the second factor, and a bare username-and-password IMAP handshake has no mechanism to do that. The account password still works in a browser, where you complete the second factor interactively. It stops working anywhere the protocol cannot.
This guide covers Gmail, Microsoft 365, iCloud and Yahoo — the four providers where this break is most common — with step-by-step fixes for each. Each has a different route to generate the replacement credential, and each has a different failure mode when that route is hidden or disabled by an administrator.
What this error literally means#
IMAP and SMTP are decades-old protocols. They authenticate with a username and password in a single exchange and have no mechanism to hand off to a second factor mid-connection. When two-factor authentication is on, the provider knows that a client presenting only a password has not proved ownership of the phone, authenticator app or hardware key tied to the account. Rather than let the connection through, it rejects it.
The rejection looks different depending on the provider. Gmail returns an authentication failed message and links to a support article. Microsoft 365 returns error 535 5.7.139 Authentication unsuccessful. iCloud returns incorrect username or password. Yahoo returns similar. The wording differs but the cause is identical: the account password is correct; the authentication method is what the provider is blocking. The two fixes that work are an app password — a static credential the provider issues to specific clients — and OAuth 2.0, where the client redirects to the provider's sign-in page so you can complete the second factor interactively.
This is a security feature, not a misconfiguration
Causes and fixes at a glance#
| Cause | How to confirm | Fix |
|---|---|---|
| Google 2-Step Verification enabled | myaccount.google.com > Security > 2-Step Verification shows On | Generate a Gmail app password |
| Microsoft MFA enabled on a personal or work account | account.live.com or mysignins.microsoft.com > Security > MFA is active | Generate a Microsoft app password or connect via OAuth |
| Microsoft 365 SMTP AUTH disabled by an administrator | App password created but connection still returns 535 5.7.139 | Admin enables SMTP AUTH per-mailbox in Exchange admin center, or switch to an OAuth-capable client |
| iCloud two-factor authentication enabled | Apple ID settings > Sign-In & Security > Two-Factor Authentication: On | Generate an app-specific password at appleid.apple.com |
| Yahoo two-step verification enabled | Yahoo Account Security shows two-step verification: On | Generate a Yahoo app password in Account Security settings |
App passwords and OAuth: the two paths that restore access#
Both fixes work around the same limitation: they replace the plain-password handshake with a credential or flow the provider accepts even after 2FA is on. Understanding which one you are getting into before you start saves confusion.
An app password is a static code — typically 16 to 19 characters — generated in your account's security settings. You paste it into your mail client's password field in place of your account password. It grants access only to the mailbox, not to account management or recovery, and can be revoked individually. An OAuth connection works differently: your mail client opens the provider's sign-in page in a browser, you complete the normal login including the second factor, and the provider issues a short-lived token to the client. The token refreshes automatically and can be revoked from the provider's security settings. Where your client supports OAuth, prefer it. Where it does not, an app password is the right answer.

Fix 1: Gmail — generate an app password#
Gmail app passwords are 16-character codes that substitute for your Google account password in any IMAP or SMTP client. Each is scoped to one client, shows up in your account under a name you choose, and can be revoked without affecting other clients or your main password.
App passwords are only available when Google 2-Step Verification is active and the account is not enrolled in Google's Advanced Protection Program. Advanced Protection accounts require OAuth rather than app passwords — use your mail client's Sign in with Google option instead.
- 1
Open your Google account security page
Go to myaccount.google.com and click Security in the left navigation panel.
- 2
Find App passwords
Under the section titled How you sign in to Google, click App passwords. If this option is absent, your account is either a Google Workspace account where the administrator has disabled app passwords, or Advanced Protection is on. Contact your admin or use OAuth.
- 3
Name the app password and generate it
In the text field, type a label identifying the client — for example Thunderbird or Apple Mail. Click Create. Google displays the 16-character code once on this screen.
- 4
Enter the app password in your mail client
Copy the 16-character code. Spaces in the displayed code are formatting only; remove them if your client does not accept spaces in the password field. Paste the code into the password field of your IMAP account settings. Your username remains your full Gmail address.
- 5
Revoke and regenerate if the code is lost
Google does not show the code again after you close the dialog. If you lose it, return to App passwords, revoke the old entry, generate a new one, and update the setting in your client. Revocation does not touch other app passwords or your account password.
Fix 2: Microsoft 365 and Outlook.com — app password or OAuth#
Microsoft app passwords follow the same pattern: a generated code that substitutes for the account password in a legacy IMAP or SMTP client. Availability depends on how the account is managed.
For personal Outlook.com accounts and Microsoft 365 Family or Personal subscriptions, app passwords are available in Security settings. For Microsoft 365 work or school accounts, an administrator must enable app passwords in Azure Active Directory MFA settings — they are disabled by default on managed tenants. If app passwords are unavailable and your client supports Modern Authentication, use OAuth instead.
- 1
Go to your Microsoft account security settings
For Outlook.com: go to account.live.com, click Security, then Advanced security options. For a Microsoft 365 work account: go to mysignins.microsoft.com, then Security info.
- 2
Add an app password
Select Add sign-in method, choose App password from the list, enter a label for the client, and click Next. Microsoft displays the password once.
- 3
Paste the app password into your mail client
Paste the generated password into the IMAP or SMTP password field. The username remains your full email address. Save the settings.
- 4
If the error is still 535 5.7.139
This error means SMTP AUTH is disabled at the tenant or mailbox level by an administrator — independently of MFA. App passwords do not override this setting. Your Exchange administrator must enable SMTP AUTH for your specific mailbox in the Exchange admin center under Settings > Mail flow > Client connections. If that is not possible, the only path is a mail client that connects via OAuth.
Managed accounts may block app passwords entirely
Fix 3: iCloud — app-specific password#
Apple calls these app-specific passwords rather than app passwords, but the mechanism is the same. When iCloud two-factor authentication is on, any third-party mail client — anything that is not Apple Mail or the iCloud web interface — must authenticate with an app-specific password rather than the Apple ID password.
- 1
Sign in to appleid.apple.com
Open a browser, enter your Apple ID, and complete the two-factor authentication prompt.
- 2
Go to Sign-In and Security, then App-Specific Passwords
Click Generate an app-specific password. Apple prompts for your Apple ID password to confirm the action.
- 3
Name the password and copy the code
Enter a label — the name of the mail client — and click Create. Copy the 19-character code immediately. Apple does not display it again.
- 4
Enter the code in your mail client
In your IMAP settings use imap.mail.me.com on port 993 with SSL, and smtp.mail.me.com on port 587 with STARTTLS. Your username is your full iCloud email address. Paste the app-specific password into the password field.
Changing your Apple ID password revokes all app-specific passwords
Yahoo and other IMAP providers#
Yahoo two-step verification works identically: enabling it disables plain-password IMAP access and requires a Yahoo-generated app password. Go to Yahoo Account Security at login.yahoo.com, click Generate app password, select Other app from the dropdown, name the client, and copy the code. Paste it into the password field of your IMAP client. Yahoo's IMAP server is imap.mail.yahoo.com on port 993 with SSL.
Other providers follow the same pattern. Fastmail and Zoho each have an app password section in their security or account settings. Proton is the exception: its IMAP access goes through a local Proton Bridge application that handles authentication separately from a direct IMAP connection, so there is no app password to generate on the provider side. If your provider is not listed here, look for an App passwords or Third-party app access section in its security settings.
How to tell which fix applies to you#
The provider determines the fix. Gmail or Googlemail addresses use Fix 1. Outlook.com, Hotmail, Live and Microsoft 365 work addresses use Fix 2. iCloud, me.com and mac.com addresses use Fix 3. Yahoo and Ymail addresses use the Yahoo steps above.
If the error persists after you enter a correct app password, the remaining causes are narrow. On Microsoft 365, SMTP AUTH may be disabled at the tenant level independently of MFA — the 535 5.7.139 error rather than 535 5.7.8 is the signal. On Gmail, check that the account is not enrolled in Advanced Protection. On iCloud, confirm the IMAP server address is imap.mail.me.com and not the older imap.gmail.com alias some older guides printed. On any provider, if the app password code was copied with spaces and the client does not accept them, strip the spaces and try again.
Preventing this problem next time#
- When you enable 2FA on any provider, generate app passwords for every mail client already connected to that account before a client surfaces an authentication error.
- Label each app password by the client it belongs to, so you can revoke a specific one — if a device is lost, for example — without disrupting other clients.
- Prefer OAuth over app passwords when your mail client supports it. OAuth tokens expire and refresh automatically; a static app password must be manually revoked if compromised.
- Keep a record of which clients are connected to which accounts. When you rotate or revoke an app password, you know which clients need updating and in which order.
- On managed Microsoft 365 accounts, confirm your organization's policy before enabling MFA: if app passwords are disabled and your client does not support OAuth, you will lose IMAP access with no self-service path.
Where AI Emaily fits#
The reason the account password stops working is not that the password is wrong — it is that the authentication method is now rejected. AI Emaily connects to Gmail and Microsoft 365 via OAuth 2.0, so it does not require an app password on those providers and is not affected by this class of failure. For iCloud, Yahoo, Fastmail and other IMAP providers, it uses the app-specific password you supply during account setup, stores it encrypted, and re-authenticates on reconnect without prompting again. We build AI Emaily; it comes with a 7-day free trial on the Pro and Autopilot plans.
Frequently asked
See it in AI Emaily
Keep reading
Sources

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.