POP3, the Post Office Protocol version 3, is a standard protocol that lets an email client download messages from a mailbox server and, by default, delete them from the server afterward. Defined in RFC 1939, it is one of the two classic retrieval protocols of Internet email infrastructure, alongside IMAP, and it handles only the last step of delivery: moving mail from the provider’s mailbox to the user’s device.
POP3 does not send mail. Outgoing messages travel through SMTP to a mail transfer agent, which stores incoming mail in the recipient’s mailbox; POP3 then collects it. Its design reflects the dial-up era, when users connected briefly, fetched everything and read offline, which explains both its simplicity and its limits today.
How a POP3 session works
A POP3 session is a plain-text command dialogue over TCP that passes through three states. In the authorization state the client proves its identity; in the transaction state it lists, retrieves and marks messages; in the update state, entered only after the QUIT command, the server permanently removes messages marked for deletion. If the connection drops before QUIT, no deletions happen, which protects mail from half-finished sessions.
Each server reply begins with +OK or -ERR, followed by optional text. The table lists the commands that a typical client uses during one session.
| Command | Function | Session state |
|---|---|---|
| USER / PASS | Sends user name and password | Authorization |
| APOP | Authenticates with an MD5 digest | Authorization |
| STAT | Returns message count and total size | Transaction |
| LIST | Lists message numbers and sizes | Transaction |
| UIDL | Returns a unique ID for each message | Transaction |
| RETR | Downloads one full message | Transaction |
| TOP | Downloads headers and a few body lines | Transaction |
| DELE | Marks a message for deletion | Transaction |
| QUIT | Commits deletions and closes | Update |
The UIDL command is what makes the popular leave a copy on the server option possible. The client remembers which unique IDs it has already downloaded and fetches only new ones, although the server itself keeps no record of read or unread status.
Ports, encryption and authentication
POP3 traditionally listens on TCP port 110 in cleartext. Secure deployments use either POP3S on port 995, where TLS starts immediately (implicit TLS), or the STLS command on port 110, which upgrades the connection. RFC 8314 recommends implicit TLS on port 995 for mail access, because opportunistic upgrades can be stripped by an attacker on the path.
| Option | Port | Encryption | Assessment |
|---|---|---|---|
| Plain POP3 | 110 | None | Exposes passwords, avoid |
| POP3 with STLS | 110 | Upgraded to TLS | Acceptable if TLS is enforced |
| POP3S | 995 | TLS from the first byte | Recommended |
Authentication ranges from USER and PASS to SASL mechanisms through the AUTH extension, including OAuth 2.0 tokens (XOAUTH2 or OAUTHBEARER). Several large mailbox providers have disabled basic password authentication for POP3 and accept only OAuth or app-specific passwords, which breaks older clients and scripts.
POP3 compared with IMAP
The decisive difference is where the mailbox lives. POP3 treats the server as a temporary drop box and the client as the permanent store, while IMAP keeps the mailbox on the server and synchronizes folders, flags and read status across every device. The comparison below shows why IMAP became the default for most users.
| Aspect | POP3 | IMAP |
|---|---|---|
| Primary model | Download and store locally | Synchronize with server |
| Folders on server | Inbox only | Full folder hierarchy |
| Read and flag status | Local to one client | Shared across clients |
| Multiple devices | Poor, copies diverge | Designed for it |
| Server storage use | Low | Grows with the mailbox |
| Offline access | Complete after download | Depends on client caching |
| Protocol complexity | Very low | High |
POP3 is unrelated to sender authentication standards such as SPF, DKIM and DMARC. Those are evaluated by receiving servers before mail reaches the mailbox, so a message downloaded through POP3 has already passed or failed them.
When POP3 is still a sensible choice
POP3 remains useful where one device or one program owns the mail and server storage should stay small. Its simplicity also makes it easy to implement in embedded systems and scripts. The decision table summarizes typical situations.
| Situation | Better choice | Reason |
|---|---|---|
| Phone, laptop and webmail used together | IMAP | Status and folders stay consistent |
| Ticketing system ingesting a support mailbox | POP3 | Simple fetch and delete workflow |
| Archiving mail locally from a small quota | POP3 | Frees server storage after download |
| Collecting mail into another provider’s account | POP3 | Widely supported import method |
| Shared team mailbox | IMAP | Several people see the same state |
Pitfalls and common mistakes
- Deleting mail by default: a newly configured client may remove messages from the server, so they disappear from webmail and other devices.
- Single point of loss: when the only copy sits on one laptop, a disk failure without backup destroys the mailbox.
- Sent mail is not uploaded: POP3 has no way to store sent messages on the server, so each device keeps its own sent folder.
- Cleartext on port 110 still appears in old configurations and exposes credentials on untrusted networks.
- Polling too often can trigger provider rate limits; intervals of several minutes are typical.
The idea in brief
POP3 works like collecting letters from a post office box. The post office holds your mail until you come by, you take everything home, and the box is empty again. From then on, the letters exist only in your house.
That is convenient if you always read mail on one computer. It becomes awkward when you also read on a phone, because each device keeps its own copy and does not know what the other has seen. The newer method, IMAP, works more like a shared mailbox that every device looks into at the same time.
A practical scenario
A small accounting firm runs a help desk tool that turns emails sent to its support address into tickets. The tool connects every five minutes over POP3S on port 995, authenticates with an OAuth token, downloads each new message with RETR and then deletes it with DELE before QUIT.
Because the session commits deletions only at QUIT, a network interruption never loses a message: on the next run the tool simply downloads it again and recognizes the duplicate by its Message-ID. The support mailbox on the server stays almost empty, and the firm avoids paying for extra storage. Staff who need a personal view of the same mail use IMAP on their own accounts instead, which keeps the automated workflow and human reading separate.