Mox

Last reviewed Sep 13, 2026 · 939 words

Run mox quickstart [email protected] on a fresh VPS and about a second later it prints every DNS record your domain needs: MX, SPF, DKIM, DMARC, MTA-STS, TLSA for DANE, and the autoconfig entries that make Thunderbird find the server on its own. Paste them into your DNS, start the service, and you have a mail server that would pass a deliverability audit most hand-built Postfix and Dovecot installs fail. That is the pitch and it is true. What the quickstart cannot fix is the part of self-hosted email that was never about software, and I will spend as much of this guide on that as on Mox.

One binary, no database, no Docker required

Mox is written in Go and ships as one executable. It implements SMTP for receiving and sending, submission for your clients, IMAP4 with the extensions modern clients expect, ACME for certificates, a Bayesian junk filter that learns from what you move between Junk and Inbox, DKIM signing and verification, SPF and DMARC checking, MTA-STS and DANE on both sides, and account and admin web interfaces. Messages are stored in a maildir-like layout with an index per account; there is no PostgreSQL to run. Memory at idle sits well under the 256 MB figure and a 1 vCPU VPS is adequate for a household.

The project documents running it as a plain binary under systemd, and that is what I would do. A Docker image exists at the project's own registry, but mail needs a lot of ports (25, 465, 587, 143, 993, 80 and 443 for ACME and autoconfig) and correct source IPs for outbound, so it wants host networking anyway, at which point the container adds little. The admin interface binds to localhost by default; reach it over an SSH tunnel rather than exposing it.

The IP is the product

Everything hard about email lives outside the software. Port 25 outbound is blocked by nearly every residential ISP and by many cloud providers on new accounts. Mail sent from an IP with no reverse DNS, or from a range that was ever used for spam, goes to the recipient's junk folder regardless of how perfect your DKIM is. Before installing anything:

dig -x 203.0.113.10 +short          # must return your mail hostname
dig mail.example.com +short         # must return 203.0.113.10

Choose a provider that lets you set the PTR record and unblocks port 25 on request, check the IP against a couple of public blocklists, and consider it a bonus if the provider's whole range has a clean reputation. Mox will tell you, in its admin interface and in the quickstart output, when the DNS side is wrong. It cannot tell you that Microsoft has decided your /24 is untrustworthy; you learn that when a message to an Outlook.com address bounces. My longer view on whether the whole exercise is worth it is in self-hosted email, honestly, and I still think most people should not, but Mox is the tool that makes the "should" a closer call.

What you do not get

Don't expect a polished webmail. Mox is a mail server, and you read mail with Thunderbird, Apple Mail, FairEmail or K-9, all of which autoconfigure against it. There is no calendar, no contacts sync, no shared mailboxes with delegation, no groupware of any kind. A team that wants what Google Workspace provides beyond email needs a different shape of project; the Google Workspace alternatives guide lays out the combinations. Sieve-style filtering rules are also limited compared to Dovecot, so heavy filterers should check the current feature list in the documentation first.

Stalwart is the other modern contender

Stalwart is the bigger project in the same "one modern binary replaces the Postfix stack" niche, written in Rust, with JMAP alongside IMAP, a more elaborate admin UI, and a wider set of storage backends. It is more configurable and more ambitious; Mox is simpler and more opinionated. For one domain and a handful of accounts I find Mox the calmer choice, because there is less to configure and therefore less to misconfigure. For an organization that wants JMAP clients, per-user quotas across a database backend, and an admin who enjoys knobs, Stalwart. Both are young relative to Postfix, so pin releases and read changelogs.

Backups and the update cadence

Back up the data directory (config, accounts, message stores and DKIM keys) with the built-in mox backup command, which produces a consistent snapshot, then ship it off-box with whatever you use. Losing the DKIM private keys means rotating DNS; losing the message store means losing mail. Releases arrive every few months and the changelog flags config migrations; Mox verifies its config on start and refuses to run with an invalid one, which is the failure mode you want.

What I'd do

For one or two domains and up to a dozen mailboxes: a 1 vCPU, 1 GB VPS from a provider that sets PTR records, port 25 confirmed open, Mox as a systemd service from the binary, quickstart output pasted into DNS verbatim, and a test message to a Gmail and an Outlook address on day one to see where it lands. Nightly mox backup to another machine. If you want webmail, calendars or shared inboxes, do not bolt them on; pick Stalwart or a groupware suite instead. And keep a paid mailbox somewhere for account recovery emails until the server has run for six quiet months.