IMAP ou POP3 : lequel choisir, et pourquoi votre client ne se connecte pas
La différence tient à l’endroit où vivent vos e-mails, et mal choisir, c’est ainsi qu’on perd tout en changeant d’appareil. Mais la plupart des problèmes de connexion ne viennent pas du protocole, et les deux plus courants ont un nom.
Avery BennettThe difference in one line: with IMAP your mail stays on the server and your client shows you a view of it, and with POP3 your client downloads the mail and, by default, the server stops keeping it.
That is the whole distinction, and it has one practical consequence that catches people out. Set up POP3 on a laptop, then open the same account on a phone, and the older mail is not there. Nothing was deleted by anyone; it was downloaded to the laptop and removed from the server, which is what POP3 is for.
Side by side
| IMAP | POP3 | |
|---|---|---|
| Where mail lives | On the server | On the device that downloaded it |
| Multiple devices | All show the same mailbox | First one to collect wins |
| Read state and folders | Synchronised everywhere | Local to each device |
| Deleting | Deletes everywhere | Local unless configured otherwise |
| Encrypted port | 993 | 995 |
| Plain port | 143 | 110 |
Sending is a separate matter and neither protocol handles it. That is SMTP, usually on 587, and it needs its own settings even when receiving already works. A configuration where mail arrives but will not send is almost always this and not a problem with the account.
Which to choose
IMAP, in nearly every case. It matches how people actually use mail now, across a phone and a computer and sometimes a browser at once, and it keeps the server as the authoritative copy.
POP3 still has one honest use: pulling a local archive of everything into a single machine, deliberately, once. If that is not what you are doing, IMAP is the answer, and most guides that present it as a genuine two-way choice are older than the way people read mail.
One caveat if you do choose POP3: most clients offer a "leave a copy on the server" setting, which prevents the disappearing-mail problem. It is off by default more often than not.
Why your client will not connect, in order of likelihood
Most connection failures have nothing to do with which protocol you picked.
You are using your account password instead of an app password
This is the commonest one by a wide margin, and it is why "app password" shows up inside the search suggestions for IMAP settings. Major providers stopped accepting the normal account password from mail clients. Instead you enable two-factor authentication, generate a separate app-specific password from the account's security settings, and give the client that.
The error you get is an authentication failure, which reads as "wrong password" and sends people off resetting a password that was never wrong. If you bought an account and the listing mentions an app password, that string is what goes in the client, not the login password.
The root folder path is unset
Specific to some IMAP setups and it produces a strange symptom: the connection succeeds, but folders are missing or duplicated, or everything nests oddly. The client needs to be told where the folder tree starts, often INBOX. It looks like a broken account and is a single field.
Port and encryption mismatch
Encrypted ports paired with encryption turned off, or the reverse. Use 993 for IMAP and 995 for POP3 with SSL or TLS enabled, and 587 for sending. The plain-text ports still exist but there is rarely a reason to choose them.
The provider has withdrawn access
The one you cannot fix from the client, covered next.
Protocol access is a policy, not a property
Worth knowing if you are buying a mailbox rather than configuring your own: whether a provider allows external clients is their decision and they revise it.
A concrete example. Onet.pl tightened external client access to free accounts during 2026: POP3 was discontinued, IMAP moved behind a paid tier, and free accounts were left with the web interface and the official app. Accounts registered long ago under earlier terms were treated as exceptions and kept free IMAP.
The lesson generalises. A listing saying "IMAP supported" describes what was true when it was written, which is why the useful move after buying is to connect a real client immediately rather than assume the tag will hold. That is a check that fits comfortably inside a twelve-hour warranty window and cannot be made after it closes.
What protocol access is worth on a listing
Something counterintuitive if you buy mailboxes: protocol access is usually cheap and sometimes free. On one large shelf it is effectively the cheapest attribute measured, against a middle price well over a dollar, while verification attributes on the same shelf cost close to double. There is one shelf where it inverts and IMAP costs nearly twice the middle price, but that is the exception.
So a buyer who filters hard for protocol access is usually optimising the axis that costs least, which is worth knowing before paying a premium someone has attached to it.
Mailbox listings with the protocol tags filterable are on the email hub.
