Why Run Your Own Email Server
Email is the backbone of digital identity – your login credential, your recovery method, your professional lifeline. Yet most people hand that backbone over to a handful of corporations that scan, index, and monetize the contents. Self-hosting email has historically been the domain of systems administrators willing to wrestle with Postfix, Dovecot, and a dozen supporting tools just to send a message without it landing in spam. Stalwart changes that calculation. It is a single binary that handles SMTP, IMAP, and JMAP together, written in Rust, with a web-based admin interface and built-in spam filtering that would have taken weeks to configure manually just a few years ago.
The setup process is not trivial – email deliverability depends on DNS records, reverse DNS, and TLS certificates all working in concert – but it is far more approachable than the classic stack. This guide walks through a complete Stalwart installation on a Linux VPS, from initial configuration to sending your first authenticated message through your own infrastructure.
Prerequisites and Server Requirements
You need a VPS with a static IP address, ideally from a provider that allows port 25 outbound and supports setting a custom reverse DNS (PTR) record. Providers like Hetzner, Vultr, and DigitalOcean generally accommodate this, though some budget tiers block port 25 by default and require a support ticket to unlock it. A minimum of 1GB RAM works for light personal use, but 2GB is more comfortable if you plan to run multiple mailboxes. The server should be running a recent Ubuntu or Debian release, and you should have root or sudo access.
Before installing anything, register a domain and point an A record at your server’s IP. You will also need MX, SPF, DKIM, and DMARC records before mail can flow reliably. None of these are optional – skipping any one of them will cause legitimate outbound mail to be rejected or silently dropped by receiving servers. If you are already running a reverse proxy layer on this machine, see the guide on setting up Traefik as a self-hosted reverse proxy with SSL for how to route HTTPS admin traffic without conflicting with Stalwart’s own TLS handling on ports 25, 465, and 993.
Installing Stalwart
Stalwart provides an install script that detects your architecture and pulls the appropriate binary. Run it as root with the following command, replacing the version tag if a newer release is available on the project’s GitHub releases page:
curl -fsSL https://get.stalw.art/install.sh | bash -s -- --components all
The --components all flag installs the mail server together with the web admin interface. The script creates a stalwart-mail system user, places the binary at /usr/local/bin/stalwart-mail, and writes a systemd service file. Configuration lives at /etc/stalwart/config.toml. Before starting the service, open that file and set the hostname field to your mail server’s fully qualified domain name, such as mail.yourdomain.com. This value appears in SMTP banners and TLS certificates, so it must match your DNS.
Enable and start the service with systemctl enable --now stalwart-mail. Check its status immediately with systemctl status stalwart-mail and follow the journal output using journalctl -u stalwart-mail -f. Common startup failures at this stage involve port conflicts – if something is already listening on port 25 or 443, Stalwart will exit with a bind error. Use ss -tlnp to see what holds each port and stop any conflicting service first.
DNS Records and TLS Configuration
Log into Stalwart’s web admin interface, which listens on port 8080 by default. The first-run wizard generates a DKIM key pair and displays the DNS records you need to publish. Copy the DKIM TXT record exactly as shown – any whitespace error will cause signature verification failures that are genuinely difficult to diagnose after the fact.
Publish all four record types in your DNS panel. The MX record points to mail.yourdomain.com with priority 10. The SPF TXT record on the root domain should read v=spf1 mx -all for a setup where only your mail server sends mail. DMARC goes on _dmarc.yourdomain.com as a TXT record with a policy of p=quarantine to start – stricter than none but less punishing than reject while you confirm everything is aligned. Once the records propagate, use the MXToolbox or mail-tester.com to verify all four pass before sending anything to external addresses.
Creating Mailboxes and Testing Delivery
Back in the web admin panel, navigate to the Accounts section and create your first mailbox. Stalwart supports multiple domains and virtual users, so you can host you@yourdomain.com and info@anotherdomain.com from the same instance. Assign a strong password, then configure your mail client – Thunderbird, Apple Mail, or any IMAP client – using port 993 for IMAP with TLS and port 465 for SMTP with implicit TLS. Use your full email address as the username.
Send a test message to a Gmail address and check that it arrives in the inbox, not spam. Open the full message headers in Gmail and look for the Authentication-Results line. It should show spf=pass, dkim=pass, and dmarc=pass all on the same line. If DKIM shows a neutral or fail result while SPF passes, the most likely cause is a mismatch between the selector in your config and the one published in DNS – check both and restart the service after any change to the key configuration.
Stalwart’s built-in spam filter uses a combination of DNS blocklists, header analysis, and Bayes scoring. It works out of the box without training, but improves over time if you configure spam and ham reporting folders. Create a folder called Junk in your mailbox and point the spam-mailbox setting in config to that folder name. Stalwart will learn from messages you move there manually, reducing false positives on mailing lists and newsletters over the first few weeks of use.
Ongoing Maintenance and What to Watch
Self-hosted email requires more active attention than a managed service. IP reputation is the variable that matters most – if your server’s IP lands on a blocklist, outbound delivery stops without any obvious error on your end. Set up automated blocklist monitoring through a service like HetrixTools or MXToolbox’s monitoring product, which will alert you by email if your IP appears on any major list. If it does, the delisting process varies by list but generally requires confirming the cause – usually an outbound spam incident or an open relay misconfiguration – before submitting a removal request.
Keep Stalwart updated by checking the GitHub releases page monthly. Because the project is actively developed, updates often include security patches for TLS handling and spam filter logic. The upgrade process is straightforward: stop the service, replace the binary, and restart. Configuration files are generally forward-compatible within the same major version. Back up /etc/stalwart/ and the data directory – typically /var/lib/stalwart/ – before each upgrade. If something in a new release changes a default that breaks your setup, those backups are the fastest path to recovery.
The real ongoing cost of self-hosted email is not hardware or bandwidth – it is time spent monitoring reputation and deliverability. Running a single-domain personal server on a clean IP from a reputable provider keeps that workload manageable, but the moment you start sending bulk messages or hosting addresses for others, the complexity scales accordingly.
