Linux IMAP mail servers: choose by mailbox behavior

Start with a mailbox contract: can users create folders, move messages, save drafts, share access, and find old mail? Then identify the systems responsible for delivery and identity. A server can accept an IMAP login and display INBOX while still being the wrong backend for your users’ daily mail workflow.

This reference compares documented capabilities, not interoperability results from a common lab. Official sources were checked on October 14, 2026. The broader open-source Linux server guide explains adjacent components; the Docker server comparison covers how suites package them.

Choose the mailbox model before the API surface

Dovecot, Cyrus, Stalwart, and WildDuck are candidates for general mailbox service; MailKite Server exposes a deliberately smaller mailbox view. An HTTP API is useful for provisioning or application access, but its presence doesn’t tell you whether a desktop client’s folder operations will succeed.

Server	Mailbox behavior	Identity and filtering	API and deployment boundary
Dovecot CE	Mailbox storage formats, namespaces and shared-mailbox configuration	Pluggable authentication; Sieve/Pigeonhole integration	Mailbox service commonly paired with an MTA; administration through doveadm and related tooling
Cyrus IMAP	Private mailbox store, ACLs, quotas and shared mailbox behavior	SASL-related identity integrations; server-side Sieve	IMAP plus additional protocols, including build-dependent JMAP; separate MTA integration
Stalwart	General IMAP and JMAP mailbox access	Internal or external directories; Sieve/ManageSieve	Integrated SMTP and mailbox server; operational features differ by edition
WildDuck	General IMAP folders and message operations	Application passwords, account APIs and API-managed filters	HTTP-managed mailbox service with MongoDB/Redis; complete suite adds SMTP components
MailKite Server	Limited read-mostly view; reads, search and flag updates; no arbitrary folder creation, moves or draft append	Domain/address-pattern scoped app passwords	Thin IMAP head over backend-owned state; not JMAP or a full mailbox replacement

For general mailboxes, compare the client operations you need rather than counting advertised extensions. For application addresses, first consider whether an HTTPS mailbox API would avoid maintaining an IMAP synchronization loop. The programmable server comparison covers those application integration choices.

Dovecot is a mailbox service you pair with your delivery system

Dovecot fits when you want control over mailbox storage and authentication while keeping your MTA separate. In a conventional deployment, Postfix or Exim receives external mail and hands local delivery to Dovecot. Dovecot’s 2.4.5 LMTP documentation recommends LMTP for most installations and describes quota and Sieve integration at delivery time.

That separation lets you retain a working SMTP policy and change mailbox operations independently. It also means you’re responsible for the boundary: recipient lookup, identity mapping, delivery sockets, and permissions must agree. A successful SMTP acceptance followed by failed local delivery isn’t repaired by choosing a different desktop client.

Use documentation for the deployed release. The current 2.3-to-2.4 upgrade guide says old configuration won’t work unchanged. It also lists removed features, including director and replicator. An older article’s replication design or configuration fragment is not evidence of current Community Edition support.

Dovecot is a strong shortlist candidate for an existing Postfix/Dovecot installation whose needs remain conventional mailboxes. Don’t replace that system merely to obtain an HTTP endpoint; establish whether administration tooling or a separate application integration already solves the missing requirement.

Cyrus serves richer shared-mailbox requirements

Cyrus deserves evaluation when shared access, mailbox policy, and server-owned storage matter. Its feature documentation describes a sealed system: normal users don’t access mailbox files directly. Clients interact through protocols, and Cyrus owns the private mailbox database.

The documentation explicitly lists mailbox ACLs, hierarchical quotas, namespaces, Sieve filtering, delayed deletion/expunge, and shared seen state. Those are concrete evaluation points for a team mailbox: whose read state is shared, who may delete messages, and how long deleted content remains recoverable? They should become acceptance requirements rather than a generic “enterprise-ready” label.

Cyrus also exposes calendar/contact protocols and documents JMAP support when built for it. Check the actual package build and enabled services instead of promising every installation the complete protocol list. Authentication options include Kerberos, LDAP, and SQL integrations; matching an existing directory still requires a deliberate configuration.

The repository README identifies 3.12 as the stable series and master as 3.13 development at retrieval. Its COPYING file supplies the permissive Carnegie Mellon terms, including an acknowledgment requirement. This isn’t a Community-versus-Enterprise capability matrix. Select a release/package and read the corresponding operational documentation, including its MTA integration.

Stalwart and WildDuck expose different integration boundaries

Evaluate Stalwart for integrated protocols, and WildDuck for HTTP-managed mailbox products. Both can serve human mailboxes, but the systems around their IMAP service differ substantially.

Stalwart’s edition comparison puts IMAP, SMTP, JMAP for Mail, ManageSieve, and ordinary Sieve scripting in the core protocol offering shared by Community and Enterprise. Community is AGPL-3.0; Enterprise is commercial. Multi-tenancy, SCIM provisioning, AI-assisted filtering/scripting, read replicas, and sharded blob/in-memory storage are explicitly Enterprise-only. Multiple email domains don’t imply per-tenant administrative isolation.

WildDuck’s official project page describes APIs for accounts, mailboxes, messages, filters, and auto-replies, alongside IMAP access and application passwords. Its README and license identify EUPL 1.2 or later. Don’t transfer Stalwart’s edition rules to WildDuck: the relevant deployment distinction is the mailbox component versus the surrounding Zone Mail Suite.

The suite architecture names MongoDB for persistent state, Redis for notifications/caching and related coordination, Haraka for inbound SMTP, ZoneMTA for outbound SMTP, and Rspamd for filtering. The Node service is therefore only part of a complete mail deployment. Choose this model when mailbox provisioning is part of your product and those database and transport dependencies fit your operations; a small conventional mailbox installation may not need that architecture.

Human mailboxes and application addresses need different checks

A user-facing mailbox needs lifecycle operations that an application-address reader may never perform. Writing those differences down prevents “supports IMAP” from becoming an accidental promise of full webmail compatibility.

For a human mailbox, use the real client to create a folder, rename it, move mail, save a draft, and delete a message. Check where Sent copies are written; submission and a client’s IMAP append behavior can otherwise create duplicates or leave no expected copy. Include shared access if users depend on it.

For an application address, evaluate credential scope, content retrieval, restart behavior, and retention. Persist a cursor per account and mailbox using UIDVALIDITY and UID: RFC 9051, §2.3.1.1 defines the mailbox-specific identity. If UIDVALIDITY changes, invalidate that mailbox’s cached UIDs and resynchronize. Flags aren’t your application’s durable processing acknowledgment.

Cursor exercise: your importer saved INBOX with UIDVALIDITY=41 and last processed UID=900. After a mailbox rebuild, SELECT reports UIDVALIDITY=42; the rebuilt mailbox contains UIDs 1–120. Would fetching only UIDs above 900 be safe? Write down which state you would discard and which processing records you would retain.

Reveal how to recover from a changed UIDVALIDITY

Fetching only above 900 would miss the rebuilt mailbox. The old cursor belongs to the previous UID namespace: UID 100 under validity 42 is not identified by UID 100 under validity 41. Invalidate this account/mailbox's cached UID mappings and cursor, enumerate its current messages, and establish a new cursor using validity 42. Other mailboxes' cursors do not become invalid just because INBOX changed.

Retain your application's durable processing ledger so resynchronization doesn't blindly repeat external side effects. Reconcile messages against whatever independent identity and idempotency policy your application actually supports; a Message-ID header alone is not guaranteed unique. If you have no reliable cross-rebuild identity, treat duplicate handling as an unresolved recovery requirement rather than marking every low UID as already processed.

The narrow application-address option has explicit limits

When the application owns storage and processing, a thin protocol head can be enough. The DIY version separates an authenticated IMAP daemon from backend endpoints for mailbox status, message listing, raw content, and flag updates. Your backend owns identity and state; the daemon translates client requests. That design reduces duplicated storage logic but also defines what the protocol head cannot do.

Disclosure: MailKite Server, which we build, is an option for this narrower reading workflow. Its documented v1 reference contract centers INBOX/Sent, fetch/search, and flag updates with scoped app passwords. Storage belongs to the backend. The daemon at the same reviewed commit also advertises Junk; verify your pinned edge/backend pair before relying on that folder’s behavior.

Folder creation, moves and draft append are refused; expunge is currently a no-op. There is no JMAP implementation. Don’t choose this head when clients require general folder management or full mailbox migration semantics.

The self-hosted repository is AGPL-3.0-only and pre-1.0, distinct from commercial MailKite Cloud. Its reference SQLite backend needs a configured smarthost for external sending. The developer API implements core send/receive contracts, not the full hosted product: attachment-send fields, templates, and scheduling are unsupported; tracking flags are no-ops. The open-source page describes the self-hosted/managed split.

Use Dovecot, Cyrus, Stalwart, or WildDuck instead when full mailbox behavior is the job. Use the API directly when your application needs content access but no mail client. Cloud is the managed application infrastructure choice when you don’t want to operate the backend and mail edges yourself, not evidence that the reference server has every hosted feature.

Migration acceptance is more than matching message counts

Approve a migration only after content, mailbox state, credentials, and recovery meet your requirements. This is an evaluation walkthrough, not a claim that these servers were tested against each other.

1. Map folders and identity. Inventory namespaces, folder separators, special-use folders, aliases, and shared ACLs. Define what changes for users before importing content.
2. Check flags and dates. Inspect read/flagged state, internal dates, and any client-specific keywords that matter. Record whether your importer preserves them.
3. Inspect content retrieval. Compare representative raw MIME, attachments, encodings, and signed/encrypted messages. If byte preservation matters, evaluate it explicitly rather than relying on a rendered preview.
4. Exercise credentials and policy. Check login, revocation, address/account scope, quotas, filters, and the SMTP submission path separately. IMAP authentication alone doesn’t verify sending.
5. Restore the service. Recover mailbox content, account data, configuration, and necessary keys into a separate environment. Reopen it with the intended client and document what survives.

Keep the existing service available under a defined cutover plan until those checks pass. For a conventional mailbox replacement, client behavior should decide the shortlist. For an application reader, prefer the smallest supported access contract that actually covers processing and recovery.

Sources and refresh policy

Primary documentation retrieved 2026-10-14. Source refresh due 2026-11-13; recheck stable versions, package/build capabilities, edition boundaries, and the thin IMAP scope before publication or a subsequent update.

• Dovecot CE, 2.4.5 LMTP server and Upgrading from 2.3 to 2.4, retrieved 2026-10-14.
• Cyrus IMAP, Features, Repository README, and COPYING, retrieved 2026-10-14.
• Stalwart Labs, Compare editions and Enterprise license, retrieved 2026-10-14.
• WildDuck, Project overview, Zone Mail Suite architecture, Repository README/license, and Database configuration, retrieved 2026-10-14.
• MailKite Server, README, IMAP README, and Developer API, retrieved 2026-10-14.
• IETF, RFC 9051: IMAP4rev2, unique identifiers, retrieved 2026-10-14.