IMAP vs POP3: what they were built for

Use IMAP. Every mainstream mail host defaults to it, every client from Outlook to Apple Mail speaks it, and POP3 survives for a short list of specific situations most people never hit. If all you wanted was the verdict, that is it.

The more useful part is why, because IMAP vs POP3 is really a fight between two decades. Each protocol is a snapshot of what a personal computer was at the moment it was designed, and every practical difference between them falls out of that.

Both protocols handle the reading half of email; neither one sends anything. If you are standing up mail on your own domain from scratch, our business email setup guide walks the whole stack, DNS records included. This article is the layer where mail reaches your devices.

Built for different computers

The Post Office Protocol came first: RFC 918, published October 1984 and marked experimental. The computer it imagines is a workstation that is not always connected to the network. Mail piles up on a server; the workstation connects, downloads everything, deletes the server copies, and disconnects. Server storage was scarce, and your own machine was assumed to be the real home of your mail. The server is a post office box, and the protocol is the trip into town to empty it.

POP3, the version everything still uses, was pinned down in RFC 1939 in May 1996. It is a genuinely tiny protocol: USER, PASS, STAT, LIST, RETR, DELE, and QUIT cover a normal session. Nothing in it describes folders, read state, or search, because your local mail program was expected to handle all of that after the download.

IMAP began in 1985 at Stanford, designed by Mark Crispin, and it flips the core assumption: the mailbox lives on the server permanently, and a mail client is a window onto it. Read and unread state, folders, flags, and search all exist server-side, so any number of windows can point at the same mailbox and agree about what they see. The protocol is still maintained four decades on; the current base specification is IMAP4rev2 (RFC 9051), published August 2021.

POP3 moves the mailbox to your device. IMAP moves your view to the mailbox. Everything in the next table is downstream of that sentence.

Sync vs download, in one table

The POP3 vs IMAP choice compresses into seven rows.

The classic POP3 failure is a phone and a laptop on the same account. Each device downloads independently, so whichever checks first takes the mail, and the other may never see it. Clients patch this with a "leave a copy on the server" setting, which fixes the disappearing messages and nothing else: read state still lives per device, sent mail exists only on the machine that wrote it, and deleting a message on one device leaves it sitting on the other. That patched setup is half of IMAP with none of the coordination, which is why providers stopped recommending it years ago.

SMTP vs IMAP is a category error

"SMTP vs IMAP" is a heavily searched comparison, and it compares the delivery truck to the front door. IMAP and POP3 are retrieval protocols: they exist so your client can read a mailbox. SMTP is the transfer protocol: your client submits outgoing mail over SMTP on port 587, and servers hand mail to each other over SMTP on port 25. Every working email setup uses SMTP for sending plus exactly one of IMAP or POP3 for reading. There is no choice between them; the real choice was the one above.

The two reasons POP3 still exists

Case one is single-device control. With download-and-delete POP3, the server holds your mail only between checks; after that, the sole copy lives on hardware you own. People who treat a mail host as an untrusted relay rather than a storage service want exactly this, and it is a legitimate want: there is no provider-side archive to scan, subpoena, or breach. The cost is symmetrical, and you should hear it as a warning: with no server copy, one dead laptop drive ends your entire mail archive. POP3 without a backup routine is a countdown.

Case two is mailbox quotas. Budget shared hosting still hands out mailboxes measured in hundreds of megabytes. On IMAP, a quota that small eventually fills, and once it fills, new inbound mail starts bouncing. POP3 drains the mailbox on every check, so a tiny quota never fills no matter how much mail flows through it. Inelegant but effective, and still the standard advice on hosts with hard mailbox limits.

There are stragglers beyond those two: old scanners and appliances that only speak POP3, and scripts that eat a mailbox and delete as they go. If you have not recognized yourself by now, the answer is IMAP.

Ports and TLS: the reference table

Since RFC 8314 (published January 2018) the recommendation is implicit TLS everywhere: the connection is encrypted from the first byte instead of starting in plaintext and upgrading with STARTTLS. In practice that means 993 for IMAP, 995 for POP3, and 587 or 465 for sending. A config screen asking for port 143 or 110 with encryption set to "none" is a setup guide from another era. Close the tab.

Team email: whether you want a protocol at all

Both protocols assume one person, one mailbox, one password. That assumption is collapsing from two directions.

Providers closed the password door first. Microsoft permanently disabled basic authentication for IMAP and POP in Exchange Online in the first week of January 2023. Google turned off password-only access to IMAP, POP, and SMTP on September 30, 2024; third-party clients now have to authenticate with OAuth. Both changes were about credential theft, and the practical effect is that type-your-password-into-any-client IMAP no longer exists at the two largest business mail hosts.

Teams break the model from the other side. Point five people's clients at one shared IMAP mailbox and you get colliding read flags, no record of who took which message, and eventually two different answers sent to the same customer. The protocol has no concept of a team. A shared inbox is shared state with history and assignment, and shared state wants an application, not a retrieval protocol from 1984.

We build on the web side of that line, so weigh the stance accordingly: LetterDuck has no IMAP access today. Inbound mail for a domain arrives on a catch-all route, gets parsed once, and lands in a database that everyone on the team reads through the same threaded inbox; replies can go out as any address on the domain. An address in that model is a routing rule rather than a mailbox with its own credentials, which is why we do not count or bill them. The tradeoff points the other way too: if two decades of your workflow live in Thunderbird, a web workspace is a genuine migration, and you should choose a host that speaks your protocol instead.

So: IMAP on 993 for a person. POP3 on 995 only if you can name your reason, and back up the archive the day you switch it on. And if the address belongs to a team rather than a person, the honest answer to IMAP vs POP3 is neither; compare workspaces instead.