What is IMAP and how does it work

IMAP (Internet Message Access Protocol) is the protocol your mail app uses to read email that lives on a mail server. When you open Apple Mail, Outlook, or Thunderbird and see your inbox, IMAP is what put it there. The messages are not stored in the app. They are stored on the server, and the app is showing you a synchronized view of them.

That single design decision is the whole point of IMAP. Because the server holds the authoritative copy of your mailbox, every device you connect sees the same thing. Read a message on your phone and it is already marked read on your laptop. Move a message into a folder in Outlook and it is in that folder in webmail. Delete it anywhere and it is gone everywhere.

IMAP handles only the receiving half of email. Sending is a different protocol on different ports, which is the single most common source of confusion when mail “stops working” in a client. This guide covers what IMAP does, which ports it uses, how it differs from POP3, how an actual IMAP session works, and what to check when a client cannot connect.

IMAP is one of three protocols, not all of email#

Email uses separate protocols for separate jobs, and a mail client has to be configured correctly for each one:

• SMTP sends mail. Your client submits outgoing messages to a mail server on port 587 or 465, and mail servers deliver to each other on port 25.
• IMAP reads mail that stays on the server. Ports 143 and 993.
• POP3 downloads mail off the server. Ports 110 and 995.

Mail clients present these as one “email account”, which hides the fact that they are independent connections to potentially different hostnames with different credentials. When someone reports “I can receive but not send”, that is almost always an SMTP problem and no amount of IMAP troubleshooting will fix it. When they report “my mail app says it cannot connect but webmail works fine”, that is IMAP or the network in front of it.

Where mail is delivered in the first place is decided earlier still, by your domain’s MX records. MX records route mail to a provider. IMAP is how you get it back out of that provider afterwards. The two are unrelated settings that people routinely conflate.

IMAP ports: 143 and 993#

There are two ways to run IMAP, and the difference is only about when encryption starts.

Port 993 (IMAPS, implicit TLS)#

The connection is encrypted from the first byte. The client opens a TLS session, and the IMAP conversation happens entirely inside it. This is what “IMAP over SSL” means in a mail client’s settings, and it is what nearly every provider recommends. Use 993 unless you have a specific reason not to.

Port 143 (STARTTLS, explicit TLS)#

The connection starts unencrypted, the client issues the STARTTLS command, and the connection is upgraded to TLS before authentication happens. Configured correctly this is just as secure as 993. Configured badly it is not: if the client is set to “STARTTLS if available” rather than “STARTTLS required”, a network attacker can strip the upgrade offer and the client will happily send your password in plaintext.

If that implicit-versus-explicit split sounds familiar, it is the same distinction as FTPS versus SFTP in file transfer, and the same as port 465 versus 587 on the sending side. In all three cases the modern advice is the same: prefer the port that is encrypted from the start, and never allow a plaintext fallback.

Plain unencrypted IMAP on port 143 with no TLS at all still exists in old server configurations. It should not be used across the internet. Everything in an IMAP session, including your password and the full text of every message, is readable in transit.

IMAP vs POP3#

POP3 is the older protocol and works on a completely different model. POP3 connects, downloads new messages to the device, and (by default) deletes them from the server. The device becomes the only place the mail exists.

For almost everyone, IMAP is the correct choice. Anyone who reads mail on both a phone and a computer needs the server to be the source of truth, and POP3 cannot do that.

POP3 still has two legitimate uses. The first is a strict archival workflow where you deliberately want mail pulled off the server onto storage you control. The second is a tiny server mailbox quota, since POP3 empties the mailbox as it goes. Both are niche. The classic POP3 disaster is a user who set up POP3 on a new phone, did not notice the “delete from server” default, and removed years of mail from every other device.

How an IMAP session actually works#

IMAP is a text protocol, and you can watch it work. Every client command starts with a tag the client picks, and the server answers with that same tag so the client can match responses to commands out of order.

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

Once connected, the session looks like this:

a1 LOGIN user@example.com "password"
a1 OK LOGIN completed
a2 LIST "" "*"
* LIST (\HasNoChildren) "/" "INBOX"
* LIST (\HasNoChildren \Sent) "/" "Sent"
* LIST (\HasNoChildren \Trash) "/" "Trash"
a2 OK LIST completed
a3 SELECT INBOX
* 1843 EXISTS
* 12 RECENT
* OK [UIDVALIDITY 1354789012] UIDs valid
a3 OK [READ-WRITE] SELECT completed
a4 FETCH 1843 (FLAGS BODY[HEADER.FIELDS (FROM SUBJECT DATE)])
a5 LOGOUT

The important part is what the client is not doing: it is not downloading the mailbox. SELECT opens a folder and the server reports how many messages are in it. FETCH then asks for specific parts of specific messages, and a client will typically fetch just headers to build the message list, then fetch a body only when you click the message. That is why an IMAP account with 40,000 messages opens quickly while a POP3 account with 40,000 messages takes an hour to set up.

A failed login stops the conversation right there, which makes this a useful diagnostic. If a1 LOGIN returns NO , the credentials or the authentication method are the problem, and the network, the certificate, and the client’s other settings are all fine.

Flags and folders#

IMAP stores per-message state on the server as flags: \Seen , \Answered , \Flagged , \Deleted , and \Draft . Synchronizing those flags is what makes read/unread state and stars agree across devices.

Deletion works in two steps, which surprises people. Setting \Deleted only marks a message; it stays in the folder until an EXPUNGE removes it. Most clients hide flagged-deleted messages and expunge on their own schedule, which is why deleted mail can reappear briefly during a resync.

Folders carry special-use attributes ( \Sent , \Drafts , \Trash , \Junk , \Archive ) so a client can tell which folder is which without guessing at names. When a client guesses wrong, you get the classic symptom of duplicate Sent folders, one named “Sent” and one named “Sent Items”, with half your outgoing mail in each. The fix is in the client’s account settings: point it explicitly at the server’s folders instead of letting it create its own.

IMAP IDLE, or push mail#

Basic IMAP requires the client to ask whether anything is new. IDLE inverts that: the client tells the server it is waiting, the connection stays open, and the server announces new messages as they arrive. This is what “push email” means on a standard IMAP account, and it is why a mail app that polls every 15 minutes feels broken next to one that supports IDLE.

IDLE needs a long-lived connection. Aggressive firewalls, captive portals, and some mobile networks kill idle TCP connections, and the symptom is mail that only appears when you manually open the app.

What IMAP does not do#

IMAP has a narrow job, and most email problems blamed on it are outside its scope.

It does not send mail. It has no role in whether your mail reaches the recipient, so it has nothing to do with messages landing in spam. That is handled by SPF, DKIM, and DMARC on the sending side.

It does not filter mail. Server-side rules use a separate protocol (Sieve), which is why filters created in one mail client often do not apply to mail read in another.

It does not manage calendars or contacts. Exchange and its MAPI protocol bundle mail, calendar, contacts, and tasks into one account, which is the main practical difference between “an Exchange account” and “an IMAP account” in a client’s setup screen. Microsoft 365 and Google Workspace both still speak IMAP, but a client connecting over IMAP alone gets mail and nothing else.

JMAP is the modern JSON-based replacement designed to fix IMAP’s chattiness and mobile behavior. Support is real but limited, and IMAP will remain the universal option for a long time.

Finding your IMAP settings#

Every provider publishes four values: hostname, port, encryption, and username. The username is almost always your full email address, not just the part before the @.

Two provider-side changes broke a great many working mail clients and still generate support tickets. Google stopped accepting plain account passwords for IMAP in 2022, so a Gmail account needs either OAuth or an app-specific password (which requires two-factor authentication to be enabled first). Microsoft disabled basic authentication for IMAP in Exchange Online, so Microsoft 365 mailboxes require OAuth 2.0 and any client too old to support it simply cannot log in. In both cases the password is correct and the login still fails.

Common IMAP problems#

The connection times out. Nothing is answering on that port. Check the hostname resolves at all, since a typo or a stale DNS record produces exactly this. Then check whether the network blocks the port, which is common on hotel, airport, and corporate Wi-Fi. A quick openssl s_client -connect host:993 from another network settles which side is at fault.

The connection is refused immediately. Something is reachable but nothing is listening on that port. Usually the wrong port for the encryption setting: 993 configured as STARTTLS, or 143 configured as SSL. Match them properly.

A certificate warning appears. The name on the certificate does not match the hostname you typed, or the certificate expired. This happens when a client is pointed at a generic server hostname instead of the provider’s published mail hostname. Never click through it. A certificate error on an IMAP connection means the password you are about to send may not be going where you think, and the same TLS mismatch causes apply here as on the web.

Authentication fails with the right password. Check whether the provider requires an app password or OAuth, whether IMAP access is switched off for the mailbox, and whether the username needs to be the full email address.

Mail disappears from other devices. Something is configured as POP3 with “delete from server” enabled, or a client is expunging a shared Trash folder. Audit every device on the account.

Everything is slow. IMAP performance falls off with very large single folders. Splitting a 200,000-message inbox into yearly archive folders fixes it more reliably than any client setting.

Sending fails but receiving works. Not an IMAP problem. Look at SMTP: the submission port, authentication, and whether the network blocks outbound mail ports.

IMAP and web hosting#

Web hosting and email hosting are separate services that people expect to arrive together, and that expectation causes a specific class of support ticket. Hostney hosts websites, not mailboxes. Your mail lives with whichever provider your MX records point at, whether that is Google Workspace, Microsoft 365, Zoho, or anyone else, and your IMAP settings come from that provider.

What that means in practice on Hostney is that MX records are edited under Hosting > DNS Zone Editor, and after a change you can confirm what the world actually sees at tools.hostney.com/mx. Watch for default MX records created when a domain was added. If those are still in place while you are using an external provider, mail routing gets ambiguous and IMAP will show you a suspiciously empty inbox because the mail never reached that provider at all. A domain or server migration is the usual moment this bites, since it is easy to move a site and forget the mail records.

The separation matters for the sending side too. Outbound port 25 is blocked on Hostney servers, so a WordPress site cannot deliver mail directly and needs an SMTP relay. That is unrelated to reading mail over IMAP, but it comes up in the same conversation constantly, and the full plugin walkthrough plus the SPF, DKIM, and DMARC records that should accompany it are the two things worth reading before you file it as an email outage.

Quick reference#