Deploying a self-hosted email server used to be a daunting task involving complex configurations across Postfix, Dovecot, and SpamAssassin, often feeling like a full-time job. However, modern solutions like Stalwart Mail have dramatically simplified this experience, offering an all-in-one, secure, and highly performant email server.
In this post, we’ll share our technical insights and “gotchas” from integrating Stalwart Mail into our automated, sovereign communications stack.
1. Modular, Opt-In Architecture
When building a sovereign cloud, resource efficiency is key. Not every user wants to host their own email right away.
In our RemoteRails communications appliance, we’ve designed Stalwart Mail as an optional module. Under the hood, this is managed simply via a Docker Compose profile. By default, the mail services remain completely shut down and ignored, keeping your server lightweight. When you’re ready to deploy email, you simply toggle it on, and the system effortlessly spins up the mail server without disrupting the rest of the stack.
2. Rust-Powered Performance & Tiered Storage
Stalwart Mail is written entirely in Rust. This modern, memory-safe language choice provides a massive advantage for two key reasons. First, the memory-safe nature of Rust drastically reduces the likelihood of unknown zero-day security vulnerabilities (like buffer overflows) that have historically plagued legacy C-based mail servers. Second, it is extremely light on resources; Stalwart can run blazingly fast using only a fraction of the memory available on a typical VPS or dedicated server.
To complement this performance, Stalwart implements a smart tiered storage architecture. By default, its primary index and database run on the incredibly fast and lightweight RocksDB (which we highly recommend placing on an SSD or NVMe volume). Meanwhile, voluminous email attachments and blobs can be seamlessly offloaded to a standard filesystem (such as an external RAID array of HDDs) or even an S3-compatible object store. This allows you to scale your email storage economically without sacrificing the speed of your core inbox.
3. Security First: The VPN Airgap
A modern self-hosted email server has two distinct faces: the public services and the internal administration.
- Public Access: We only expose the absolute minimum port required for server-to-server mail delivery: inbound SMTP (port 25). This allows your server to receive incoming emails from other providers (like Gmail or Outlook) over the public internet, while keeping the rest of the stack entirely invisible.
- Private Client Access & Administration: Standard email client connection ports (SMTPS, IMAPS, JMAP, autodiscover, and autoconfig), the sensitive administration, and user self-service interfaces are never exposed to the public internet. We aggressively lock these endpoints down using a combination of edge network firewall rules and reverse-proxy IP-whitelisting, restricting all access to a WireGuard VPN tunnel (e.g., Defguard).
This VPN isolation ensures that only authenticated users actively connected to your private VPN can sync their inboxes or access the management portals.
4. Seamless Authentication with OpenID Connect (OIDC)
Managing separate credentials for your email server is a thing of the past. Stalwart has excellent support for OpenID Connect (OIDC), allowing it to plug directly into identity providers like Defguard or Authentik.
Key Configuration Details:
- Ensure your OIDC application provides the
email,name,profile, andgroupsclaims. - Map the Username Claim strictly to
emailto ensure compatibility with standard email clients. - Remember the chicken-and-egg problem: You must manually create your initial administrator user (e.g.,
[email protected]) in the Stalwart panel before attempting to log in through the OIDC portal.
5. The Protonmail Security Model & Web Key Directory (WKD)
Stalwart Mail is currently unique in the self-hosted ecosystem because it adopts the exact same zero-access security model popularized by Protonmail. Through its native PGP integration and the crucial “Encrypt on Append” feature, Stalwart encrypts incoming emails upon receipt—even if they were originally sent unencrypted by the sender. This means for users with a PGP public key uploaded and “Encrypt on Append” enabled, emails are stored with zero-access encryption at rest. (While the server briefly processes the incoming plaintext in memory to apply spam and routing filters, the data written to disk is cryptographically locked). Even the operator of the Stalwart server cannot read them! If an attacker gains full root access to the physical server, they still cannot read the contents of your inbox without your private PGP key.
This true E2E privacy is vastly superior to corporate “encrypted envelope” solutions (such as Microsoft Purview or Cisco’s equivalents) which rely on one-time passwords. Those are merely “tick box” compliance solutions that provide no real E2EE privacy, because the underlying encryption keys remain escrowed by both your organization and the vendor (e.g., Microsoft 365).
Furthermore, Stalwart includes a built-in Web Key Directory (WKD) server. WKD is a modern standard that makes the historically painful process of exchanging PGP keys completely invisible.
To understand the impact of WKD, think back to the Snowden PRISM revelations. Following those leaks, the tech industry pushed to encrypt virtually the entire web (HTTPS), transitioning away from unencrypted HTTP. WKD aims to do the exact same thing for email. When you compose a message, email clients that support WKD—such as Mozilla Thunderbird, eM Client, or Proton’s webmail—will silently ping the recipient’s WKD server in the background. If a public key is found, your client will automatically and opportunistically upgrade your unencrypted email to a fully encrypted E2E (End-to-End) message before it ever leaves your device. This seamless key exchange is critical for encouraging the broader, mainstream use of E2E encrypted email.
Why We Don’t Ship Webmail
You might notice that the RemoteRails appliance does not include a webmail client by default. This is an intentional security decision. Webmail is historically the weakest link in the encrypted email security model because the end user has no visibility into the code being served to them from the server-side. Furthermore, many webmail packages require you to upload your PGP private keypair to the server, drastically increasing your attack surface and risking compromise.
Instead, we recommend using reputable open-source or European desktop and mobile clients where your PGP private key material is exclusively stored and processed on your local device—providing true E2E privacy. Excellent options include Thunderbird (which features a built-in OpenPGP keyring), K-9 Mail / Thunderbird Mobile (paired with the OpenKeychain companion app), or eM Client.
6. Built-in Calendars and Contacts
Stalwart isn’t just an email server; it’s a full groupware suite supporting CalDAV and CardDAV. A standout feature is its support for sending HTML-based calendar invites to both internal and external users. These invites feature intuitive “Yes”, “Maybe”, and “No” response buttons, allowing Stalwart users to easily track the confirmed or unconfirmed RSVP status of all attendees.
NOTE
E2E Encryption Limitation: While Stalwart supports PGP encryption for standard emails at rest and in transit, these interactive calendar invitations are currently sent as standard HTML emails (to support the interactive RSVP buttons). They are not E2E PGP encrypted.
7. Crucial Configuration “Gotchas”
Through our deployment testing, we discovered a few critical settings that are easy to overlook in the Stalwart Setup Wizard:
- Traefik and Real IPs: Since Stalwart sits behind Traefik, you must enable “Obtain remote IP from Forwarded header” (parsing the
X-Forwarded-Forheader). Otherwise, Stalwart will see all inbound connections as originating from the reverse proxy, which breaks rate-limiting and security logging. - Network Whitelists: Docker can dynamically reassign subnets upon recreation. To prevent connectivity breakage, whitelist the broader Docker bridge network (e.g.,
172.16.0.0/12) and your VPN IP range in Stalwart’s “Allowed IPs” security settings. - The “Encrypt on Append” Forensic Trap: Stalwart supports encrypting emails at rest using PGP. While incoming emails can easily be encrypted using your public key, the “Sent” folder is often a massive vulnerability. Computer forensic investigators frequently target the Sent folder because, in many legacy setups, a copy of the outbound message is simply appended there in plain text. Enabling “Encrypt on append” ensures that even the copies saved to your Sent folder are cryptographically secured at rest. For this to work in Stalwart, it must be enabled globally in the server settings in addition to the individual user account level. Note: Changing this global setting requires a full container restart!
- Automated DNS & TLS Certificates: Stalwart natively integrates with APIs from Cloudflare, AWS Route 53, DigitalOcean, Hetzner, and many other DNS providers. This integration allows Stalwart to automatically manage the
dns-01challenge, greatly simplifying the renewal of SSL/TLS certificates. Furthermore, if automatic management is desired, this API connection allows Stalwart to fully automate the provisioning of your mail server’s SRV, MX, SPF, DKIM, and DMARC records! If you are managing DNS manually, you can alternatively bind-mount your own ACME-generated TLS certificates directly into the container.
8. Outbound Deliverability: The External Relay Strategy
Self-hosting inbound email is straightforward, but ensuring outbound emails actually reach a Google or Microsoft inbox (without being flagged as spam) is notoriously difficult due to IP reputation.
To solve this, we recommend routing outbound mail through an external SMTP relay like AWS SES or SendGrid. For example, during a real-life deployment of our appliance on a dedicated OVH server, we discovered the entire IP range was indiscriminately blacklisted by Microsoft, meaning zero emails could reach Outlook or O365 users.
By configuring Stalwart to use Amazon SES as an SMTP relay, we instantly bypassed the blacklist. And because the message body is already PGP encrypted by the sender, AWS SES simply acts as a “dumb pipe” to transmit the cipher-text. (Note: While the body is cryptographically secured, standard email metadata like the Sender, Recipient, and Timestamp remains visible to the relay provider for routing purposes). By doing this, we achieved enterprise-grade deliverability without compromising the zero-access security model!
Stalwart makes configuring a relay easy, but there is one major catch: DKIM Signatures. If you use an external relay like AWS SES with “Easy DKIM” enabled, SES will cryptographically sign your outbound messages. You must disable local DKIM signing for your domain inside Stalwart. The reason for this is that relay providers often slightly modify the message in transit (e.g., rewriting headers or altering line endings). If SES modifies the email after Stalwart has signed it, Stalwart’s original DKIM signature mathematically breaks. Recipient servers will see a broken signature and penalize your spam score. Letting SES handle the sole DKIM signature prevents this issue.
Conclusion
Stalwart Mail is a powerhouse that brings modern, robust, and secure email hosting within reach. However, deploying it correctly alongside reverse proxies, identity providers, and DNS automation involves a steep learning curve.
That’s why we built the RemoteRails communications appliance. We aren’t just providing a hobbyist guide for gluing parts together in a homelab; we provide a professional, pre-integrated appliance product. It bridges the gap between DIY self-hosting and a managed service, offering a thoroughly tested, optimized, and opinionated solution that works securely out of the box.