How IMAP Actually Works (And Why It Matters for Privacy)

What happens when you open your email

When you open an email client and see your inbox, something specific is happening at the protocol level. Something is connecting to your email server using IMAP and requesting your messages. Whether that "something" is your device directly, or a backend server acting on your behalf, is the privacy question most people never think to ask.

IMAP stands for Internet Message Access Protocol. It was first designed in 1986 and the current version (IMAP4rev1, RFC 3501) dates to 2003. Despite its age, it remains the most widely supported protocol for accessing email from a client. Every major email provider supports IMAP: Gmail, Outlook, iCloud, Fastmail, Protonmail (via Bridge), and virtually every custom domain host.

The connection dance

Here is what happens, step by step, when an IMAP connection is made to a mail server:

1. A TCP connection opens to the server, usually on port 993 (IMAP over TLS). The connection is encrypted.
2. The connecting party authenticates with your username and password (or an OAuth token) to prove it is authorised to access your mailbox.
3. A SELECT command opens a specific mailbox (usually INBOX). The server responds with the state of that mailbox: how many messages, how many are unseen, the next available message number.
4. FETCH commands download message headers, bodies, or both. Messages can be requested by number or by UID (a persistent identifier).
5. STORE commands change message flags, marking something as read (\Seen), flagged (\Flagged), or deleted (\Deleted).
6. If the server supports IDLE, the connection can enter an idle state where the server pushes notifications about new messages instead of requiring repeated polling.

In the simplest case, a desktop client like Thunderbird performs this entire conversation directly from your machine to your email server. Nobody else is involved. But most modern email clients, including Marco, do not work this way.

The reality: most clients use a backend

A purely local IMAP client has real limitations. IMAP IDLE only works on one folder at a time, so monitoring multiple folders or accounts requires multiple persistent connections from your device. Push notifications on mobile require a server that can receive IMAP events and forward them through Apple or Google's push infrastructure. Fast search across large mailboxes requires indexing that is expensive to do on a phone.

For these reasons, most modern email clients, including Marco, run a backend server that connects to your mail server on your behalf. Marco's backend maintains the IMAP connections, handles sync, builds search indexes, and delivers push notifications. Your email passes through our infrastructure as part of this process.

This is true of Spark, Superhuman, Edison, and essentially every email client that offers reliable push notifications and fast search on mobile. The honest question is not "does this client use a backend?" because the answer is almost always yes. The question is "what does that backend do with my email beyond the infrastructure basics?"

Where the privacy differences actually are

If nearly every modern client routes email through a backend, why does privacy vary so much between them? Because the backend's purpose varies enormously.

Some backends exist purely for infrastructure: IMAP sync, search indexing, push notifications. The email passes through the system to make the product work, and that is all. The backend is plumbing.

Other backends exist to power features that analyse your email content. Smart Inbox categorisation reads your messages to sort them. AI summarisation reads your messages to condense them. Ad targeting reads your messages to profile you. Collaboration features read your messages so teammates can comment on them. In these cases, the backend is not just plumbing; it is actively processing your email for purposes beyond delivery.

The privacy distinction is not "backend or no backend." It is "what does the backend do with your email, and why?"

• Gmail's servers process your email for ad targeting and smart features (Smart Reply, nudges, promotions sorting).
• Spark's servers process your email for Smart Inbox categorisation, AI summaries, and team collaboration features.
• Superhuman's servers process your email for speed optimisation, tracking, and AI features.
• Marco's servers process your email for IMAP sync, search indexing, and push notifications. We do not scan email content for ad targeting, AI features, smart sorting, or any purpose beyond making the core product work.

Every client on that list uses a backend. The difference is what the backend is for.

Why IMAP still matters

If most clients use a backend anyway, why does it matter that Marco builds on IMAP rather than provider APIs like the Gmail API or Microsoft Graph?

IMAP is a standard protocol. It works with every email provider. Building on IMAP means Marco supports Gmail, iCloud, Outlook, Fastmail, Protonmail, self-hosted servers, and any provider that speaks the protocol. That is nearly every email address in the world.

Provider APIs lock you in. A client built on the Gmail API works with Gmail. A client built on the Microsoft Graph API works with Outlook. If you move your email to Fastmail or a custom domain, those clients cannot follow you. IMAP can.

Provider APIs also come with strings attached:

• Access control: Google requires expensive third-party security audits for apps requesting email scopes. This barrier kills small email startups before they launch.
• Policy dependency: if Google changes API terms, tightens scopes, or deprecates endpoints, every client built on their API breaks.
• Provider lock-in: supporting N providers means building N separate integrations instead of one protocol implementation.

The cost of building on IMAP is complexity. IMAP is stateful, every provider implements it slightly differently, and there are dozens of optional extensions with inconsistent support. Building a reliable IMAP client is dramatically harder than using the Gmail API. For the details, read What Most Email Clients Get Wrong About IMAP.

IMAP extensions that matter

The base IMAP protocol is capable but limited. Over the years, extensions have been added to improve performance and functionality. Not all servers support all extensions, which is one of the things that makes IMAP client development challenging.

IDLE (RFC 2177)

Without IDLE, a client has to poll the server repeatedly to check for new messages. IDLE lets the connecting party say "tell me when something changes" and the server pushes notifications. This is how real-time email updates work over IMAP. Servers that do not support IDLE force polling, which is slower and uses more battery.

CONDSTORE (RFC 7162)

CONDSTORE adds modification sequence numbers to messages. This lets a sync process ask "what changed since I last checked?" instead of re-fetching the entire mailbox state. Without CONDSTORE, every sync requires comparing the full message list, which is slow for large mailboxes.

QRESYNC (RFC 7162)

QRESYNC builds on CONDSTORE to handle disconnection and reconnection. It lets the sync process efficiently resume from where it left off, including detecting messages that were deleted during the gap. This is critical for reliable offline-to-online transitions.

How to evaluate an email client's privacy

When you evaluate an email client, do not ask "does it use a backend?" Ask these instead:

1. What does the backend do with my email beyond sync, indexing, and push notifications?
2. Does the client scan email content for AI features, smart sorting, or ad targeting?
3. Does the client's business model depend on processing my email data?
4. Does the client work with any email provider, or does it lock me into Gmail/Outlook?

Marco's backend handles IMAP sync, search indexing, and push notifications. It does not scan your email for AI features, ad targeting, or smart categorisation. Once your email reaches your device, search and triage run locally. The business model is $4/month, not data monetisation.

For the deeper engineering story of building on IMAP, read What Most Email Clients Get Wrong About IMAP. For the offline-first architecture that makes local processing work at scale, read Offline-First Landscape. For how free email clients pay for themselves, read The Real Cost of Free Email Apps.