Email Server Setup for Sovereign Cloud

This document compares two main approaches for personal email in a minimalist sovereign setup:

1. Fully managed privacy-focused service → ProtonMail.
2. Self-hosted mail server on your VPS — with realistic challenges and hybrid options using free SMTP relays.

The goal is low-maintenance personal email (send/receive via custom domain, webmail access, ~10–20 GB total storage budget across all services) while maximizing control and privacy.

ProtonMail – The Managed Option with Caveats

ProtonMail (Switzerland-based) offers encrypted email with a zero-knowledge architecture. It's a strong privacy-focused alternative to consumer Gmail/Outlook, but its architecture and business model have important limitations for the truly sovereign user.

Key Pros

• Strong privacy architecture — Zero-access encryption at rest, meaning Proton cannot decrypt your message bodies on their servers.
• Very high deliverability — Excellent inbox placement (rarely lands in spam) due to established IP reputation.
• Zero setup effort — No server management, no fighting IP reputation, automatic spam filtering.
• Web, mobile & desktop apps — Clean interface, Bridge for IMAP/SMTP (paid plans).
• Custom domain support (paid plans) — Use yourname@yourdomain.com.
• Bundled extras — Calendar, Drive, VPN (in higher tiers).

Critical Cons for the Sovereign User

• No True End-to-End Control: ProtonMail's encryption is not true OpenPGP end-to-end encryption between arbitrary parties. It is a zero-access model within their ecosystem. If you email someone using Gmail, Proton must decrypt your message on their server to send it in plaintext over TLS to Google. You are trusting Proton's servers with the decrypted message at the moment of sending.
• Vulnerable to Policy & Jurisdiction: As a Swiss company, Proton is subject to Swiss law and international pressure. While Switzerland offers strong privacy, it is not immune to geopolitical shifts. A change in company policy, acquisition, or legal ruling could theoretically weaken the current privacy model. The code is open-source, but the service is still a centralized point of control.
• Metadata Still Visible: Subject lines, recipient lists, and timestamps are not encrypted and are visible to Proton.
• Vendor Lock-in: Exporting large volumes of mail is possible but intentionally inconvenient to discourage churn.
• Gmail is the Baseline for "Open Bar": For any non-US user, or any user concerned with US jurisdiction, Gmail represents the extreme opposite of sovereignty. Google's business model is data analysis; their servers have full, unencrypted access to your content. Emails sent to a Gmail address from any server—including ProtonMail—will ultimately be decrypted and stored in Google's indexable, data-mineable format.

Self-Hosted Mail Server – The Sovereign Option

Running your own mail server gives you full control, but comes with significant real-world challenges in 2026. This is the only way to ensure that your communication with Gmail users isn't just a handover of your plaintext to another corporation's servers, as the email will always end up there, but at least you control the sending and receiving infrastructure.

Major Challenges

• Port 25 blocking — Many cheap VPS providers (Hetzner, Vultr, Linode) block outbound port 25 by default. Unblocking is often denied for consumer-tier IPs.
• IP reputation — New/clean VPS IPs are often in spam folders. You must slowly "warm up" the IP over weeks.
• Spam filtering — Your server becomes a target; poor config leads to instant blacklisting.
• Ongoing maintenance — Updates, spamassassin/rspamd tuning, DKIM/DMARC/SPF, cert renewal, log monitoring, backups.

Self-Hosted Stack Options

You have two primary paths: an all-in-one suite or a hand-rolled minimal setup.

Option A: All-in-One Suites (Easiest, but Heavy)

These packages automate the complex integration of Postfix, Dovecot, and a web interface.

• Mail-in-a-Box: A focused Ubuntu-based setup. Good documentation, opinionated design.
• iRedMail: Script-based installer for various Linux distros. Very popular.
• YunoHost: A Debian-based distribution that aims to make self-hosting accessible to non-experts. It uses the classic Postfix + Dovecot + Rspamd stack under the hood, wrapped in a friendly web admin interface for managing users, domains, and email aliases. It's an excellent middle ground for those who want a sovereign mail setup without hand-editing every config file.
• Mailcow: A Dockerized suite. It runs many containers (MySQL, Redis, Solr, Nginx, Postfix, Dovecot, Rspamd, etc.). Default RAM usage is around 3 GB, making it unsuitable for a $3–4 VPS. It requires a server with at least 4 GB of RAM to run comfortably, increasing the base cost.

Option B: Minimalist Hand-Rolled Setup (Lean, but Complex)

This is the most resource-efficient and educational path. You run only the essential daemons on a base OS like Debian or Ubuntu.

• MTA (Mail Transfer Agent): Postfix – Handles sending and receiving mail via SMTP.
• MDA (Mail Delivery Agent) / IMAP Server: Dovecot – Delivers mail to the user's mailbox and serves it to clients (like Thunderbird or K-9 on Android) via IMAP. It also handles authentication.
• Webmail (Optional): Roundcube or SnappyMail – A PHP application that provides a Gmail-like interface in your browser. It connects to Dovecot via IMAP and sends mail via Postfix.
• Anti-spam: Rspamd (modern, fast) or SpamAssassin (classic, heavy).
• Web Server: Nginx to serve Roundcube and handle Let's Encrypt SSL certificates.

Resource usage (light personal use): 300–800 MB RAM idle, 5–15 GB disk.

The Critical Integration: Postfix + Dovecot Auth

In a hand-rolled setup, the most common pitfall is authentication. You do not want to manage separate UNIX system users for every email account.

1. Dovecot as Auth Provider: Dovecot is configured to manage virtual users (often stored in a simple SQLite database or a text file). It becomes the master of user credentials.
2. Postfix as Auth Client: Postfix is configured to hand off SASL (Simple Authentication and Security Layer) authentication requests to Dovecot via a socket.
3. Testing with doveadm: Before you even try to send mail, you must verify Dovecot can authenticate a user.

```bash # Test user 'yourname@yourdomain.com' with password 'testpassword' doveadm auth test yourname@yourdomain.com testpassword # Expected output: "passdb: yourname@yourdomain.com auth succeeded" ``` This command is your admin tool. If this fails, nothing else will work.

Testing the Full Stack with swaks

Once Postfix and Dovecot are talking, you must test the entire mail pipeline. swaks (Swiss Army Knife for SMTP) is the essential tool for this.

• Test Submission (Port 587 - with auth):

This tests if your mail client (Thunderbird) can send mail through your server. ```bash swaks --to your-test@gmail.com \ --from yourname@yourdomain.com \ --server mail.yourdomain.com:587 \ --auth LOGIN \ --auth-user yourname@yourdomain.com \ --auth-password "yourpassword" \ --tls ``` Look for -> 250 OK and <- 250 2.0.0 Ok: queued.

• Test Delivery (Port 25 - incoming):

This tests if your server can receive mail from the outside world. You can telnet to port 25, but swaks is cleaner for a quick test from another machine. If this fails, your MX records or firewall are broken.

Realistic outcome for most individuals: After 1–3 months of configuration and fighting IP reputation, you can achieve a 60–80% inbox rate. It will never be as reliable as the big players, but it is yours.

Hybrid Approach: Self-Hosted Receiving + Free SMTP Relay for Sending

This is the most practical minimalist sovereign setup in 2026, combining the control of a hand-rolled Dovecot setup with the deliverability of a professional sending service.

• Receive emails directly on your VPS via Postfix/Dovecot → full control over storage, privacy, filtering. You own the mailbox.
• Send via a reputable third-party SMTP relay → avoids port 25 blocks & IP reputation problems entirely.

Recommended Free/Low-Cost SMTP Relays (2026)

Top minimalist picks: Brevo for highest volume, SMTP2GO for best reliability.

Personal Setup Note

The author of this guide currently runs a Postfix + Dovecot stack on a minimal VPS, with outbound mail relayed through SMTP2GO (free tier). This setup consumes under 500 MB of RAM, costs ~$4/month for the VPS, and crucially, allows full OpenPGP/GPG encryption at the user level. Unlike ProtonMail's ecosystem-bound encryption, this means emails can be encrypted end-to-end with any correspondent who publishes a public key, regardless of which provider they use. The stack works seamlessly with standard email clients like Thunderbird (desktop) and K-9 Mail (Android), which have built-in OpenPGP support.

Comparison Table – ProtonMail vs Self-Hosted vs Hybrid

Recommendation for Sovereign Cloud Minimalist

Most practical path in 2026:

• Use hybrid setup:
• Self-host a minimal Dovecot + Postfix stack for receiving on a low-resource VPS, or deploy YunoHost if you prefer a web UI for user management.
• Use a hand-rolled setup (Option B) to keep RAM usage under 500 MB, allowing a $3–4 VPS.
• Configure Roundcube as a webmail option, pointing it to Dovecot's IMAP and Postfix's submission port.
• Configure Postfix to relay all outgoing mail through Brevo or SMTP2GO.
• Add proper SPF/DKIM/DMARC records (critical even with relay).
• Set up GPG keys in Thunderbird/K-9 to achieve true end-to-end encryption for sensitive correspondence.

This gives you ~95% of the sovereignty of a pure self-hosted setup with far better deliverability and much less pain. You get the privacy of controlling your stored data, the flexibility of using any email client, and the reliability of a professional sending service. Most importantly, you enable true GPG-based end-to-end encryption that works across all providers, not just within a single ecosystem.

Pure self-hosted only makes sense if:

• You already have a clean residential/static IP.
• You're willing to dedicate significant time to IP warming & blacklist monitoring.
• You accept that your mail to Gmail/Outlook will often be treated as second-class.

Pure ProtonMail is better if privacy + zero hassle is your only goal, and you accept the trade-off of using a centralized service with its own jurisdictional and architectural limitations.