IMAP Settings for Gmail, Outlook, Yahoo, iCloud

Almost every provider uses port 993 with SSL for IMAP, and the only thing that really changes between them is the host name and the credential. Gmail is imap.gmail.com, Yahoo is imap.mail.yahoo.com, iCloud is imap.mail.me.com, and all three require an app password rather than your normal account password. The exception, and it is a big one this year, is Microsoft: Outlook.com and Microsoft 365 mailboxes no longer accept a password over IMAP at all.

Here is the whole thing in one table. Everything below it is the detail for whichever row you came for.

Settings checked against provider documentation in August 2026.

What are IMAP settings?

IMAP settings are the four things a mail client needs to reach your mailbox: the server host name, the port, whether the connection is encrypted, and the credential to log in with. IMAP itself is the protocol that leaves your mail on the provider's server instead of downloading it, so every device you connect sees the same mailbox and the same read, moved and deleted state.

That last part is why the settings matter more than they used to. Because IMAP keeps the server as the source of truth, connecting a new client is a genuinely low-risk thing to do. Nothing gets migrated, nothing gets removed, and if you dislike the client you disconnect it and your mail is untouched. The settings are the only friction, and most of that friction is now the credential rather than the host name.

Gmail IMAP settings

Google publishes these directly. Incoming is imap.gmail.com on port 993 with SSL. Outgoing is smtp.gmail.com, which supports TLS on port 587 or SSL on port 465. Your user name is the full address including @gmail.com, or the full address at your Workspace domain.

The part that stops people is the password. If two step verification is on, and on most Google accounts it now is, Gmail will refuse your normal password over IMAP. You generate an app password at the account security page instead, which produces a sixteen character string scoped to that one client. Paste it in place of the password and the connection works immediately.

Google Workspace accounts have one extra layer: an administrator can disable IMAP access for the whole domain. If the settings are right, the app password is fresh and it still fails, that is worth asking about before you spend another hour on it.

Outlook and Microsoft 365 IMAP settings, and what changed

The server details are still outlook.office365.com on port 993 with SSL, with smtp.office365.com on 587 for sending. What changed is that knowing them is often no longer enough.

Microsoft finished retiring basic authentication for Exchange Online in April 2026. For a managed Microsoft 365 work or school mailbox, that means a user name and password over IMAP is refused outright, no matter which client is asking, and app passwords do not help because app passwords are themselves a form of basic authentication. The client has to support OAuth, where sign-in happens in a Microsoft window rather than a password field.

Personal Outlook.com and Hotmail addresses are heading the same way. Microsoft's own support page states that it will "fully remove support for Basic authentication from Outlook.com, and only rely on OAuth," and newer personal accounts already ship with authenticated SMTP disabled and no user toggle to turn it back on. If you are choosing a mail client in 2026 and your main mailbox is a Microsoft one, OAuth support is the first thing to check and everything else is secondary.

The practical effect is that Outlook, Thunderbird and the other clients that implement OAuth still connect fine, while a lot of older or simpler tools that only ever asked for a password have quietly stopped working. If that is what happened to you, it is not a settings problem and no combination of host names will fix it.

Yahoo and AOL IMAP settings

Yahoo is imap.mail.yahoo.com on port 993 with SSL, sending through smtp.mail.yahoo.com on 465 or 587. AOL runs on the same infrastructure and follows the same shape: imap.aol.com on 993, smtp.aol.com on 465 or 587.

AOL is worth a note of its own, because AOL ships no desktop mail client except Desktop Gold, which is a 9.99 dollar a month subscription for Windows only. That makes IMAP the normal way to read an AOL mailbox on a Mac, a Chromebook or Linux, and we cover the whole picture on our AOL Mail app page.

Both require an app password, and unlike Google, Yahoo requires it whether or not you have two step verification switched on. You generate it under account security, where it is listed as generating a password for an app that does not support the standard sign-in. Use your full address as the user name, including the @yahoo.com or @aol.com part.

iCloud IMAP settings

iCloud Mail is imap.mail.me.com on port 993 with SSL, with smtp.mail.me.com on port 587 for sending, authentication required.

Two quirks catch people here. The first is that iCloud requires an app specific password, and to generate one you must have two factor authentication enabled on the Apple Account, which is not optional for this. The second is the user name: for the incoming server it is usually just the part before the @, so johnappleseed rather than [email protected], while the outgoing server wants the full address. If IMAP refuses the login and everything else looks correct, try it both ways before assuming the password is wrong.

One thing worth saying plainly, because people arrive at these settings after installing the wrong thing: Apple publishes no mail app outside macOS, iOS and iPadOS, and the iCloud for Windows app does not read mail. That is why an iCloud address on a PC has to go through a third party client at all. The full picture, including every route and what Apple own Windows app actually covers, is on our iCloud Mail app page.

Zoho, Fastmail and your own domain

Zoho publishes imap.zoho.com on 993 with SSL, sending via smtp.zoho.com on 465 for SSL or 587 for TLS. Zoho will accept your account password unless two factor authentication is on, in which case you generate an application specific password like everywhere else. Note that Zoho runs regional data centers, so an account provisioned outside the US may use a regional host name instead.

Fastmail is imap.fastmail.com on 993, smtp.fastmail.com on 465, and app passwords are required rather than optional.

For a mailbox on your own domain, the pattern is nearly always mail.yourdomain.com on 993 with SSL, and your hosting control panel will tell you exactly, usually under a "connect devices" or "configure mail client" link next to the mailbox. Two things go wrong here more than anywhere else. If the host's TLS certificate was issued for the server's own name rather than for mail.yourdomain.com, the client will warn about a mismatch, and the fix is to use the server host name the panel gives you rather than your own domain. And if the mailbox lives on a small VPS you administer, the IMAP daemon going down is a silent failure: nothing bounces, mail simply stops arriving in your client. Putting a check on port 993 that runs every thirty seconds turns that into a notification instead of a bad afternoon.

Do I need an app password for IMAP?

With Gmail, Yahoo, AOL, iCloud and Fastmail, yes. With Zoho only if two factor authentication is on. With your own domain, no, the mailbox password is the password. With Microsoft, an app password will not help you at all because the whole basic authentication mechanism it belongs to has been retired.

An app password is a long random credential scoped to one application, which the provider can revoke on its own without touching your account password. It exists because a mail client cannot complete a two factor prompt. It is also a genuine security improvement over handing a client your real password, since revoking it takes one click and affects nothing else. We wrote the longer explanation, including where to generate one on each provider, in the guide to what an app password is.

Should IMAP use port 993 or 143?

Use 993. It carries the connection inside TLS from the first byte, and every provider listed above expects it. Port 143 is the original IMAP port, historically plaintext, sometimes upgraded mid-session with STARTTLS. It still works in places but there is no reason to choose it, and a setup guide that tells you to use 143 with no encryption is out of date rather than offering an alternative.

The same logic applies on the sending side. Prefer 587 with STARTTLS where it is offered, which is the modern standard for authenticated submission, and use 465 with implicit SSL when the provider lists that instead.

Why is my IMAP connection being refused?

Five causes cover nearly all of it, in rough order of how often they turn out to be the answer.

You used the account password where an app password is required. This is the single most common one and it produces a plain authentication failure that looks like a typo. Generate the app password and paste it instead.

Two step verification was switched on after you set the client up. Enabling it invalidates credentials that were working the day before, so a client that ran for two years suddenly stops. Same fix.

The mailbox is a Microsoft one and the client does not support OAuth. No credential will work. You need a different client.

IMAP access is disabled on the account or the domain. Several providers ship it off by default, and a Workspace or Zoho administrator can disable it for everyone. It is a checkbox on the provider side, not something the client can route around.

The port is blocked or the host name is wrong. Some corporate and hotel networks block 993 outbound. A wrong host name usually produces a timeout rather than an authentication error, which is a useful way to tell the two categories apart: authentication errors mean you reached the server, timeouts mean you did not.

Is IMAP better than POP3?

For almost everyone, yes. IMAP keeps mail on the server and syncs state in both directions, so a message you read on your laptop is read on your phone and a message you file is filed everywhere. POP3 downloads copies to one machine and, in its default configuration, deletes them from the server, which means the mailbox exists properly on exactly one device.

POP3 still has one narrow use: a deliberate local archive on a machine that is meant to be the only permanent copy. Outside of that, choosing POP3 in 2026 mostly causes the problem people then search for, which is mail appearing on one device and not another. It is also being actively retired around the edges, with Google closing Gmail's POP-based mail fetching to new users after early 2026.

Which client should you put these settings into?

That depends on how many of the rows above apply to you. One or two mailboxes on a desktop, and Thunderbird or eM Client will do it well, with Thunderbird costing nothing at all. If your mail is a Microsoft mailbox, the OAuth requirement narrows the field to clients that implement it, and Outlook itself becomes hard to argue with.

The case that changes the answer is having five or six of these rows open at once, which is normal for anyone running a business alongside a personal life: a Gmail, a company domain, a billing alias on Zoho, an old Yahoo address that still receives real mail, and an iCloud account tied to the phone. Every client in the field will merge those into one list, and that is worth doing, but the merged list is then longer than any of the individual ones. Sorting it is a separate problem from connecting it, and hardly anything solves the second one.

That is the gap our own IMAP email client is built for: connect your mailboxes with the settings above, up to the limit your plan allows, read them on one board in a browser tab, and have a model tag each message with a category (Important, Newsletter, Notification, Spam, or Other) and a spam verdict before you open it. Because it runs from a server rather than your machine, the setup exists once and follows you between computers, and archive and junk decisions push back over IMAP so the provider webmail agrees with it. The honest trade is offline: a desktop client keeps a local archive and we do not. If you are weighing that specific tradeoff, it is written out in full on the web based email client comparison, and the wider field is in the roundup of apps for multiple email accounts.