Stop Trusting Your Email to Corporations: Set Up Your Own Mail Server with S/MIME Encryption

This week, 404 Media reported that Proton Mail — the company that built its entire brand on privacy — handed over payment data to the Swiss government, which passed it directly to the FBI. That data was used to unmask an anonymous protestor connected to the Stop Cop City movement in Atlanta [1].

Let that sink in. The email contents were encrypted. The metadata wasn't. And that metadata was enough.

Proton's response to this reporting has been to attack 404 Media and critics online rather than address the structural problem: if a third party holds your data, a third party can be compelled to surrender it. This isn't a Proton-specific failure — it's the fundamental limitation of trusting any corporation with your communications. Swiss privacy law didn't save that protestor. End-to-end encryption didn't save that protestor. The payment information Proton collected did them in.

The only way to close that gap is to own the infrastructure yourself. This guide walks you through setting up your own mail server using Stalwart and encrypting all stored email with your S/MIME certificate — so that even if someone gains access to your server, the messages on disk are unreadable without your private key which only you have.

By the end of this guide, you'll have:

• A working mail server handling SMTP, IMAP, and JMAP
• TLS encryption for all connections via Let's Encrypt
• Properly configured DNS records (MX, SPF, DKIM, DMARC)
• S/MIME encryption at rest — every incoming message encrypted before it hits the disk
• A setup where not even you, as the server administrator, can read stored messages without the private key

Prerequisites:

• A Linux server (VPS or dedicated) with a public IP address — Ubuntu 22.04 or later recommended
• A registered domain name with access to DNS management
• Basic comfort with the Linux command line
• About 30-60 minutes of focused time
• An S/MIME certificate for your email address (we'll cover where to get one)

Why Not Just Use Proton?

This isn't about Proton being uniquely bad. They are, in many ways, better than Gmail or Outlook for privacy. But "better" is not the same as "sufficient," and the Stop Cop City case illustrates exactly where the model breaks down.

When you use any hosted email provider, you're trusting them with at minimum:

• Your IP address and login times
• Payment information tied to your real identity
• Email metadata (who you email, when, how often)
• Recovery email addresses and phone numbers
• Any data their jurisdiction's government compels them to hand over

Proton encrypts the contents of your email. That's real and meaningful. But the FBI didn't need the contents — they needed the payment data, and Proton had it because Proton processed the payment.

When you run your own mail server, you control what data exists in the first place. If you choose a VPS where you can pay in cash or crypto, you can ensure that problem will not happen for you.

If you have an email that is hosted at a large provider, there is a simple method for organizations to request information about you. If you have a custom domain and make your own mail server in another country, you can be more trouble than your worth to investigate.

I want to state again, this is for educational purposes only.

Architecture Overview

Here's what we're building:

1. Stalwart Mail Server — an all-in-one mail server written in Rust that handles SMTP (sending/receiving), IMAP (client access), and JMAP (modern client access) in a single binary
2. Let's Encrypt — automated TLS certificates so all connections are encrypted in transit
3. DNS records — MX, SPF, DKIM, and DMARC so other mail servers trust your messages
4. S/MIME encryption at rest — incoming messages are automatically encrypted with your public certificate before being written to disk

The key insight with Stalwart's encryption at rest: the server encrypts each message with your S/MIME public key on arrival. The private key never touches the server. Even if someone compromises the server, gains root access, and dumps the entire mail store — they get encrypted blobs. Without your private key (which lives on your devices, not the server), the messages are useless.

Step 1: Prepare Your Server

Before installing Stalwart, make sure your server's hostname and DNS are configured. You'll need an A record (and AAAA if you have IPv6) pointing your mail domain to your server's IP address.

For example, if your domain is example.com and you want mail handled at mail.example.com:

mail.example.com.    A       203.0.113.10
mail.example.com.    AAAA    2001:db8::10
example.com.         MX  10  mail.example.com.

What this does: The A/AAAA records tell the internet where your mail server lives. The MX record tells other mail servers "when you have mail for @example.com, deliver it to mail.example.com." The 10 is a priority value — lower numbers are tried first, which only matters if you have multiple MX records.

Make sure the following ports are open in your firewall:

sudo ufw allow 25/tcp    # SMTP (receiving mail from other servers)
sudo ufw allow 465/tcp   # SMTP over TLS (submission)
sudo ufw allow 587/tcp   # SMTP with STARTTLS (submission)
sudo ufw allow 993/tcp   # IMAP over TLS
sudo ufw allow 443/tcp   # HTTPS (web interface and JMAP)
sudo ufw allow 8080/tcp  # Web admin interface (initial setup only)

What each port does:

• 25 — This is how other mail servers deliver messages to you. Without this, you can't receive email from the outside world.
• 465/587 — These are how your email clients (Thunderbird, Apple Mail, etc.) send outgoing messages through your server. Port 465 uses implicit TLS; port 587 uses STARTTLS.
• 993 — IMAP over TLS, the standard way your email client retrieves your messages.
• 443 — HTTPS for the web admin interface and JMAP protocol access.
• 8080 — The default admin interface port during initial setup. You'll want to lock this down after you enable TLS.

Step 2: Install Stalwart

Stalwart ships as a single binary. The installation script handles downloading the right version for your architecture and setting up the systemd service.

curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh -o install.sh
sudo sh install.sh

What this does: Downloads the official install script over a TLS-secured connection (the --proto '=https' --tlsv1.2 flags enforce this), then runs it with root privileges. By default, Stalwart installs to /opt/stalwart. The script creates a systemd service, sets up the default RocksDB storage backend, and generates your initial admin credentials.

Important: The installer will print an admin username and password to the terminal. Write these down. You'll need them to access the web interface.

After installation completes, verify the service is running:

sudo systemctl status stalwart

You should see active (running). If not, check the logs:

sudo journalctl -u stalwart -f

Step 3: Initial Configuration via Web Interface

Open your browser and navigate to http://your-server-ip:8080/login. Log in with the admin credentials the installer gave you.

Set Your Hostname

Navigate to Settings > Server > Network and set your server hostname to your mail domain (e.g., mail.example.com). This is the identity your server presents during SMTP conversations with other mail servers.

Add Your Domain

Go to Management > Directory > Domains and add your domain (e.g., example.com).

What this does: Stalwart will generate the DNS records you need — MX, DKIM, SPF, and DMARC. It creates a DKIM signing key for your domain and shows you the exact DNS records to add at your registrar or DNS provider.

Copy each DNS record Stalwart generates and add them to your domain's DNS configuration. These typically include:

• MX record — if you haven't added it already
• SPF record — a TXT record that tells receiving servers which IPs are authorized to send mail for your domain
• DKIM record — a TXT record containing your public signing key, so recipients can verify your messages haven't been tampered with
• DMARC record — a TXT record that tells receiving servers what to do when SPF or DKIM checks fail

If you've read the north.engineer guide on email headers [2], you already know why each of these matters. If not, the short version: without these records, your outgoing mail will land in spam folders or get rejected outright.

Create Your User Account

Navigate to Management > Directory > Accounts and create your email account. Set a strong password — this is the password you'll use in your email client and for the encryption management interface.

Step 4: Configure TLS with Let's Encrypt

Stalwart supports automatic TLS certificate provisioning through ACME (the same protocol Let's Encrypt uses). This means your server will automatically obtain and renew TLS certificates.

In the web interface, navigate to Settings > Server > TLS and enable ACME. Point it at Let's Encrypt's directory URL and configure it for your domain.

What this does: Your server will automatically request a TLS certificate from Let's Encrypt, proving it controls your domain. Once issued, all SMTP, IMAP, and HTTPS connections will be encrypted in transit. The certificate renews automatically before expiration.

After enabling TLS, restart Stalwart:

sudo systemctl restart stalwart

You should now be able to access the admin interface at https://mail.example.com (port 443) instead of the unencrypted port 8080. Once you've confirmed HTTPS works, consider firewalling off port 8080.

Step 5: Get an S/MIME Certificate

Before you can enable encryption at rest, you need an S/MIME certificate for your email address. This certificate contains the public key Stalwart will use to encrypt your messages on arrival.

You have a few options:

Option 1: Actalis (Free, 1 year validity)
Actalis offers one free S/MIME certificate per email address. It's a real CA-signed certificate, which means other mail clients will trust it for signing as well. Visit their site, request a certificate for your email, and follow their verification process. You'll receive a PKCS#12 (.pfx) file.

The trade-off of this convenience is you don't get to create and hold your private key to decrypt your email. I don't recommend this method, but if you struggled to get this far, you may want to do this and come back later to finish creating something you own.

Option 2: Self-signed (Free, you control validity)
If you don't need other people's mail clients to trust your certificate for signature verification — and for encryption at rest, you don't — you can generate your own. This is what I'd recommend for pure encryption-at-rest use:

# Generate a private key
openssl genrsa -aes256 -out smime-key.pem 4096

# Create a certificate signing request
openssl req -new -key smime-key.pem -out smime.csr \
  -subj "/CN=you@example.com/emailAddress=you@example.com"

# Self-sign the certificate (valid for 10 years)
openssl x509 -req -days 3650 -in smime.csr \
  -signkey smime-key.pem -out smime-cert.pem

What each command does:

• openssl genrsa — Generates a 4096-bit RSA private key, encrypted with AES-256. You'll set a passphrase here. This is the key that decrypts your messages — guard it with your life.
• openssl req — Creates a certificate signing request. The -subj flag sets the common name and email address embedded in the certificate.
• openssl x509 — Self-signs the certificate with your private key, making it valid for 3,650 days (10 years).

Critical: Your private key (smime-key.pem) never goes on the server. It stays on your devices — your laptop, your phone, wherever you read email. The only file that goes to Stalwart is the public certificate (smime-cert.pem).

Create a .p12 file to use in your mail clients

You'll want to bundle them into a single PKCS#12 (.p12) file. This is the format most email clients (Thunderbird, Apple Mail, iOS, Outlook) expect when importing an S/MIME identity.

openssl pkcs12 -export -inkey smime-key.pem -in smime-cert.pem -out smime.p12

You'll be prompted for your private key passphrase (the one you set during generation), then asked to set an export password for the .p12 file. Use something strong — this password protects the bundle when you transfer it to your devices. Anyone with this file and the export password has your signing and decryption identity.

Import the .p12 file into your email client or operating system, and keep a backup somewhere secure and offline. If you lose this file and haven't backed up the private key separately, your encrypted mail becomes permanently unreadable.

Step 6: Enable Encryption at Rest

This is where the magic happens. Navigate to your Stalwart encryption management page:

https://mail.example.com/account/crypto

Log in with your email account credentials (not the admin account — your personal mail account).

1. Select S/MIME as your encryption method
2. Upload your public certificate file (smime-cert.pem)
3. Click Update

What this does: From this point forward, every plain-text email that arrives via SMTP is automatically encrypted with your S/MIME public key before it's written to disk. The message lands on the server already encrypted — at no point is the unencrypted message stored.

Send yourself a test email from an external account to verify it's working. When you access it through your email client (which must have the corresponding private key installed), you should be able to read it normally. If you were to look at the raw message on the server's filesystem, it would be encrypted and unreadable.

A Note on What This Does and Doesn't Protect

Encryption at rest protects the contents of your stored messages. If someone compromises your server, dumps the database, or gets physical access to the hardware, they get encrypted blobs.

It does not encrypt email metadata — sender addresses, recipient addresses, subject lines, timestamps. That metadata is necessary for the mail server to function. It also doesn't protect messages in transit beyond what TLS provides (which is why TLS configuration matters too).

The combination of TLS (protecting messages in transit) and S/MIME encryption at rest (protecting messages on disk) gives you defense in depth. Neither alone is sufficient. Together, they make your mail server a genuinely hard target.

Your sent mail is not automatically encrypted with every email client either. You may want to clear out your sent folder at times.

Step 7: Configure Your Email Client

You'll need to configure your email client with both your mail account and your S/MIME private key.

Mail account settings:

• Incoming: IMAP, mail.example.com, port 993, SSL/TLS
• Outgoing: SMTP, mail.example.com, port 465, SSL/TLS (or port 587 with STARTTLS)
• Username: your full email address
• Password: the password you set when creating the account

S/MIME private key:

Import your private key into your email client. In Thunderbird, this is under Account Settings > End-To-End Encryption > S/MIME. In Apple Mail, importing the .p12 file into Keychain Access is usually sufficient — Mail picks it up automatically. On iOS, you can install the certificate profile through Settings.

Once imported, your client will automatically decrypt the S/MIME-encrypted messages from your server. You should also be able to sign outgoing messages if you're using a CA-signed certificate.

The Honest Trade-offs

Running your own mail server is not trivial, and pretending otherwise would be dishonest. Here's what you're signing up for:

You are the sysadmin now. If the server goes down at 2 AM, that's your problem. If a software update breaks something, you're the one fixing it. Stalwart is remarkably stable and low-maintenance compared to the Postfix/Dovecot stack, but "low-maintenance" is not "no maintenance."

Deliverability is an ongoing battle. Major providers (Gmail, Outlook) are suspicious of mail from small, independent servers. Having correct SPF, DKIM, and DMARC records is the minimum. You may also need to monitor your IP's reputation and set up proper reverse DNS. This is solvable, but it takes attention. If you try to start a newsletter from this, or use a funky domain name like eatmyspam.ru, you're shooting yourself in the foot.

You need backups. Your encrypted mail is only as safe as your backup strategy. If the server dies and you don't have backups, those messages are gone. And remember — the backups will contain encrypted messages, so you still need your private key to read them. Lose the private key, lose the mail. Back up the key separately and securely. A server level backup most providers give you is enough.

Self-hosting doesn't make you anonymous. Your server has an IP address. Your domain has WHOIS records (even with privacy protection). Running your own mail server gives you control over your data — it doesn't make you invisible. For anonymity, you need additional layers (VPN, Tor, etc.).

Remember, privacy is the goal here. Raise the bar and make it more difficult to target you. Allegedly.

Closing Thoughts

The Proton Mail story isn't surprising if you've been paying attention to how these systems actually work. Every third-party service, no matter how well-intentioned, is one legal request away from becoming a liability. The encryption was never the weak point — the business relationship was.

Running your own mail server puts you back in control of that relationship. You decide what data exists. You decide what gets logged. You decide what gets encrypted. The trade-off is complexity and responsibility, and that trade-off isn't right for everyone. But if you've read this far, it's probably right for you.

Your private key, your server, your rules.

Footnotes:

[1] 404 Media — "Proton Mail Helped FBI Unmask Anonymous Stop Cop City Protestor" — https://www.404media.co/proton-mail-helped-fbi-unmask-anonymous-stop-cop-city-protestor/

[2] North Engineer — "How to Read Email Headers" — https://north.engineer/how-to-read-email-headers/