SMTP, POP3 and IMAP: How Email Actually Works

How a message actually travels

Press send and the process is more involved than it looks. The mail client hands the message to an outgoing mail server using SMTP on port 587. That server looks up the MX record for the recipient's domain to find which server accepts mail for that address. It then connects to that server on port 25 and delivers the message. The recipient's server stores it until the recipient's client connects to retrieve it.

The recipient's server holds the message whether the client is online at the time of delivery. When the client next connects, it either downloads the message via POP3 or syncs its view of the mailbox via IMAP. Which one depends entirely on how the client is configured.

SMTP: the sending protocol

SMTP is a text-based protocol. The session reads as a conversation between client and server. The server speaks first. The client greets it with EHLO and the server responds with a list of extensions it supports. What happens next depends on those capabilities.

Notice that STARTTLS completes before AUTH. The TLS handshake wraps the authentication, so the password never travels as plaintext. A server that advertises STARTTLS in its EHLO response but does not require it is still vulnerable to clients that skip the upgrade. A properly hardened server enforces the upgrade before accepting credentials.

SMTP commands

The command set is small. Each step in the session maps to a single command. Reading an SMTP log becomes straightforward once you recognise them.

POP3: download and retrieve

POP3 does one thing. It lets a client connect to a mail server, download messages and remove them from the server. The model comes from a time when people checked email from a single machine. The server was a temporary holding area. The permanent copy lived locally on the client.

A POP3 session is stateful in a narrow way. Messages are identified by their position in the mailbox for the duration of the session. The client lists them, retrieves the ones it wants, marks others for deletion, then ends the session. Deletions are not applied until QUIT is issued. Nothing on the server is modified before that point.

Most clients can be configured to leave copies on the server after downloading. This is an option rather than the default behaviour. It lets POP3 behave a little more like IMAP, though without any of the sync capabilities. If messages need to be accessible on multiple devices, IMAP is the better starting point.

POP3 commands

IMAP: synchronised access

IMAP was built around a different assumption: messages live on the server. Clients access them remotely. A phone, a laptop and a web browser can all look at the same inbox and see the same state. Read a message on one device and it appears as read on the others. Move a message to a folder from one client and every other client reflects the change.

This works because reading a message does not remove it from the server. The client fetches it for display but the authoritative copy stays in place. Actions taken by the client, marking as read, starring, moving to a folder, deleting, are written back to the server as flag updates rather than as purely local state changes.

IMAP sessions are tagged. Every command the client sends starts with a unique tag so responses can be matched back to the command that produced them. This is necessary because IMAP allows the client to issue commands without waiting for each previous one to complete. POP3 has no equivalent because it works strictly in sequence.

Server-side search is another capability POP3 simply does not have. An IMAP client can ask the server to return only messages matching a given sender, date range, subject string. The server filters and returns matching message IDs. The client fetches only those. On a mailbox with thousands of messages, downloading everything locally to search through would be impractical.

SMTP vs POP3 vs IMAP

Each protocol has a specific role. The confusion usually comes from the fact that email clients present all three as a single system. Seeing the responsibilities laid out separately makes it easier to locate where a problem is likely to live.

Ports worth knowing

Email involves more ports than most protocols because each role has at minimum a plaintext port and a TLS port. SMTP adds a third because server-to-server relay and client submission serve different purposes and carry different requirements.

Port 25 is blocked by most ISPs on residential connections to prevent compromised machines from relaying spam directly. Cloud providers block it by default too. Enabling it typically requires contacting support and explaining the use case. For most applications, sending through an authenticated relay on port 587 is the practical path that sidesteps the issue entirely.