Fixing AUTHENTICATIONFAILED IMAP Error During Migration

You started a migration, the source connection test failed instantly, and the log shows AUTHENTICATIONFAILED Invalid credentials. Nothing else moved. The server is up, TLS negotiated, but the LOGIN command was refused. This post walks through the four real causes — wrong password, MFA without an app password, locked account, and IMAP disabled at the provider — and how to clear each one in the order that catches the most cases first.

What AUTHENTICATIONFAILED actually tells you#

AUTHENTICATIONFAILED is RFC 5530 territory. The server completed the TCP and TLS handshake, parsed your LOGIN or AUTHENTICATE command, and decided no. That means everything below the auth layer is fine: DNS resolved, port 993 is reachable, the cert chain validated, and the IMAP banner came through. You are not looking at a network problem. You are looking at an identity problem, and the four causes overlap in confusing ways.

If the same credentials work in webmail, the issue is almost never the password itself. It is one of the other three causes pretending to be a password problem. Walk through them in order.

Cause 1: wrong password (the boring one)#

Confirm it first because it is the cheapest to rule out. Copy the username from your migration log, paste it into the provider's webmail, and try the password you gave Mailbox Taxi. If webmail rejects you, you have your answer. Reset the password, update the source credential in Mailbox Taxi, and re-run the connection test.

Watch for hidden whitespace. A trailing space copied from a spreadsheet of staff credentials will silently break IMAP login on most servers without trimming on either side. If you maintain the credential list in a CSV, run it through a trim before importing.

Cause 2: MFA is on and there is no app password#

This is the single most common reason AUTHENTICATIONFAILED shows up on a freshly correct password. Gmail, Yahoo, iCloud, Fastmail, Zoho and others all stop accepting your primary password over IMAP the moment MFA is enabled on the account. The server treats your regular password as invalid for IMAP specifically, even though webmail still accepts it.

The fix depends on the provider:

• Gmail / Google Workspace: generate an app password from the account's security settings, or switch to OAuth. See the Gmail app password fix for the exact path admins miss.
• iCloud, Yahoo, AOL: app-specific passwords only. There is no IMAP-OAuth path.
• Microsoft 365: app passwords are deprecated for tenants on modern auth. You need OAuth, not a password. If your tool is sending Basic auth, you will see AUTHENTICATIONFAILED even with a perfectly valid app password. The modern auth required fix covers this in more detail.

If you are mid-migration and OAuth is the path, also check whether your refresh token has aged out — that surfaces the same way. The OAuth token expired fix walks through token rotation.

Cause 3: the account is locked or suspended#

Repeated failed sign-ins, suspicious-activity flags, admin holds, license loss, and offboarding workflows all manifest as AUTHENTICATIONFAILED to IMAP. The user themselves often does not know — webmail may still let them in via a session cookie even after IMAP has been blocked.

Check the provider's admin console:

• Google Workspace: Admin console → Users → the user → Security. Look for "Account locked" and review sign-in activity.
• Microsoft 365: Entra ID → Users → the user → Sign-in logs. Filter for the last hour and look for conditional-access failures.
• Zoho, Fastmail, Yandex: each has a sign-in activity panel. Look for forced password resets or admin holds.

If the account was locked by your own earlier test attempts, the fastest path is to wait out the cooldown. Hitting it again will reset the clock.

Cause 4: IMAP is disabled at the provider#

This is the cause that catches admins out the most because it is silent. The user can sign in to webmail, app passwords work for other services, MFA is fine — and IMAP is just turned off at the org or user level. The server still answers on 993, still negotiates TLS, still accepts the LOGIN command, and still returns AUTHENTICATIONFAILED. There is no helpful "IMAP disabled" message.

Where to check:

• Google Workspace: Admin console → Apps → Google Workspace → Gmail → End User Access. Confirm "Enable IMAP access" is on for the relevant OU.
• Microsoft 365: Exchange admin center → recipients → mailboxes → the user → Manage email apps. Confirm IMAP is enabled. Tenant-level CAS mailbox plans can override this for new users.
• Zoho Mail: Admin → Mail Account → IMAP access. Off by default on some plans.
• Fastmail, iCloud, Yahoo, AOL: IMAP is on by default, but security defaults may require explicit app-password enrollment first.

A working order of operations#

When you hit AUTHENTICATIONFAILED mid-migration, follow this sequence. It catches the most cases the fastest:

1. Test webmail with the same password

   If webmail rejects it, reset the password. If webmail accepts it, the password is fine and the cause is one of the next three.

2. Check MFA status

   If MFA is on, you need an app password or OAuth depending on the provider. Treat the regular password as automatically invalid for IMAP.

3. Check the admin console for locks

   Look for account locks, sign-in failures, conditional-access denials, or license problems.

4. Confirm IMAP is enabled

   At both tenant and user level. Save changes and wait two to three minutes for propagation.

5. Retry the connection from Mailbox Taxi

   Use the connection test, not a full migration kickoff. You want to confirm auth works before you queue thousands of messages.

For the broader picture of how auth failures fit into the rest of a migration's failure modes, the email migration troubleshooting hub groups every error class with links to the right fix. And if any of the IMAP vocabulary above was unfamiliar, the IMAP protocol glossary has the terms.