What this RFC defines
RFC 9051 defines IMAP version 4rev2, the current standard for accessing email stored on a server. Unlike POP3, IMAP keeps messages on the server and synchronizes state across multiple devices. It supports folders, flags, search, and partial message retrieval.
Where you see it in practice
Every modern email client that shows your inbox across multiple devices (phone, laptop, web) is using IMAP. The folder structure you see in your email client (Inbox, Sent, Drafts, Trash) is managed via IMAP SELECT and CREATE commands. The unread/read sync that happens when you open a message on your phone and it immediately marks as read on your laptop is an IMAP flag update (Seen flag) propagating to all connected clients.
How it connects to other RFCs
RFC 9051 obsoletes RFC 3501 (IMAP4rev1 from 2003). It works alongside RFC 2177 (IDLE command for real-time notifications), RFC 4551 (CONDSTORE for atomic flag updates), and RFC 6851 (MOVE command). RFC 8314 mandates TLS for IMAP connections (port 993).
Current status
RFC 9051 is the current IMAP standard, published August 2021. It supersedes RFC 3501 with clarifications, UTF-8 improvements, and tighter security requirements. New IMAP deployments should reference RFC 9051.
The IMAP protocol overview
RFC 3501 defined IMAP version 4rev1, which was the dominant IMAP standard from 2003 to 2021 when RFC 9051 (IMAP 4rev2) was published. IMAP is a stateful protocol where a client authenticates, selects a mailbox, and then issues commands to search, fetch, and modify messages on the server. Unlike POP3, IMAP messages remain on the server by default; the client caches them locally but the server holds the authoritative copy. This is why the same account can be accessed from multiple devices with consistent state.
IMAP versus POP3 architecturally
IMAP is stateful and expressive; POP3 is stateless and minimal. IMAP supports server-side folders, per-message flags (Seen, Answered, Flagged, Draft, Deleted), server-side search, partial message fetches (fetch headers only, or a specific MIME part), quotas, ACLs, and many extensions layered on top. POP3 supports downloading whole messages and marking them for deletion. Any client that provides features like Sent folders shared across devices, unread badge counts synced across phones and desktops, or server-side search is using IMAP.
Superseded by RFC 9051
RFC 9051 (IMAP 4rev2), published in August 2021, updated RFC 3501 with clarifications, integration of common extensions into the base standard, and internationalization improvements. In practice, RFC 3501 remains the most widely-deployed IMAP standard in 2026. Most servers negotiate 4rev1 by default, with 4rev2 being adopted incrementally. Any implementation that references RFC 3501 is operating on the standard that runs the majority of world IMAP traffic today.
RFC 3501 (March 2003) defines IMAP4rev1 (Internet Message Access Protocol version 4 revision 1): the mail access protocol used by Gmail, Outlook, iCloud, Yahoo Mail, and virtually every other mailbox service. Unlike POP3, IMAP keeps messages on the server, supports folders, allows partial fetches (headers only, specific parts), and provides server-side search and flags. Port 143 (STARTTLS via RFC 2595) or 993 (implicit TLS per RFC 8314). Updated by RFC 9051 (IMAP4rev2, 2021) but IMAP4rev1 remains dominant.
RFC 3501 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Client access to remote mailboxes with server-side state |
| Model | Messages stored on server; client synchronizes selectively |
| Ports | 143 (STARTTLS), 993 (implicit TLS) |
| vs POP3 | IMAP is stateful, folder-aware, and message-partial-fetch capable; POP3 is stateless download-then-delete |
| Successor | RFC 9051 IMAP4rev2 (2021) |
| Published | March 2003 (obsoletes RFC 2060) |
| Deployment 2026 | Dominant; RFC 9051 IMAP4rev2 adopted incrementally |
Core IMAP commands
| Command | Purpose | State required |
|---|---|---|
CAPABILITY | List server capabilities | Any |
STARTTLS | Upgrade to TLS | Not authenticated |
AUTHENTICATE | SASL authentication | Not authenticated |
LOGIN | Simple username/password auth | Not authenticated |
LIST | List folders (mailboxes) | Authenticated |
SELECT | Select mailbox for message operations | Authenticated |
EXAMINE | Select mailbox read-only | Authenticated |
FETCH | Retrieve message data (headers, body, structure) | Selected |
SEARCH | Server-side search across selected mailbox | Selected |
STORE | Set message flags (Seen, Flagged, Deleted, etc.) | Selected |
COPY, MOVE | Copy/move messages between mailboxes | Selected |
EXPUNGE | Permanently remove messages marked Deleted | Selected |
IDLE | Server pushes updates until client cancels (RFC 2177) | Selected |
LOGOUT | End session | Any |
The FETCH command: selective message retrieval
System-defined message flags
| Flag | Meaning | Set by |
|---|---|---|
\Seen | Message has been read | Client (implicit on BODY fetch) or STORE |
\Answered | Message has been replied to | Client via STORE |
\Flagged | Marked for follow-up (starred) | Client via STORE |
\Deleted | Marked for deletion (removed on EXPUNGE) | Client via STORE |
\Draft | Message is a draft | Client via STORE or APPEND |
\Recent | New arrivals since last SELECT | Server automatic; deprecated in IMAP4rev2 |
Common IMAP client mistakes
Related standards and further reading
- RFC 2060: Original IMAP4rev1 (obsoleted by RFC 3501)
- RFC 9051: IMAP4rev2 (2021 update)
- RFC 2177: IDLE extension (real-time updates)
- RFC 4315: UIDPLUS extension
- RFC 4551: CONDSTORE extension
- RFC 5256: SORT and THREAD extensions
- RFC 6851: MOVE extension
- RFC 2595: STARTTLS for IMAP
- RFC 8314: Cleartext obsolete for access
- Email Protocols and Ports Guide: IMAP vs POP3 vs SMTP
- SSL/TLS Email Setup Guide: securing IMAP access
Frequently asked questions
Should I still use RFC 3501 IMAP4rev1 or move to RFC 9051 IMAP4rev2?
RFC 3501 remains the dominant standard in 2026. RFC 9051 IMAP4rev2 (2021) folds in widely-used extensions (UTF-8 support, CONDSTORE, MOVE) and removes deprecated features. Adoption is incremental; most servers advertise both IMAP4rev1 and IMAP4rev2 capabilities. New client implementations should target rev2 with rev1 fallback; new server deployments should advertise both.
What is the difference between IMAP and POP3?
Model. IMAP keeps messages on the server; the client sees them as a remote folder tree, can search server-side, and syncs flags across devices. POP3 downloads messages to the client and typically deletes them from the server (or leaves for a grace period). IMAP suits multi-device users (phone + desktop + web); POP3 suits single-device users with limited connectivity. In 2026 nearly all consumer mail uses IMAP; POP3 remains for legacy and specialized use.
Why does IMAP use both sequence numbers and UIDs?
Different lifetimes. Sequence numbers are 1..N position within selected mailbox; they shift when messages are expunged (message 5 becomes 4 when message 3 is expunged). UIDs are permanent identifiers that never change (once assigned, a UID belongs to that message forever). Client code that persists message references across sessions must use UIDs; within a single SELECT, sequence numbers are convenient for iteration.
What is IDLE and why is it important?
IDLE (RFC 2177) is an IMAP extension that keeps the connection open with the server pushing updates as they arrive. Instead of polling every 30 seconds, the client issues IDLE and waits for the server to notify about new messages, flag changes, or expunges. Reduces latency (instant notification), bandwidth (no polling overhead), and battery (idle connection is cheaper than repeated polls). Every modern mail client uses IDLE; PUSH notifications on mobile IMAP typically implement this pattern.
Can I use IMAP without TLS?
Technically yes, practically no. Cleartext IMAP transmits passwords and message content in the open. Per RFC 8314, cleartext access is obsolete. Modern clients default to implicit TLS on port 993. Servers should refuse LOGIN before STARTTLS (advertise LOGINDISABLED) or refuse cleartext connections entirely. Only legacy or specialized internal-network deployments should use cleartext IMAP; even then, wrap in VPN or private network.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
