The Internet Message Access Protocol (IMAP) is the standard way most modern email clients access mailboxes on a server.

Unlike old-school POP3, IMAP is designed for a world where:

  • You read mail on more than one device.
  • Folders and flags matter (e.g., Seen, Starred, Important).
  • Mailboxes live on a server 24/7, not downloaded and deleted.

This page is a high-level orientation. It links out to deeper guides on IMAP, the surrounding email stack, and common operational issues.

1. What IMAP Actually Does

At a high level:

  • Your mail server receives mail via SMTP and stores messages in a mailbox.
  • Your client (Thunderbird, Outlook, Apple Mail, iOS, etc.) connects via IMAP.
  • IMAP lets the client:
    • List folders (mailboxes).
    • Fetch message headers and bodies.
    • Create, rename, and delete folders.
    • Set flags (seen/unseen, answered, flagged, etc.).
    • Search on the server side.

The important bit: the mailbox lives on the server. Your devices are views into that mailbox, not the canonical copies.

2. IMAP vs POP3 vs Webmail

You’ll often see IMAP mentioned alongside POP3 and webmail:

  • POP3
    • Oldest of the three.
    • Traditionally: download + delete.
    • Good for “one device, low storage server.”
  • IMAP
    • Synchronised view of server-side folders and flags.
    • Built for “many devices, same mailbox.”
  • Webmail
    • A web UI that talks to the mailbox (often via IMAP internally).
    • The protocol underneath is still usually IMAP or an internal API.

A detailed comparison (with migration guidance) lives here:

  • 👉 IMAP vs POP3 vs Webmail (coming soon)

3. Ports, Encryption and Authentication

In practice, you’ll see IMAP offered on:

  • TCP 143 – “IMAP with STARTTLS”
    • Client connects in plain text, then upgrades to TLS.
  • TCP 993 – “IMAPS”
    • TLS is negotiated immediately after connect.

Best practice in 2025:

  • Prefer TLS-encrypted connections (STARTTLS on 143 or direct TLS on 993).
  • Avoid sending credentials in cleartext on any port.
  • Use strong passwords at minimum; modern providers often support OAuth or modern SASL mechanisms instead of raw passwords.

We’ll later attach tooling so you can sanity check this for your own host:

  • 👉 IMAP Port & Encryption Check (tool; coming soon)

4. Capabilities and Extensions (Why IMAP Isn’t “Just POP with Folders”)

IMAP is extensible. Servers advertise supported features via the CAPABILITY command, such as:

  • IDLE – Server can push new-mail notifications instead of forcing periodic polling.
  • UIDPLUS – More reliable message identifiers for sync operations.
  • CONDSTORE / QRESYNC – More efficient sync for large mailboxes.
  • LITERAL+, SASL-IR, and others that improve performance, auth, or interoperability.

Most users never see these names, but they matter for:

  • Mobile battery life.
  • “New mail” responsiveness.
  • Sync behaviour when you move large numbers of messages.

Future content will break some of these out in more detail.

5. Where IMAP Fits in the Email Stack

IMAP is one layer in a multi-layer system:

  • DNS tells the world where to send mail for a domain (via MX records).
  • SMTP handles mail transfer between servers.
  • IMAP provides mailbox access to end users and apps.
  • SPF, DKIM, DMARC, MTA-STS, TLS-RPT live alongside this to reduce spoofing and improve delivery.

If your IMAP mailbox isn’t behaving, the root cause is often in DNS or SMTP, not the IMAP layer itself.

We’ll unpack this end-to-end here:

  • 👉 The Email Stack: DNS, SMTP and IMAP (coming soon)

6. Should You Run Your Own IMAP Server?

You can run your own IMAP server (Dovecot, Cyrus, etc.) and manage everything yourself:

  • Pros:
    • Full control over data, logs, and policies.
    • Integrates nicely into self-hosted stacks.
  • Cons:
    • You handle updates, TLS certificates, storage, backups, monitoring, spam filtering, and abuse.

For many individuals and small teams, a hosted IMAP provider is the more pragmatic choice.

This site is maintained by easyDNS, an independent DNS and email provider. If you’d rather not run your own mail stack, one option is:

We’ll try to keep the protocol content here neutral and standards-focused. Where we do talk about providers, we’ll always disclose our own role clearly.