SMTP vs IMAP vs POP3: how the three email protocols differ

Why email needs more than one protocol

SMTP vs IMAP vs POP3 comes down to direction. SMTP pushes a message toward the recipient's mailbox, and IMAP and POP3 let a client pull it back out.

Sending a message and reading it happen at different times, on different machines. The sender's client hands off the message as soon as it's written. The recipient may be offline for hours, then read the message on a laptop, and later on a phone.

SMTP covers the moment of sending, server to server, until the message lands in the mailbox. POP3 and IMAP cover the reading, whenever the recipient connects. That split is why a mail client asks for two servers when you set up an account, an outgoing one and an incoming one.

What each RFC defines

RFC 1939 states the POP3 model in its introduction:

"POP3 is not intended to provide extensive manipulation operations of mail on the server; normally, mail is downloaded and then deleted."

IMAP leaves sending to SMTP on purpose. RFC 9051 says IMAP4rev2 "does not specify a means of posting mail" and points to the submission protocol of RFC 6409.

How they fit in one mail's journey

SMTP carries the message up to the mailbox, and IMAP or POP3 handles the last step.

1. A mail client submits the message to its outgoing server over SMTP: port 587 with STARTTLS, or port 465 with implicit TLS. The server checks who is sending before it accepts MAIL FROM.
2. From there, the outgoing server looks up the MX records of the recipient's domain and relays the message over SMTP on port 25. This hop runs between two servers and carries no user login.
3. The receiving server stores the message in the recipient's mailbox. SMTP's part ends here.
4. The recipient's clients connect to the mailbox server and fetch the message over IMAP on port 993, or POP3 on port 995.

SMTP pushes: the side that holds the message opens the connection. IMAP and POP3 pull: the client opens the connection and asks what's new.

Anatomy: SMTP vs IMAP vs POP3 side by side

The three protocols differ in direction, in where mail lives, and in how much state a session keeps.

Ports and the RFC behind each one

With implicit TLS, the TLS handshake starts as soon as the TCP connection opens. With STARTTLS, the session starts in cleartext and the client asks to upgrade it.

IANA briefly registered port 465 as "smtps", then revoked it, but mail software kept using it for submission over TLS. In 2018, RFC 8314 had IANA add "submissions" as an alternate usage of port 465, next to the service the port had been reassigned to, to match that practice. It also asks clients and servers to support both 587 and 465 during a transition period.

Where the messages live

With POP3, a client downloads each message with RETR and marks it with DELE. The server deletes the marked messages when the session ends with QUIT. A second device that connects afterwards finds an empty maildrop. A client setting such as "leave a copy on the server" keeps the messages there, yet read state still lives on each device, so a message read on the laptop shows as new on the phone.

With IMAP, the messages stay on the server, and so do their flags. A message read on the laptop carries the \Seen flag, and the phone shows it as read the next time it syncs. Each client keeps a cache, and the server holds the copy they all sync against.

Three sessions, traced

In these traces, C: marks what the client sends and S: what the server answers.

SMTP submission on port 587

S: 220 smtp.example.com ESMTP ready
C: EHLO laptop.example.org
S: 250-smtp.example.com
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
   (TLS handshake, then the client starts over with EHLO)
C: EHLO laptop.example.org
S: 250-smtp.example.com
S: 250 AUTH PLAIN
C: AUTH PLAIN AGJvYkBleGFtcGxlLmNvbQBzZWNyZXQ=
S: 235 Authentication successful
C: MAIL FROM:<bob@example.com>
S: 250 OK
C: RCPT TO:<alice@example.net>
S: 250 OK
C: DATA
S: 354 End data with <CRLF>.<CRLF>
C: (headers and body)
C: .
S: 250 OK: queued
C: QUIT
S: 221 Bye

The client authenticates before MAIL FROM, as RFC 6409 section 4.3 requires by default, and does it inside TLS, as RFC 8314 recommends. A mail transaction runs from MAIL FROM to the final 250. After that, the client can start the next message on the same connection, and nothing from the previous transaction carries over.

POP3 on port 995

S: +OK POP3 server ready
C: USER alice
S: +OK
C: PASS secret
S: +OK maildrop has 2 messages (2048 octets)
C: LIST
S: +OK 2 messages
S: 1 1120
S: 2 928
S: .
C: RETR 1
S: +OK 1120 octets
S: (headers and body)
S: .
C: DELE 1
S: +OK message 1 deleted
C: QUIT
S: +OK bye

The session moves through the three states of RFC 1939. It stays in Authorization until PASS succeeds, works in Transaction for LIST, RETR and DELE, and enters Update on QUIT, where the server removes message 1. If the connection drops before QUIT, the server never enters Update and deletes nothing.

IMAP on port 993

S: * OK [CAPABILITY IMAP4rev2 AUTH=PLAIN] Server ready
C: a1 LOGIN alice secret
S: a1 OK LOGIN completed
C: a2 SELECT INBOX
S: * 2 EXISTS
S: * OK [UIDVALIDITY 3857529045] UIDs valid
   (more untagged responses describing the mailbox)
S: a2 OK [READ-WRITE] SELECT completed
C: a3 FETCH 1 (UID FLAGS BODY.PEEK[HEADER.FIELDS (FROM SUBJECT)])
S: * 1 FETCH (UID 4827 FLAGS () BODY[HEADER.FIELDS (FROM SUBJECT)] {49}
S: From: bob@example.com
S: Subject: Weekly report
S:
S: )
S: a3 OK FETCH completed
C: a4 UID STORE 4827 +FLAGS (\Seen)
S: * 1 FETCH (UID 4827 FLAGS (\Seen))
S: a4 OK STORE completed
C: a5 LOGOUT
S: * BYE Logging out
S: a5 OK LOGOUT completed

Each command carries a tag (a1, a2) so the client can match a completion to its command. SELECT ties the session to one mailbox.

BODY.PEEK reads the headers without setting \Seen. UID STORE then sets the flag on the server, by a UID that stays valid across sessions as long as UIDVALIDITY is unchanged, and every other client sees it. The connection can stay open: with IDLE, part of IMAP4rev2, the server reports new mail as it arrives.

Limits

SMTP stops at the mailbox. It has no command to list, read or delete stored messages, so a mail client pairs it with a retrieval protocol to read mail.

POP3 has no folders, no server-side flags and no search.

An IMAP client tracks UIDVALIDITY, UIDs and sequence numbers over a long-lived connection, and handles untagged responses the server can send at any time. A client that mishandles one can fall out of sync with the server.

JMAP batches several method calls in one HTTPS request, resyncs from a state string, and pushes changes through EventSource or push subscriptions. A client can use it only where the mailbox provider runs a JMAP server.

Cleartext ports remain registered. RFC 8314 asks mail clients and servers to use TLS, but a server can still accept cleartext on 110 and 143. Between servers on port 25, TLS depends on STARTTLS, and RFC 8461 section 1 describes how an attacker who deletes the "250 STARTTLS" response can downgrade the session. Transport security covers MTA-STS and DANE, which close that gap.

Check it yourself

Connect to each port with openssl s_client and read what the server sends first:

# SMTP submission, STARTTLS on 587
openssl s_client -connect smtp.example.com:587 -starttls smtp -crlf

# SMTP submission, implicit TLS on 465
openssl s_client -connect smtp.example.com:465 -crlf

# IMAP, implicit TLS on 993
openssl s_client -connect imap.example.com:993 -crlf

# POP3, implicit TLS on 995
openssl s_client -connect pop.example.com:995 -crlf

The first line the server sends names the protocol: 220 from SMTP on 465, +OK from POP3 on 995, * OK from IMAP on 993. On 587, openssl runs the STARTTLS upgrade itself, so type EHLO test and look for AUTH in the reply. Type a1 CAPABILITY on 993 to see whether the server offers IMAP4rev1, IMAP4rev2, or both. To type further commands such as RCPT TO or QUIT, add -nocommands: without it, s_client reads a line that starts with Q or R as its own command.

To watch a relay hop, find the recipient domain's mail server with dig +short MX example.com, then connect to it on port 25 with -starttls smtp. On a test server you control, telnet mail.example.com 110 or telnet mail.example.com 143 shows the cleartext ports that RFC 8314 asks clients to leave behind.

Where it fits

This page compares protocols the cluster covers one at a time: SMTP for transfer commands and reply codes, message submission for the first hop and port 587, IMAP and POP3 for retrieval, JMAP as the JSON-over-HTTPS alternative, and transport security for TLS between servers. The reference hub lists the full set of email standards.

For a sending API that accepts SMTP submission on port 587, see the SMTP sending guide.

Choosing between them

Sending uses SMTP: submission on 587 or 465 from a client, relay on 25 between servers. The choice is on the reading side.

IMAP suits any account read from more than one device, since the server keeps the messages and their flags. An archiving script that must hold the only copy can use POP3. A client built on HTTP can use JMAP wherever the mailbox provider offers it.

FAQ

IMAP vs SMTP: is SMTP better than IMAP?

They do different jobs. SMTP sends a message and moves it between servers. IMAP reads and manages the messages already in a mailbox. A mail client uses both: SMTP for its outgoing server, IMAP for its incoming one.

Which ports do SMTP, IMAP and POP3 use?

SMTP relay between servers uses port 25 (RFC 5321). A mail client submits on port 587 with STARTTLS (RFC 6409, RFC 8314) or port 465 with implicit TLS (RFC 8314), and RFC 8314 asks clients and servers to support both. IMAP uses 993 with implicit TLS, or 143. POP3 uses 995 with implicit TLS, or 110.

Is SMTP still used today?

Yes. RFC 5321 is the current standard for moving mail between servers, and RFC 6409 for submitting it from a client. JMAP leans on it too: RFC 8621 describes a JMAP server that performs SMTP submission, or proxies to an SMTP submission server.

Is POP3 used anymore?

POP3 is still a current standard: RFC 1939 defines it, and RFC 8314 updated it in 2018 with implicit TLS on port 995. For an account read from several devices, IMAP or JMAP keeps every device in sync.

How do I tell if my email account uses POP or IMAP?

Open the account's incoming server settings in your mail client. Port 993 or 143 means IMAP, port 995 or 110 means POP3. A server name such as imap.example.com or pop.example.com is another clue.

RFC reference

RFCs covered: RFC 5321, RFC 6409, RFC 8314, RFC 1939, RFC 3501, RFC 9051, RFC 8620, RFC 8621. Also cited: RFC 3207, RFC 2595, RFC 8461. Superseded / updated by: RFC 9051 obsoletes RFC 3501. RFC 8314 updates RFC 1939, RFC 2595, RFC 3501, RFC 5068, RFC 6186 and RFC 6409.