Why I Spent a Week Mapping Open Source Mail Servers by Role

Most "best open source mail server" lists are misleading. They throw a full-stack Docker bundle and a single SMTP daemon into the same ranked table, as if you're picking one from a menu. You're not. A mail server is five distinct jobs — inbound MX, filtering, storage, IMAP serving, and outbound submission — and every project on this list fills one, some, or all of them. Once you know which slot you need, the field narrows to about three real candidates.

The acceptance test for any mail server is the same three commands, and I'd run them before reading another line of documentation. Two check the server itself. The third checks the thing that actually determines whether your mail arrives:

# 1. does it accept mail on :25 for a domain it claims to own?
swaks --to [email protected] --server mail.example.com:25 --tls

# 2. does it serve that mailbox back over IMAP with a real cert?
openssl s_client -connect mail.example.com:993 -quiet -crlf

The first command verifies your SMTP edge accepts inbound mail. The second confirms IMAP retrieval works with TLS. Run both before you commit to a stack — they'll save you hours of debugging deliverability issues later.

Here's how the 23 projects break down by role in the mail path. I grouped them because the grouping tells you what you're actually buying.

Inbound MX and SMTP reception. This is the front door. Postfix remains the dominant choice here — mature, well-documented, enormous ecosystem — but if you want something more modern and modular, Haraka (Node.js) or Exim give you different trade-offs in config complexity and plugin flexibility.

Filtering and reputation. Rspamd is the standout. Written in C, Apache-2.0 licensed, with Bayesian classification, fuzzy hashing, greylisting, and DKIM/ARC signing built in. It replaced SpamAssassin in nearly every deployment I looked at, and it's noticeably faster on the same hardware. If you're running a high-volume inbound path, this is the component you tune most aggressively.

Mail storage and IMAP serving. Dovecot is the workhorse — C, LGPL-2.1 with MIT-licensed parts, 1,233 stars on the core repo, last commit August 4 2026. Its Sieve implementation handles server-side filtering, and its LMTP and auth services are what Postfix hands mail to. The low star count is an artifact of a project that predates GitHub as a center of gravity, not a measure of actual use. Nearly every bundle ships Dovecot as the IMAP layer.

Full-stack bundles. Projects like mailcow and Stalwart pack multiple roles into a single deployment. mailcow is the practical choice if you need human mailboxes with calendars and contacts — it's groupware, and it isn't close to anything else in the open source space for that use case. Stalwart is newer but impressively fast, written in Rust, and worth watching if you want a modern all-in-one.

Application-oriented mail handling. If your goal is an AI agent or a web application owning an address and reacting to mail as an event, the full groupware stack is overkill. The shape that makes sense is a lightweight SMTP receiver plus a webhook pipeline — which is where tools like MailKite fit. The SDK approach lets you verify incoming webhooks with a single function call, matching the same signature logic whether you're running self-hosted or against a hosted service.

The part every roundup skips. Self-hosting mail still costs you after the install script says done. You're managing DNS records (SPF, DKIM, DMARC), watching blacklist status, handling bounce queues, and maintaining TLS certs. The install script solves the first hour; the ongoing deliverability work is the real cost. Budget for it or use a service that absorbs it.

If you're deploying from scratch, start by picking your slot, run the two verification commands above, and only then evaluate the projects that fill that role. The list stops being a popularity contest and becomes a shortlist.