Mailu

Last reviewed Sep 13, 2026 · 872 words

Mailu will have Postfix, Dovecot, Rspamd, a webmail, and an admin panel receiving mail for your domain in about an hour. Getting the mail you send accepted by Gmail takes weeks, and no amount of Mailu configuration changes that, because it is a property of your IP address and your DNS, not your software. So the order of operations is backwards from what most guides show: check that your provider allows outbound port 25 and will set reverse DNS for you before you write a single compose line. Half the people who abandon self-hosted email never got past that check.

The generator writes the compose file, and that is fine

Mailu's setup page at setup.mailu.io asks 10 questions (domain, hostname, admin address, which webmail, whether you want antivirus, which ports to bind) and emits a docker-compose.yml and a mailu.env. Use it. The generated stack is a set of small images, each doing one job: front (Nginx, TLS termination, all the ports), admin (the web UI and REST API), imap (Dovecot), smtp (Postfix), antispam (Rspamd), webmail (Roundcube or SnappyMail), and optionally antivirus (ClamAV) and fetchmail. That composability is the project's point: MIT-licensed, Python glue, 7,489 stars, and lighter than the suites it competes with. The 2 GB minimum is with antivirus off; ClamAV alone wants another 1 GB for its signature database in memory, and for a household mailbox I leave it off.

Two lines in mailu.env matter more than the rest. TLS_FLAVOR=letsencrypt lets front fetch its own certificate on ports 80 and 443, which means Mailu wants to own those ports on its host or you switch to TLS_FLAVOR=cert and hand it certificates from your existing proxy. And SECRET_KEY must be set once and never changed, since sessions and some internal signing depend on it.

Five DNS records, and the admin panel shows you all of them

After first boot, the admin UI at https://mail.example.com/admin has a domain page that prints the exact records to create. You need an MX pointing at the hostname, an A record (and AAAA if the box has IPv6) for that hostname, an SPF TXT record, a DKIM TXT record with the key Mailu generated, and a DMARC TXT record. The sixth, reverse DNS (PTR) for the server IP matching the hostname, lives at your VPS provider and is the one Mailu cannot display because it is not yours to set. Miss the PTR and large providers will junk or reject you regardless of the other five. The DNS guide for self-hosters walks through each record type.

Then send test mail to a Gmail address and a Microsoft address and read the headers. spf=pass dkim=pass dmarc=pass is the target. A fresh IP with all three passing still lands in spam for the first weeks at some providers; that is reputation, and only volume and time fix it. The honest case for self-hosted email covers whether that is a fight you want.

Updates are one pull, backups are one directory

Mailu pins to a release branch in the generated compose file, and docker compose pull && docker compose up -d moves you along that branch. Read the release notes before changing the branch, because major versions have occasionally changed the storage layout. Everything persistent is under one root, /mailu by default: mail in /mailu/mail, the SQLite admin database, DKIM keys, certificates, and Rspamd's learned data. Back up that tree nightly with the containers running for a routine copy, or stop imap first if you want a guaranteed-consistent Maildir. Losing the DKIM key is not fatal but means re-publishing a DNS record; losing the admin database means recreating users.

Mailu against mailcow and docker-mailserver

mailcow does more: SOGo groupware with CalDAV and CardDAV, a richer admin panel, Solr full-text search, and a larger community, at the cost of roughly 6 GB of RAM and 20-odd containers. If you need shared calendars or you administer mail for 30 people, mailcow is the safer and bigger pick. docker-mailserver goes the other way, one container and no web UI at all, for people who are happy in config files. Mailu sits between them with a UI, an API, Kubernetes manifests, and half mailcow's footprint. The newer contender is Stalwart, a single Rust binary that does IMAP, SMTP, and JMAP in one process; it is worth a look if you are starting fresh in 2026. The email category covers all four.

What I'd do

Confirm port 25 and PTR with the provider first. Generate the stack with antivirus off and SnappyMail as webmail, run it on a VPS with 2 GB and a clean IP, create all 5 DNS records before creating a single mailbox, and test headers at Gmail and Outlook. Keep the real domain on a paid provider for the first month while the new server warms up with low-stakes mail, then move MX. If calendars or more than a dozen users are on the list, deploy mailcow instead and accept the extra 4 GB.