What Is JMAP and Why Does Fastmail Use It Instead of IMAP?

The short answer
JMAP is a JSON-over-HTTP email protocol, standardized as RFC 8620 and RFC 8621, that Fastmail helped design to replace IMAP. It syncs mail, contacts, and calendars through one API, uses fewer connections, and drains less mobile battery. Fastmail's own apps already run on it, but almost no third-party client speaks it yet, so most Fastmail users don't need to change anything.
What is JMAP? Why Fastmail uses it instead of IMAP, and how it changes sync speed and mobile battery life.
On this page
JMAP is the protocol Fastmail helped design to replace IMAP, and it's why Fastmail's own apps sync the way they do. If you've spotted "JMAP" in a settings screen or a developer doc and wondered whether you're missing a feature, the short answer is: probably not, at least not yet.
JMAP stands for JSON Meta Application Protocol. It's an IETF standard — RFC 8620 covers the core protocol, RFC 8621 adds the mail-specific parts — that does the same job IMAP does: syncing your mailbox between a server and a client. It does it over plain HTTP, in JSON, with one API that also covers contacts and calendars instead of three separate protocols.
Fastmail's web app, iOS app, and Android app already run on JMAP. Almost no other mail client does. That gap is the whole story of this post.
How JMAP Actually Works#
IMAP was designed in 1986 for a world of dial-up connections and mail clients that stayed open on one machine. It works by opening a persistent connection to the server and issuing a sequence of commands — select a folder, fetch headers, fetch bodies, fetch flags — each one a separate round trip. Keeping that connection alive for push notifications (IDLE mode) means the client has to hold a socket open more or less permanently.
JMAP throws that model out. A client sends one HTTP request containing a batch of JSON method calls — "get the ten newest messages in this mailbox, and their flags, and any events created since I last checked" — and gets one JSON response back with everything it asked for. There's no persistent connection to maintain between syncs.
The other piece is state tokens. Every JMAP response includes a state string for the data you just fetched. Next time the client wants to check for changes, it sends that token back and JMAP returns only what changed since then — new messages, moved messages, flag changes — instead of the client re-fetching a folder's full manifest to diff it locally, which is how a lot of IMAP clients handle incremental sync in practice.
For real-time updates, JMAP defines push over a standard HTTP mechanism (Server-Sent Events or WebSocket), rather than requiring the client to sit on an open IMAP socket and periodically ping it to keep firewalls and mobile carriers from killing the connection.
The batching goes further than "send several requests at once." RFC 8620 lets one method call reference the result of an earlier call in the same request — a resultReference, prefixed with a #. A client can ask for the ten newest email IDs in a mailbox and, in the same HTTP round trip, ask JMAP to fetch the full bodies of whatever IDs that first call returns, without waiting for a response in between. IMAP has no equivalent: each fetch is its own command, dependent on the client parsing the previous reply before it can issue the next one.
Before any of this happens, a JMAP client fetches a Session resource from a well-known URL (`/.well-known/jmap`). That single JSON document lists which capabilities the server supports, the account IDs available, and the URLs to use for the API, uploads, downloads, and the push event stream. IMAP has no comparable single-document handshake; a client discovers what a server supports by sending CAPABILITY and probing for extensions one at a time.
Why It Matters: What Breaks Without It#
None of this matters if you never think about your mail protocol, and most people never do. It shows up in three concrete places, all of them worse on IMAP by design rather than by bad implementation.
- Mobile battery — an IMAP client either holds a socket open (draining radio power) or polls on an interval (missing mail between polls); JMAP's HTTP push model does neither
- Sync bandwidth — IMAP's UID and flag models were built for one mailbox at a time, so many clients re-list a folder to detect changes; JMAP's state tokens return only the delta
- Multi-data-type apps — a client that wants mail, contacts, and calendar events today needs IMAP, CardDAV, and CalDAV as three separate protocols with three separate auth flows; JMAP covers all three in one API
JMAP vs. IMAP: The Comparison#
Neither protocol is strictly better across every dimension — JMAP is newer and less deployed, IMAP is older and universal. Here's where they actually differ.
| Dimension | IMAP (RFC 9051) | JMAP (RFC 8620/8621) |
|---|---|---|
| Transport | Its own TCP protocol, typically over TLS | Standard HTTPS — works through existing web infrastructure |
| Data format | A custom wire format of typed literals and lists | JSON |
| Incremental sync | Client-driven; varies by client implementation | Server-issued state tokens return only what changed |
| Push updates | IDLE — a held-open connection | Server-Sent Events or WebSocket over HTTP |
| Covers contacts/calendar | No — needs CardDAV/CalDAV separately | Yes, in the same API |
| Client support today | Universal — Gmail, Outlook, Apple Mail, Thunderbird, and nearly every mail app | Fastmail's own apps, a handful of servers (Cyrus, Stalwart) and early third-party clients |
| First standardized | 1986 (RFC 1064); current revision 2021 (RFC 9051) | 2019 (RFC 8620/8621) |
Which Email Clients and Servers Support JMAP Today#
On the client side, Fastmail's own web app, iOS app, and Android app remain the main mainstream software actually speaking JMAP to a mailbox every day. Apple Mail, Gmail's client, Outlook, and Thunderbird do not implement it as of this writing — a reader checking their own client's settings for a JMAP toggle won't find one unless that client is on the short list above.
The server side has moved faster than the client side. Cyrus IMAP — the open-source IMAP server Fastmail itself runs, and which Fastmail's engineers contribute to — has a native, in-progress JMAP implementation alongside its IMAP support; Cyrus's own developer documentation describes the JMAP support as ongoing rather than finished. Stalwart Mail Server, a newer Rust-based mail server, markets JMAP as a first-class transport alongside IMAP and POP3 rather than an afterthought. Apache James, an older Java-based mail server project, also implements JMAP and lists RFC 8621 compliance as an active area of its roadmap; it's the protocol the Linagora-built OpenPaaS product chose James for in the first place.
That leaves an odd gap: several real mail servers can speak JMAP today, but almost nothing outside Fastmail's own apps can speak it back to them. A JMAP-capable server still has to keep running IMAP too, because that's what every third-party client — the ones on someone's phone, desktop, and everywhere else — actually connects with.
Common Misconceptions About JMAP#
The gap between how much JMAP gets talked about and how few clients support it produces a few recurring wrong ideas.
The biggest one is thinking JMAP is a Fastmail-proprietary format. It isn't — it's an open IETF standard that any mail server or client can implement, and Fastmail's engineers were prominent contributors to writing it, not its sole owners, as the independent server implementations above show.
The second is assuming JMAP is simply "faster" in a way you'd feel on a fast connection with a small mailbox. The gains are real but concentrated in specific conditions: high-latency or flaky mobile connections, large mailboxes doing incremental sync, and battery life on a phone that's checking mail all day. On a desktop client with a good connection and a modest inbox, the difference is close to unnoticeable.
The third is thinking JMAP support is a Fastmail account setting you can toggle. It isn't a setting — it's a protocol your mail client has to speak. If your client doesn't implement JMAP, there's nothing to turn on inside Fastmail to get it.
The fourth is assuming JMAP replaces CardDAV and CalDAV the moment a mail server adopts it. In practice, a server that implements JMAP for mail alongside JMAP for contacts and calendars still needs a client built to call all three — most JMAP-capable servers today, including Fastmail's own, keep serving CardDAV and CalDAV to clients that only know those protocols, exactly the way they keep serving IMAP.

You don't need to do anything
How This Shows Up in AI Emaily#
The reason JMAP matters for a client built around an AI agent is the same reason it matters for battery life: fewer round trips and a delta-based sync model make it cheaper to keep an account's state current without constantly re-polling it.
AI Emaily connects over IMAP today, because that's what Gmail, Outlook, iCloud, Fastmail, and every other provider a user might bring can actually speak — a client that only supported JMAP could serve Fastmail and almost nobody else. We built our own sync engine to get IMAP's incremental-update behavior as close to JMAP's as the protocol allows, rather than waiting on providers to adopt a standard most of them show no sign of moving toward.
We build AI Emaily. If you're on Fastmail specifically, connecting it to AI Emaily today means IMAP, the same as any other provider — see the setup guide linked below if you want the exact steps.
Frequently asked
See it in AI Emaily
Keep reading
Sources

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.