Head to head

Choose your mail platform
with your eyes open.

Stalwart. Zimbra. The Postfix + Dovecot stack. Each is good at what it was built for. Here is what ZephyrAB was built for, row by row — including the rows where we come off worse.

The platform

ZephyrAB

Mail, calendar and contacts built as one system — storage, deliverability, DNS, AI and operations designed together, in Rust. Younger than the other three, and a preview build.

The modern server

Stalwart

A very good modern mail server, and ahead of us on several things — anti-spam, directory integration, Sieve extensions, IMAP4rev2. What it is not is a platform: no DNS server, no reply drafting, no acceptance auditor.

The legacy suite

Zimbra

Twenty years of groupware, carrying twenty years of architecture. Java-era design, storage tied to each server, and an open-source edition that ended in 2023.

The DIY stack

Postfix + Dovecot

The internet's workhorses, and rightly trusted. They give you a mail transfer agent and a mailbox server. Everything else is yours to choose, join up and keep working.

The matrix

Feature by feature

Where someone else does it better, the row says so. Where we do not have it yet, the row says that too.

Built in ~ Partial / assembly required Not available
Capability ZephyrABThe platform* StalwartModern server ZimbraLegacy suite Postfix + DovecotDIY stack
Platform & architecture
Written inMemory safety for every parser that reads untrusted mail Rust, including every parser that reads mail from strangers Rust Java + legacy native components C
How it growsWhat adding capacity costs you Add a cell. 1M mailboxes measured in one; 10M is the design ceiling, not a tested number ~One cluster ~Many servers, but each user lives on one of them ~Per host; splitting users across hosts is your design
Any server can answerSo losing one is not an outage for the people on it No user is tied to a particular server ~Cluster coordination Each mailbox lives on one server State per host; you build the proxy layer
One commit, or noneQuota, flags and the message itself land together or not at all A distributed transactional store; a half-written delivery cannot exist ~Several storage backends; what you get depends which you pick Database plus filesystem, per server Filesystem indexes per host
Where messages are keptWhether storage is a shared pool or bolted to one machine Object storage, addressed by content — one copy of a message sent to fifty people ~Filesystem or S3 Disks attached to each server ~Maildir or mdbox; object storage is in the commercial edition
Multiple customers, kept apartNot just several domains on one box Every stored object carries its tenant; in the base product, not an upgrade ~Supported, in their Enterprise edition ~Domains and class-of-service Virtual domains only
Protocols & product
JMAPThe modern mail API: faster on a phone, one connection The platform's own API, not a side door Proprietary SOAP/REST
IMAPThe protocol most mail apps still speak ~IMAP4rev1 with most rev2 extensions. We do not advertise rev2 until the last few land — see the note below the table IMAP4rev2 ~IMAP4rev1 rev1 and rev2 (Dovecot)
Calendar & contactsCalDAV / CardDAV groupware Integrated, open standards Mature Separate stack (SOGo, Radicale…)
WebmailReading your mail in a browser, without installing anything Ours: mail, calendar, settings, translated and accessibility-audited None shipped; they recommend a third-party client and have their own planned Mature webmail Add Roundcube or similar yourself
Exchange ActiveSyncWhat older corporate phone setups expect Not built. It needs a license from Microsoft; that is a later phase Not built Network Edition
Deliverability & trust
Proving mail came from youDKIM, SPF, DMARC and ARC — the checks that decide inbox or spam Built in, on every message, nothing to configure Built in ~DKIM signing; filtering through bundled amavis; no ARC Separate add-ons: OpenDKIM, Rspamd
MTA-STS and DANEMail between servers stays encrypted and cannot be quietly redirected Built in External tooling
Runs your DNS for youPoint your nameservers at it once; it writes and signs the mail records Its own nameserver, DNSSEC-signed. None of the other three do this Not a nameserver Not a nameserver Not a nameserver
Nothing accepted goes missingOnce we say yes to a message it ends up delivered, bounced or quarantined — never nowhere A ledger of every acceptance, and an auditor that reads it separately from the code that writes it Nothing equivalent in their documentation Nothing equivalent in their documentation Nothing equivalent
Watching your sending reputationBlocklist checks, feedback loops, sending limits, IP pools and warm-up ~Blocklist watch, DMARC and TLS report ingest, provider feedback loops and per-account send limits are running. Separate IP pools and automatic warm-up are not built yet ~Queue routing and throttling ~Assemble it yourself from policyd, Rspamd and friends
Privacy & security
Encrypted with your key, not oursThe server stores text it cannot read Per account, off until you turn it on; we hold no private key. Subjects and addresses stay readable OpenPGP and S/MIME at rest Whole-disk encryption only ~mail_crypt plugin; you manage the keys
When an account is stolenSpot it, stop it, clean up after it ~Sending limits, malware scanning on the way out and an automatic lock. Guided clean-up and a staged return to full rate are not built yet ~Filtering aimed mostly at incoming mail ~Rate limits and bundled antivirus Yours to build
Intelligence
AI sortingSorting mail with a model you choose On the server or in the client; your own model or your own provider account. Off until configured LLM-assisted classification, in their Enterprise edition
AI-drafted repliesA suggested reply you read before it goes anywhere The operator's model or your own; yours wins. Nothing is ever sent for you
AI on an encrypted mailboxSorting mail the server itself cannot read It runs in a client holding your key; neither the key nor the prompt reaches the server
Big attachments become linksExpiring, revocable, optionally password-protected, every download logged Happens as you send, without you doing anything ~Briefcase share links, made by hand
Operations
Admin console and APISet everything up by script, and hand out limited access safely Documented OpenAPI, delegated administration, quotas, long jobs, webhooks Web admin and an API ~Console and an older SOAP API Config files and command lines
Finding one messageAnswering "where did it go?" in seconds, not by grepping logs An OpenTelemetry trace follows a message from arrival to mailbox Metrics and tracing Log files Log files
Is the source code public?Whether you can read it, build it, or fork it if we disappear No. The binaries are free to download and run, including commercially for your own organization; some enterprise features need a license file AGPL-3.0, with an enterprise tier Proprietary subscription; the open-source edition ended in 2023 Open source
The ZephyrAB take

All three are good. Here is the difference.

vs Stalwart

A server is not a platform.

Stalwart is what a modern mail server should look like, and it is ahead of us on anti-spam, directory integration and Sieve. If you are running mail for yourself, take it seriously. If you are running mail for other people, the work is mostly above the server: DNS, an auditor that can prove nothing was lost, drafting your users control, attachment links, and an admin layer built for tenants and delegation. That layer is the point of ZephyrAB.

vs Zimbra

The right idea, built again.

Zimbra was right that mail, calendar and contacts belong together. We are building the same idea on newer foundations: memory-safe code, shared object storage instead of disks bolted to each server, real transactions, and JMAP instead of SOAP. Zimbra still has more groupware than we do — shared calendars and ActiveSync among them. What it also has is an open-source edition that ended in 2023.

vs Postfix + Dovecot

Stop being the integrator.

Postfix and Dovecot carry the internet and have earned every bit of their reputation. What they hand you is a project rather than a product: webmail, calendars, DKIM, spam filtering, failover, DNS and upgrades are seven more projects, and joining them up is your job for as long as you run it. ZephyrAB ships those parts together, from one codebase. If you enjoy that assembly work, they are still the right answer.

The bottom line

Good options exist. We are building the joined-up one.

Your keys, your choice of AI model, and a record of what happened to every message we accepted. Ask us the awkward questions — the table above is where we have already answered a few of them against ourselves.

Talk to us →

* Read the ZephyrAB column as "this is built", not "this is finished". ZephyrAB is a preview build in active development, and a tick means the feature exists and has been tested, not that it has been running in production for years. Several ticks describe features that are off until you configure them. The roadmap says what is done and what is not, milestone by milestone.

On IMAP: we implement IMAP4rev1 plus most of what IMAP4rev2 adds, and deliberately do not announce rev2 support until the rest lands. A server that claims rev2 and then behaves like rev1 breaks clients in ways that are hard to diagnose, so we would rather show the honest mark here.

The other three columns are summarized in good faith from public documentation as of August 2026, and from running Stalwart ourselves as an interoperability partner. Products change and editions differ, open-source against commercial. If we have got something wrong about your product, tell us and we will correct it: hello@zephyrab.com.

Stalwart, Zimbra, Postfix, and Dovecot are trademarks of their respective owners. ZephyrAB is not affiliated with or endorsed by any of them.