Most "best open source mail server" lists put a full-stack Docker bundle and a single SMTP daemon in the same ranked table, as if you'd choose between them. You wouldn't. This is 23 Linux mail projects grouped by the slot they fill in the mail path, with licenses, languages, and activity verified on 2026-08-05, plus the part every roundup skips: what self-hosting still costs you after the install script says done.
Start with the slots, not the projects. A mail server is five distinct jobs wearing one
name, and every project below fills one, some, or all of them. Once you know which slot
you're shopping for, the list stops being a popularity contest and turns into about three
real candidates.
Whichever you install, the acceptance test is the same three commands, and it is worth
running them before you read another word of documentation. Two of them check the server.
The third checks the thing that actually decides whether your mail arrives.
# 1. does it accept mail on :25 for a domain it claims to own?
swaks --to you@example.com --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 <<'EOF'
a login you@example.com hunter2
a list "" "*"
a logout
EOF
# 3. does your sending IP have reverse DNS that matches your HELO name?
dig +short -x "$(curl -s https://ifconfig.me)"
Command 3 is not part of any project's install script, and it is the one that fails. An
IP with no PTR record, or a PTR that doesn't match the name your server announces in
EHLO, gets your mail filed as spam by Gmail and Outlook no matter which of these 23
projects is behind it.
Everything below was checked against each project's repository on 2026-08-05: license
from the actual LICENSE file, language, star count, and the date of the last commit.
Star counts are a proxy for attention, not quality, and I've said so where the two
diverge.
The MTAs: they move mail and nothing else
An MTA speaks SMTP. It accepts a message on port 25, decides whether to take it, and
either drops it into a local store or queues it for delivery elsewhere. It does not serve
you a mailbox, filter spam, or render a web UI. Three of the four below have been doing
this since before most of us had email addresses, which is the point: they are the least
surprising software in your stack.
Postfix
The default answer, and usually the right one. C, dual-licensed under
EPL-2.0 or IPL-1.0 since 3.2.5, written by Wietse Venema as
a security-first replacement for Sendmail. Its architecture is a set of small processes
with narrow privileges talking over pipes, which is why its CVE history is as quiet as it
is. Nearly every bundle further down this page is Postfix plus a wrapper. Configuration
is a flat main.cf of key-value pairs, and it's readable, but the map/transport/restriction
vocabulary takes a weekend to learn properly.
Exim
C, GPL-2.0-or-later, stable at 4.99.5 as of 2026-07-22. The Debian default for years and
the engine behind most cPanel hosts. Exim's distinguishing feature is a genuinely
programmable configuration language with string expansions, routers, and transports, so
you can express routing logic in the config that would need a plugin elsewhere. That
power has a cost: Exim has shipped several remote-code-execution CVEs where Postfix
shipped none, largely because more of the message path runs in one privileged process.
Pick it when you need its routing expressiveness, and subscribe to the security list.
OpenSMTPD
C, ISC license, from the OpenBSD project. The configuration file is the pitch: a working
mail server in about six lines, with a grammar closer to pf than to main.cf. It is
audited to OpenBSD standards and deliberately implements a subset of SMTP rather than all
of it. If you run OpenBSD, or you want the smallest correct thing that can accept mail,
this is the one. Portable builds for Linux exist and are maintained, though they lag the
OpenBSD release.
chasquid
Go, Apache-2.0, 978 stars, last commit
2026-06-07. Written for small personal servers by one maintainer who kept it small on
purpose: SMTP in, SMTP out, hooks for aliases and spam filtering, no store of its own.
It is the modern-language equivalent of OpenSMTPD's philosophy, and it pairs with Dovecot
the same way. A single-maintainer project is a real risk to weigh, but the codebase is
small enough that you could read all of it in an afternoon.
The all-in-one servers: the whole path in one binary
These replace the classic Postfix-plus-Dovecot-plus-Rspamd assembly with a single
process. It's a genuine architectural argument, not just packaging: one config file, one
set of credentials, one thing to upgrade, and no gluing an MTA's idea of a user to an
IMAP server's idea of a user. The trade is that you are betting on a younger codebase in
the position where the old ones have thirty years of hostile-internet exposure.
Stalwart
Rust, dual-licensed AGPL-3.0 and a commercial Enterprise license,
14,017 stars, last commit 2026-08-03. The most
protocol-complete project on this page: SMTP, IMAP4, JMAP, POP3, CalDAV, CardDAV, and
WebDAV in one server, with built-in spam filtering, DKIM/ARC signing, and full-text
search. JMAP support in particular is close to unique here. It's also the most actively
developed, which cuts both ways: features land fast, and the config surface has changed
between minor versions. Read the upgrade notes before you apt upgrade.
mox
Go, MIT, 5,768 stars, last commit 2026-08-02. mox's design
goal is that a competent person can run a personal mail server without becoming a mail
administrator. One binary, a quickstart command that generates your DNS records and
systemd unit, and sane defaults for SPF, DKIM, DMARC, MTA-STS, DANE, and TLSRPT out of
the box. It ships DANE and MTA-STS support that several older projects still don't. If
you want one domain, a handful of mailboxes, and to stop thinking about it, mox is the
shortest honest path.
maddy
Go, GPL-3.0, 6,055 stars, last commit 2026-07-24. The
selling point is composability: maddy models the mail path as pipelines of modules you
wire in its config, so you can swap the storage backend or the auth source without
swapping servers. It hits a nice middle ground between "one opinionated binary" and "six
daemons and a socket map." Development is steadier than fast, which for mail software is
not the worst property.
The bundles: the classics, assembled
These aren't servers. They're curated stacks (usually Postfix, Dovecot, Rspamd, and a
webmail) plus provisioning, TLS automation, and an admin UI. You get a working mail host
in an afternoon and inherit whatever opinions the maintainers baked in. That is a fair
trade for most people, as long as you know you're now debugging the wrapper as well as
the components.
docker-mailserver
Shell, MIT, 18,661 stars, last
commit 2026-08-03. A single container with Postfix, Dovecot, Rspamd, ClamAV, and Fail2ban,
configured by env vars and a setup CLI. No database and no admin web UI on purpose:
accounts live in a flat file, and the project treats "no persistent state we manage" as a
feature. The most popular project on this page by stars, and the easiest to reason about
when it breaks, because it's just the classics in a box.
mailcow: dockerized
GPL-3.0, 13,229 stars, last commit
2026-08-04. The opposite bet: a full docker-compose stack (Postfix, Dovecot, Rspamd,
SOGo, Nginx, MariaDB, Redis) with a polished admin panel, per-domain quotas, ActiveSync,
and calendars and contacts through SOGo. If you're replacing a small-business Exchange or
Google Workspace and non-engineers will use the admin UI, this is the strongest option
here. Budget the RAM: a dozen containers is not a $5 VPS workload.
Mail-in-a-Box
Python, CC0-1.0 (public domain), 15,377 stars,
last commit 2026-05-24. One setup script turns a clean Ubuntu box into mail, webmail,
contacts, calendar, DNS, and a status console that tells you exactly which DNS records
are wrong. Explicitly designed for one box, one owner, no customization, and it says so:
deviate from the supported layout and upgrades will fight you. The slowest commit cadence
in this group, which reflects a project that considers itself finished more than one that
is stalled.
Mailu
Python, MIT, 7,421 stars, last commit 2026-07-27.
Docker-compose stack in the mailcow tradition, with a lighter footprint and a Kubernetes
path that actually works. Web admin, optional webmail, per-user filters. A good middle
choice if mailcow feels heavy and docker-mailserver feels too bare.
iRedMail
Shell, GPL-3.0, 1,834 stars, last commit
2026-07-22. Installs the classic stack straight onto the host (no containers) across
several Linux and BSD distributions, backed by OpenLDAP, MySQL, or PostgreSQL. The
open-source edition is complete; the good admin panel is the paid iRedAdmin-Pro, which is
worth knowing before you plan around it. Choose it when you want packages on metal and an
LDAP directory rather than a compose file.
Modoboa
Python (Django), ISC, 3,528 stars, last commit
2026-08-04. Not a mail server: a management layer over Postfix and Dovecot, with domain
and mailbox admin, per-user DNS record checks, a calendar, and a REST API. Reach for it
when you already run the classics and the thing you're actually missing is a control
panel with an API you can automate against.
The programmable ones: mail as an event in your application
This is the category that behaves differently from everything above. The projects here
assume the recipient is not a human with a mail client but a program: a support tool that
turns replies into tickets, a CI system that accepts commands by email, an AI agent with
its own address. What you want from a mail server in that case is not a mailbox. It's a
well-formed event delivered to your code, with the MIME already parsed and the
authentication already checked.
Haraka
JavaScript, MIT, 5,613 stars, last commit 2026-08-04.
A high-performance SMTP server built as a plugin bus: every phase of the SMTP conversation
(connect, mail, rcpt, data_post) is an event you can hook in JavaScript, so you
can reject a recipient with a live database lookup or hand the parsed message to your own
code. It is the most flexible way to put application logic inside the SMTP conversation
itself, and it's what we run as our own MX edge. It gives you a programmable SMTP server,
not a finished product: storage, auth, retries, and the web UI are yours.
WildDuck
JavaScript, EUPL-1.2, 2,106 stars, last commit
2026-08-04. An IMAP and POP3 server that stores mail in MongoDB instead of on a
filesystem, so mailboxes replicate and shard the way the rest of your infrastructure
does, with no local state on the mail nodes. It also exposes a full REST API over
mailboxes, which is unusual and useful. The right pick when you're building a mail
product for many users rather than hosting mail for a company.
ZoneMTA
JavaScript, EUPL-1.2, 668 stars, last commit
2026-07-20. Outbound only, and specialized: named delivery zones let you bind different
traffic to different IPs, so transactional mail and bulk mail stop sharing a reputation.
Per-zone throttling, connection pooling, and hooks for rewriting messages in flight. Low
star count for how good it is at its one job.
Postal
Ruby, MIT, 16,719 stars, last commit
2026-08-03. The self-hosted answer to SendGrid or Mailgun: a full sending platform with
an HTTP send API, per-organization credentials, click and open tracking, bounce
processing, suppression lists, inbound routes that POST to a URL, and a real dashboard.
If your requirement reads "we need a transactional email API but the data has to stay on
our infrastructure," Postal is the closest open-source match. It expects MariaDB, RabbitMQ,
and someone to keep them alive.
MailKite Server
JavaScript (Node ≥ 22.5), AGPL-3.0, github.com/mailkite/server,
v0.5.0, first public release 2026-08-01. This is ours, and it exists because of a specific
gap in the list above: the programmable projects each solve one slot well (Haraka the SMTP
conversation, WildDuck the store, Postal the sending platform), and an application that
wants to receive mail has to assemble three of them plus the parsing, the signing, and
the retry logic.
MailKite Server is that assembly, built so that every protocol daemon is stateless and all
state sits behind one small HTTP contract: five IMAP read endpoints, an inbound ingest
hook, an SMTP auth check, and a relay endpoint
(docs/contract.md). The
bundled zero-dependency SQLite backend and MailKite Cloud are two implementations of the
same contract, so the Haraka MX edge, the submission edge, the IMAP head, and the web
console run unchanged against either. One MX edge can serve several backends at once,
routing each recipient domain to its owner.
git clone https://github.com/mailkite/server && cd server
docker compose up -d # backend + web console on :8787
docker compose --profile edges up -d # adds the MX edge on :25
Mail that arrives is POSTed to your app as parsed JSON, signed with an
x-mailkite-signature: t=<unix>,v1=<hex> header. Verifying it is one call from the SDK,
and because the self-hosted server and the hosted service sign identically, the same
handler works against both:
import { MailKite } from "mailkite";
export async function POST(req) {
const raw = await req.text();
const ok = MailKite.verifyWebhook(
req.headers.get("x-mailkite-signature"),
raw,
process.env.MAILKITE_WEBHOOK_SECRET,
);
if (!ok) return new Response("bad signature", { status: 401 });
const { from, subject, text, attachments } = JSON.parse(raw);
await handleIncomingEmail({ from, subject, text, attachments });
return Response.json({ status: "ok" });
}
Honest scope: it's pre-1.0, the SMTP and IMAP edges run our production mail but the SQLite
backend and console are new, and it is not a groupware server. If you want mailboxes for
humans with calendars and contacts, mailcow or Stalwart is a better fit and it isn't
close. If you want an application (or an AI agent) to own an address and react to mail as
an event, this is the shape we think that should take, and you can run the whole thing
yourself. MailKite Cloud, which we build and which pays for this
work, is the same contract with the deliverability and retention handled; the DIY path
above is deliberately complete so you never need it.
The supporting cast
Three projects that aren't mail servers but appear in almost every deployment on this
page.
Dovecot
C, LGPL-2.1 with MIT-licensed parts, 1,233 stars on the
core repo, last commit 2026-08-04. The IMAP and POP3 server that nearly every bundle here
ships. 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 use.
Rspamd
C, Apache-2.0, 2,501 stars, last commit 2026-08-04.
The spam filter that replaced SpamAssassin nearly everywhere: fast, with Bayesian
classification, fuzzy hashing, greylisting, reputation tracking, and DKIM/ARC signing
built in. It also handles the signing side of DMARC alignment, so it often does more than
filtering in a modern stack. If you already run Postfix and your only problem is spam,
adding Rspamd is a smaller change than replacing your server.
Roundcube
PHP, GPL-3.0, 7,114 stars, last commit
2026-07-25. The webmail your users will actually see, sitting on top of whatever IMAP
server you chose. Roundcube Elastic is the modern responsive skin, and the plugin API
covers most of what people ask for. SOGo (bundled in mailcow) is the alternative when you
need calendars and ActiveSync alongside mail.
If what you want is a newsletter, not a mail server
Two projects worth naming because people land on mail-server roundups when this is what
they actually need. Neither speaks SMTP to the internet on its own; both hand mail to
something that does (Postfix, SES, or any relay).
listmonk (22,624 stars, Go, AGPL-3.0, last commit
2026-08-03) is a single self-contained binary plus Postgres: subscriber lists, campaign
templating, per-campaign analytics, and a fast admin UI. The highest star count on this
page.
Keila (2,180 stars, Elixir, AGPL-3.0, last
commit 2026-08-01) covers the same ground with a friendlier editor and a GDPR-first
posture, which is why it shows up in European deployments.
Every project, one table
Verified 2026-08-05. Stars are rounded; "last commit" is the most recent push to the
default branch.
| Project | Slot | Language | License | Stars | Last commit |
|---|---|---|---|---|---|
| Postfix | MTA | C | EPL-2.0 / IPL-1.0 | n/a | active |
| Exim | MTA | C | GPL-2.0-or-later | n/a | 4.99.5, 2026-07-22 |
| OpenSMTPD | MTA | C | ISC | n/a | active |
| chasquid | MTA | Go | Apache-2.0 | 1.0k | 2026-06-07 |
| Stalwart | all-in-one | Rust | AGPL-3.0 / commercial | 14.0k | 2026-08-03 |
| mox | all-in-one | Go | MIT | 5.8k | 2026-08-02 |
| maddy | all-in-one | Go | GPL-3.0 | 6.1k | 2026-07-24 |
| docker-mailserver | bundle | Shell | MIT | 18.7k | 2026-08-03 |
| mailcow | bundle | Shell / JS | GPL-3.0 | 13.2k | 2026-08-04 |
| Mail-in-a-Box | bundle | Python | CC0-1.0 | 15.4k | 2026-05-24 |
| Mailu | bundle | Python | MIT | 7.4k | 2026-07-27 |
| iRedMail | bundle | Shell | GPL-3.0 | 1.8k | 2026-07-22 |
| Modoboa | admin layer | Python | ISC | 3.5k | 2026-08-04 |
| Haraka | programmable SMTP | JavaScript | MIT | 5.6k | 2026-08-04 |
| WildDuck | IMAP + store | JavaScript | EUPL-1.2 | 2.1k | 2026-08-04 |
| ZoneMTA | outbound MTA | JavaScript | EUPL-1.2 | 0.7k | 2026-07-20 |
| Postal | sending platform | Ruby | MIT | 16.7k | 2026-08-03 |
| MailKite Server | app / agent mail | JavaScript | AGPL-3.0 | new | 2026-08-04 |
| Dovecot | IMAP + store | C | LGPL-2.1 / MIT | 1.2k | 2026-08-04 |
| Rspamd | filter | C | Apache-2.0 | 2.5k | 2026-08-04 |
| Roundcube | webmail | PHP | GPL-3.0 | 7.1k | 2026-07-25 |
| listmonk | newsletter | Go | AGPL-3.0 | 22.6k | 2026-08-03 |
| Keila | newsletter | Elixir | AGPL-3.0 | 2.2k | 2026-08-01 |
What none of them fix
Every project on this list will accept mail on port 25 within an hour. None of them can
make anyone else accept mail from you, and that is where self-hosted email actually goes
wrong. Four things decide it, and all four are outside the software:
- Port 25 is blocked on most residential ISPs and on several cloud providers by default. Check before you build. Some providers unblock on request, others never will.
- Your IP has a history you didn't write. Cloud IPs get recycled. A fresh instance can arrive already on a blocklist because of whoever had it in March, and no amount of correct configuration overrides that.
- PTR records live at your hosting provider, not in your DNS zone, and they must match the hostname your server announces. This is command 3 at the top of this page, and it's the single most common miss.
- Warming is real for volume. Sending a thousand messages on day one from a new IP is the behavior of a spammer, and receivers model it that way.
None of this argues against self-hosting. It argues for being honest about the job: the
install is an afternoon, the reputation is a practice. A common and entirely reasonable
split is to receive on your own server, where reputation doesn't matter much, and relay
outbound through a service whose IPs are already warm.
How to pick
The decision is almost never "which is best." It's "which sentence sounds like me."
If you're still undecided after that, the default that disappoints the fewest people is
mailcow for human mailboxes and Postfix plus Dovecot plus Rspamd for anything you intend
to operate for a decade. Both are boring in the way infrastructure should be.
And if you got here because an application of yours needs to receive email rather than
host it, that's a different problem with a different shape, which is
why we open-sourced our answer to it.
Originally published at mailkite.dev. I'm Gabe; I build MailKite, and MailKite Server (AGPL-3.0) is #18 on the list above.
Top comments (0)