Docker open-source email servers: Linux options compared in 2026

A team replacing employee email needs folders, saved drafts, authentication, and a usable client. A SaaS reply handler needs recipient validation and durable event delivery. The distinction determines whether you’re taking on mailbox administration or operating an application pipeline.

The broader Linux open-source email server reference covers individual protocol components. Here the question is narrower: what does each Docker deployment assemble, and what will remain your responsibility after startup? The comparisons below come from official documentation retrieved on October 14, 2026; they’re not results from a shared performance benchmark.

Compare the service boundary, not the container count

mailcow, Mailu, and docker-mailserver assemble established mailbox components; Stalwart integrates protocols in its own server; MailKite Server centers an application backend. A smaller Compose file isn’t evidence of lower operational effort. Moving persistence into external databases changes where the work happens, not whether it exists.

Project	Primary role	Browser surface	Persistence and deployment boundary
mailcow	Mailbox and groupware suite, including Postfix and Dovecot	Administration plus SOGo webmail/groupware	Multiple service volumes; mailbox data, SQL state, and cryptographic keys need coordinated recovery
Mailu	Docker-based mailbox suite	Administration and selectable webmail	Persistent mail data and administration database; optional components affect resource needs
docker-mailserver	SMTP/IMAP appliance centered on configuration files	Webmail is external	Mail and configuration mounts; no SQL database required by the appliance
Stalwart	Integrated SMTP, IMAP, JMAP and other protocols	Web administration; evaluate an end-user client separately	Configuration plus local or external stores; Community/Enterprise feature boundary
MailKite Server	Inbound parsing, routes, developer API, limited IMAP	Application-oriented web console	SQLite and file blobs; default Compose starts backend/UI, optional profile adds inbound MX

Read the browser column carefully. An admin page that creates a mailbox isn’t the application where someone spends the day reading and organizing mail. Likewise, a message log isn’t automatically webmail. The Linux IMAP comparison examines the folder behavior underneath those interfaces.

mailcow and Mailu suit teams that need managed mailboxes

Start with mailcow when bundled groupware is part of the requirement; start with Mailu when you want a mailbox suite with configurable web access. Both give you a composed system, but they make different decisions about the surrounding user experience.

mailcow includes Postfix, Dovecot, SOGo, filtering, databases, and supporting services. That breadth has a host requirement. As checked in 2026, mailcow’s Prepare your system specifies a default minimum of 6 GiB RAM plus 1 GiB swap and 20 GiB disk before email storage. Those are project requirements, not measurements from this article. Its documentation explicitly excludes OpenVZ and LXC; “Docker runs here” isn’t enough to establish support.

Mailu’s 2024.06 documentation lists IMAP, submission, administration, webmail choices, quotas, aliases, and ManageSieve. Its Compose requirements, retrieved in 2026, specify 3 GB memory plus 1 GB swap with ClamAV, or 1 GB memory plus 1 GB swap without it. Don’t compare those figures as equal-workload benchmarks: enabled scanning, indexing, and concurrency change the workload.

For either suite, write down who owns account recovery and filtering policy. Also decide whether calendars and contacts belong in this service. A team expecting groupware should evaluate that experience directly rather than inferring it from the presence of an IMAP listener.

docker-mailserver suits file-centered operations

Choose docker-mailserver when you want a configurable SMTP/IMAP appliance and already have a plan for clients and administration. Its documentation explicitly describes configuration files instead of an SQL database. That is a real architectural distinction, not a promise that running it needs no maintenance.

The absence of an administration database makes configuration review and versioning natural. It doesn’t eliminate mailbox state, private signing material, or account credentials. Keep secrets out of source control even when the surrounding configuration is versioned. If browser access is required, account for the separate webmail deployment and its own updates and persistence.

The project’s Usage guide calls for a manageable host, domain/DNS control, reachable mail ports, and an appropriate IP/PTR setup. It also insists that documentation match the deployed image version. Follow that pairing when evaluating overrides: a copied Postfix or Dovecot setting can be correct for an older image and wrong for the one you’re deploying.

This is a useful middle ground for an operator comfortable with mail components who doesn’t want to assemble every package manually. It is less suitable when nontechnical administrators need an integrated account-management and groupware interface.

Stalwart integrates protocols, with a separate Enterprise boundary

Stalwart Community includes SMTP, IMAP, JMAP and ManageSieve; Enterprise adds the operational features below. The current edition comparison identifies Community as AGPL-3.0 and Enterprise as commercial.

The same comparison explicitly reserves multi-tenancy, SCIM provisioning, AI-assisted filtering/scripting, read replicas, and sharded blob/in-memory stores for Enterprise. Its licensing FAQ also places dashboards, message delivery history, and metric alerts in the paid feature set. Multiple hosted email domains and tenant isolation are different requirements; don’t treat one as proof of the other.

Stalwart’s Docker guide separates configuration at /etc/stalwart from local data at /var/lib/stalwart. External storage can move data outside the container volume, so the recovery inventory must follow your chosen stores. The guide recommends version-series image tags rather than treating the moving latest tag as an upgrade plan.

Evaluate Stalwart when integrated protocols or JMAP are part of your design. If your decision depends on an operational feature, check its edition before committing to the architecture. A web administration interface still needs to be paired with the client experience your users require.

A running container is only the start of the operating plan

The meaningful deployment milestone is recoverable mail service, not a green container status. A healthy web interface says little about outside-in SMTP reachability, the IMAP certificate clients see, or the contents of the next backup.

For persistence, inventory the complete recovery set. mailcow’s backup documentation lists mailbox, crypt, SQL, Redis, Rspamd, and Postfix components. Restoring message files without the encryption keys needed to read them isn’t a complete recovery. Use each project’s documented backup mechanism and verify a restore separately from the running production instance.

Restore exercise: a replacement host starts every container, accepts a mailbox login, and lists old subjects. Opening an encrypted-at-rest message fails. The backup contains mail files and account data but omits the original encryption keys. Is the restore successful, and would generating fresh keys repair the old mail? Decide before revealing the explanation.

Reveal why a healthy stack can still be an incomplete restore

No: the service has recovered enough account and index state to look healthy, but it hasn't recovered readable message content. Fresh keys cannot decrypt content encrypted with the missing originals. This scenario assumes the deployed mailbox storage actually uses those keys; it isn't a claim that every Docker mail stack encrypts mail at rest.

The next recovery step is to locate the matching original key material in the documented backup or a separate protected recovery copy, then repeat the restore in isolation. If no usable copy exists, those encrypted messages may be unrecoverable. A meaningful pass condition is opening representative pre-backup messages on the replacement host, not merely seeing their subjects or creating new mail.

For networking, inspect both the host firewall and container port publication. Then identify how certificates are renewed for SMTP and IMAP, not just the HTTPS proxy. An HTTP reverse proxy doesn’t automatically provide TLS to a separate mail daemon.

For outbound mail, decide between direct-to-MX delivery and an authenticated relay before choosing the host. Direct delivery makes port availability, reverse DNS, signing, reputation, and queue handling your concerns. A relay changes that responsibility split, but you still need authorized sender identities and visible failure handling. Neither path guarantees inbox placement.

Application workflows need a different recommendation

For application addresses, evaluate the durable ingest and route path before adding full mailbox machinery. The DIY design is an SMTP edge that validates recipients, a backend that stores accepted messages, and a delivery worker that calls your application’s endpoint with retry and authentication behavior. The programmable Linux email server guide compares that layer in more detail.

Disclosure: MailKite Server, which we build, is worth evaluating for that application-first design. It is AGPL-3.0-only and pre-1.0, with a reference Node/SQLite backend, file blobs, routes, and a web console. The actual Compose file starts backend/UI by default; its edges profile adds the inbound Haraka MX service. It does not compose the IMAP or submission heads. Those require the separately documented host deployment and TLS setup.

Its IMAP surface is read-mostly, without arbitrary folder creation, message moves or draft append, and it has no JMAP implementation. The documented reference contract centers INBOX/Sent; the daemon at the reviewed commit also advertises Junk. Check your pinned edge/backend pair rather than assuming that advertised folder provides full spam-folder behavior.

External outbound delivery requires a configured smarthost. The developer API contract is a compatible core send/receive surface, not hosted feature parity: templates, attachment-send fields, and scheduling are refused, while tracking flags are no-ops.

MailKite Cloud is our separate commercial managed product; the open-source page explains that split. Choose Cloud when you want the application workflow without operating the mail infrastructure. Choose mailcow, Mailu, docker-mailserver, or Stalwart instead when full human mailbox behavior is the requirement. Keep an existing Postfix/Dovecot setup when it already meets the job and only an application integration is missing.

Shortlist by the failure you need to prevent

Use the evaluation to eliminate mismatches, then compare the remaining operators’ workload. For a small team, the decisive questions are usually who manages accounts, where users read mail, how state is restored, and who notices delivery failures.

Pick mailcow for bundled mailbox/groupware workflows, Mailu for a configurable mailbox suite, or docker-mailserver for file-centered mail administration. Evaluate Stalwart for integrated protocols and JMAP, with edition requirements written down. Before moving domains, exercise one representative mailbox or application address through your required workflows and a replacement-host restore. A shortlist that survives those checks is more useful than a universal “best server” score.

Sources and refresh policy

Primary documentation retrieved 2026-10-14. Source refresh due 2026-11-13; recheck requirements, image/deployment instructions, editions, and API limitations before publication or a subsequent update.

• mailcow, Prepare your system, retrieved 2026-10-14.
• mailcow, Component backup, retrieved 2026-10-14.
• Mailu, 2024.06 overview and Docker Compose requirements, retrieved 2026-10-14.
• Docker Mailserver, Documentation overview and Usage, retrieved 2026-10-14.
• Stalwart Labs, Compare editions and Docker installation (documentation source), retrieved 2026-10-14.
• MailKite Server, README, Compose definition, IMAP scope, and Developer API, retrieved 2026-10-14.