Most self-hosted email guides assume you enjoy assembling software from parts. Stalwart Mail Server takes the opposite bet: one binary, written in Rust, that speaks SMTP, IMAP, and JMAP, does its own DKIM signing, stores mail in its own store or S3, and hands you a web admin UI. After setting it up on a fresh VPS and living with it, I think it is now the least painful way to run your own mail — with a few caveats nobody mentions.
Before you touch a server
Three things decide whether self-hosting is even possible for you, and none of them are software:
- Port 25. Most cloud providers block outbound port 25 by default. Some unblock it after an account-age check; some never do. Confirm this before you buy anything.
- Reverse DNS (PTR). Big receivers check that your IP’s PTR record points back at your mail hostname. Setting it is a checkbox in your VPS panel; skipping it costs you deliverability you cannot buy back.
- IP reputation. Ask whether your provider’s IP ranges are on blocklists. A fresh IP from a spammy range starts life in the junk folder.
Installation, for real
On a Debian or Ubuntu box, installation is one script and a few minutes. The binary runs as a systemd service, and the admin interface listens on your configured HTTPS port. Point your browser at it, set the administrator password, and most of your first hour is spent in DNS records rather than configuration files.
The DNS records that matter
Stalwart generates most of what you need, but you should understand what each record does before pasting it:
- MX — tells the world where mail for your domain arrives.
- SPF — authorizes your server’s IP to send for the domain. Keep it to one record, no more.
- DKIM — Stalwart generates the keypair; you publish the public half. Sign everything.
- DMARC — start at
p=nonewith report collection, watch the reports, then tighten. - Autodiscover/SRV records — make client setup pleasant.
If any of that paragraph felt like a foreign language, read our plain-English SPF/DKIM/DMARC guide first. These records are the whole game in deliverability.
The first-week checklist
The default configuration is genuinely sane, which is Stalwart’s quiet superpower. Things I still changed in week one: enforcing TLS certificates from Let’s Encrypt for the mail hostnames, enabling the built-in spam checks and quarantines rather than accepting defaults blind, and setting up outbound throttling so a bug in my own code cannot turn my server into a cannon. Backups came next — Stalwart can store mail in S3-compatible storage, which makes off-site backup semantics trivially boring, exactly as they should be.
Living with it
Two weeks in, the honest ledger looks like this. Wins: JMAP is a delight for programmatic access; the admin UI removes most of the Postfix-plus-Dovecot assembly tax; memory usage is a fraction of the classic stack. Costs: the community is smaller than Postfix’s, so when something breaks at 2 a.m. you may be reading source code instead of a forum post; and some ancillary tooling in the wider ecosystem still assumes the classic split of SMTP/IMAP daemons.
Should you?
Self-host if email is your identity and you want sovereignty over it, or if you love the machinery. Use a hosted API provider if email is only a feature of your product — the opportunity cost of deliverability babysitting is real. If you go hosted for transactional but self-host your personal mailbox, that hybrid is exactly what I settled on. Our Postfix in 2026 piece covers the classic stack if you want the traditional route, and our warmup guide applies to your own server too — a new IP needs gentle treatment just like a new domain.
Where to start
Check port 25 and PTR on a provider first, deploy Stalwart on the smallest VPS that fits, send yourself mail at Gmail, and read the headers. Every lesson you need is inside those headers.