ProFor.Pro Profor.Pro
profor.pro / notes / self-hosted-email-2026-mailcow-stalwart-mailu
Email Linux 5 min read

Self-hosted email in 2026: mailcow vs Stalwart vs Mailu

A practical comparison of mailcow, Stalwart, and Mailu based on what we actually deploy for clients in 2026, with notes on resource use, deliverability, and operational pain points.

Running mail yourself in 2026 is still unfashionable, and still occasionally the right answer. GDPR-sensitive clients, lawyers, accountants, small ISPs, and a surprising number of dev shops keep asking us to set it up. After a few years of cycling through stacks, we’ve settled on three that we actually deploy: mailcow, Stalwart, and Mailu. Here is how we choose between them.

None of this removes the hard part: warming the IP, keeping reverse DNS clean, and surviving Microsoft’s silent blocks. The MTA is the easy bit.

The short version

  • mailcow — our default for SMB clients with 10–500 mailboxes who want a polished webmail and admin UI.
  • Stalwart — our pick for technical teams, low-resource VPS, or anyone who wants a single Rust binary instead of a container zoo.
  • Mailu — when the client already lives in Kubernetes or wants a minimal, transparent compose stack to audit themselves.

mailcow: dockerized

mailcow is the most batteries-included of the three. You get Postfix, Dovecot, Rspamd, ClamAV, SOGo, Nginx, Redis, and MariaDB wired up in a single docker-compose.yml.

What we like:

  • The admin UI is genuinely good. Domain admins, ACLs, quotas, sieve filters, DKIM rotation — all clickable.
  • SOGo gives users CalDAV/CardDAV without extra moving parts. iOS and Thunderbird just work.
  • Rspamd integration is mature. Bayes training, neural module, greylisting — all preconfigured.
  • The update flow (./update.sh) is reliable in our experience.

What hurts:

  • Memory floor is around 4–6 GB realistic. Don’t try it on a 2 GB VPS.
  • ClamAV alone wants a gigabyte. We disable it for clients that have upstream scanning.
  • Backups are your problem. The official scripts work, but restoring to a different host requires care with volumes and the DKIM keys in Redis.

A minimal deploy still looks like this:

git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh
docker compose pull
docker compose up -d

Then point MX, SPF, DKIM, DMARC, and PTR. Skipping any of those four means your mail lands in spam, period.

Stalwart: the Rust monolith

Stalwart Mail Server has matured fast. By 2026 it covers SMTP, IMAP, JMAP, ManageSieve, and includes its own spam filter and storage backend. It ships as one binary (or one container) and stores data in RocksDB, FoundationDB, or your SQL of choice.

What we like:

  • Resource usage is dramatically lower. We run small clients on a 1 vCPU / 2 GB instance and it idles fine.
  • Native JMAP is a real feature if you want a modern client like a JMAP-aware mobile app.
  • One config file (config.toml) in TOML. Diffing changes in git is pleasant.
  • Built-in DKIM, ARC, DMARC reporting, MTA-STS, and TLS-RPT. All the modern stuff is first-class.
  • The included spam filter is competitive enough that we haven’t missed Rspamd on most deployments.

What hurts:

  • The web admin is functional but not as polished as mailcow’s. Power users won’t mind; end-customers will.
  • No bundled webmail. We pair it with Roundcube or pick a JMAP client. That’s another container to manage.
  • No CalDAV/CardDAV yet in the configurations we run. If the client needs shared calendars, this is a dealbreaker.
  • Smaller community. When something breaks at 2 AM, you’re reading source, not Stack Overflow answers.

Quick start with Docker:

docker run -d --name stalwart \
  -p 25:25 -p 587:587 -p 465:465 \
  -p 143:143 -p 993:993 \
  -p 4190:4190 -p 8080:8080 \
  -v /opt/stalwart:/opt/stalwart \
  stalwartlabs/mail-server:latest

Then finish setup through the web installer on :8080.

Mailu: compose, transparent, opinionated

Mailu is the middle path. It’s a docker-compose stack of well-known components — Postfix, Dovecot, Rspamd, Roundcube/SnappyMail, optional ClamAV — glued by a small Python admin app.

What we like:

  • The setup wizard at setup.mailu.io generates compose files you can read top-to-bottom. No magic.
  • Each service is a single, well-known upstream image. Debugging is straightforward.
  • Kubernetes Helm chart exists and is maintained. We’ve put Mailu behind an ingress without drama.
  • Lower memory footprint than mailcow if you skip ClamAV.

What hurts:

  • The admin UI is bare-bones compared to mailcow. Domain admins get less power.
  • No bundled groupware. You bolt Radicale on the side if you need calendars.
  • Upgrades between major versions occasionally need manual migration steps. Read the changelog.

How we actually pick

A rough decision tree from our intake calls:

  • Client wants webmail, calendar, contacts, and a UI their office manager can use → mailcow.
  • Client is technical, wants a small VPS, doesn’t need shared calendars → Stalwart.
  • Client has Kubernetes, or wants a stack they can audit component-by-component → Mailu.
  • Client has more than ~1000 mailboxes or strict HA requirements → none of the above out of the box. We build with Postfix + Dovecot director + a real object store, or push them to a hosted provider.

Things that matter more than the MTA choice

No matter which one we deploy, the same boring checklist decides whether mail actually reaches Gmail and Outlook:

  1. Static IP with clean reputation. Check it on multiple RBLs before you even install anything. If the IP is dirty, ask the provider for a different one or move on.
  2. PTR record matches HELO matches A record. All three. Mismatch is an instant trust hit.
  3. SPF, DKIM, DMARC. All published. DMARC starts at p=none with rua= reporting until you’ve validated alignment for two weeks.
  4. MTA-STS and TLS-RPT. Cheap to publish, real signal to receivers.
  5. Outbound rate limiting. New IPs sending in bursts get throttled. Warm up over weeks, not hours.
  6. Monitor DMARC aggregate reports. Parse them. Postmaster tools at Google and Microsoft too.

What we don’t recommend in 2026

  • Hand-rolling Postfix + Dovecot + Rspamd from scratch for a client. The above projects do it better and you’ll pay for the maintenance burden later.
  • iRedMail Pro for greenfield deploys. It still works, but the licensing model and update cadence push us toward the three above.
  • Running mail on the same host as anything else. Keep it isolated. When the IP gets blocked — and someday it will — you don’t want to migrate three other services with it.

Closing note

In our setup, mailcow handles the majority of client mailboxes, Stalwart is growing fast on smaller deployments, and Mailu fills the Kubernetes-shaped niche. None of them will save you from a bad IP or a misconfigured DNS record. Pick the one whose operational model you actually want to live with for three years, because that is roughly how long it takes before the next migration looks tempting.

— need similar work done?

If what's described here resembles your situation — drop us a line. We'll talk through how we'd approach it for you.