For organizations and technically-minded individuals prioritizing privacy, ProtonMail has long been the gold standard for End-to-End Encrypted (E2EE) email. However, as organizations scale, the desire for data sovereignty and infrastructure control often leads engineering teams to explore self-hosted solutions.
Enter Stalwart Mail, a modern, open-source, and highly scalable mail server written in Rust. Its robust architecture has earned the trust of respected privacy authorities; for instance, the non-profit organization Privacy Guides utilizes Stalwart Mail for their own organizational email correspondence, validating its capabilities in highly sensitive environments. But can a self-hosted Stalwart instance truly match ProtonMail’s security model? And how do you solve the notorious deliverability issues that plague independent mail servers?
In this deep dive, we will explore how Stalwart Mail compares to ProtonMail’s security architecture, its relative strengths and weaknesses, and how combining Stalwart with a commercial SMTP gateway (like AWS SES or Postmark) can solve deliverability problems while strictly maintaining PGP-based E2EE trust.
Security Model Parity: Stalwart vs. ProtonMail
ProtonMail’s core value proposition is “zero-access encryption.” Messages are encrypted on the client side using OpenPGP, meaning Proton’s servers cannot read the contents of your inbox.
Stalwart Mail, functioning as a standard (but highly advanced) JMAP/IMAP/SMTP server, does not enforce client-side encryption out of the box. However, when paired with a PGP-capable client (like Thunderbird, Apple Mail with GPGMail, or web clients leveraging Web Key Directory), Stalwart achieves exact security parity with ProtonMail regarding E2EE.
Comparative Strengths & Weaknesses
| Feature | ProtonMail | Stalwart Mail (Self-Hosted + PGP) |
|---|---|---|
| End-to-End Encryption | Local client-side execution via OpenPGP.js (browser) or native apps. | Local client-dependent OpenPGP execution (e.g., Thunderbird). |
| Key Management | Managed by Proton (easy, but relies on trusting their keystore delivery). | User-managed or automated via Web Key Directory (WKD). Requires more setup but removes third-party trust. |
| Data at Rest (Storage) | Mailboxes are natively encrypted. | Achieved via infrastructure-level encryption (e.g., direct filesystem storage on a LUKS encrypted RAID array). |
| Metadata Privacy | Proton can see To, From, Date, and Subject headers (unless using Subject encryption). | You control the server, meaning metadata is kept entirely in-house and out of the hands of third-party providers. |
| Ecosystem Lock-in | High. You must use their apps/bridge. Standard IMAP/SMTP requires the local Proton Bridge. | None. Fully standards-compliant (JMAP, IMAP, SMTP, ManageSieve). |
| Threat Model Focus | Protecting data from the provider and state actors coercing the provider. | Protecting data from external breaches. The Stalwart add-on to the RemoteRails Appliance standardizes a hardened OS, network, and firewall configuration out of the box, alleviating this burden from the end user. |
The Advantage of Server-Side Auditability
While ProtonMail’s client applications are open source, their server-side code is proprietary and closed source. This presents a critical trust blind spot for highly sensitive use cases. For example, when a standard (non-PGP encrypted) email arrives from the internet to a ProtonMail address, the server must process it in plain text before encrypting it into the user’s zero-knowledge mailbox. Because the backend cannot be audited, there is no mathematical proof or absolute certainty that the server isn’t silently archiving, scanning, or logging that plain text prior to encryption.
In contrast, Stalwart Mail is 100% open source. You know exactly what code is executing on your server. When unencrypted mail arrives, Stalwart’s native Encrypt on Append feature securely encrypts the incoming message directly in-memory using your public key, storing only the cipher and immediately discarding the plain text. Because the source code is public and running on your own infrastructure, this cryptographic guarantee can be fully and independently verified.
Crucially, this Encrypt on Append functionality applies to all data written to the server via IMAP or JMAP. This means when your email client saves a message to your Drafts or Sent folders, Stalwart automatically encrypts it with your public key before it ever touches the disk. This is a massive security upgrade; forensic analysts and attackers frequently target Drafts and Sent folders because users often overlook encrypting them, leaving a trove of sensitive outbound communications exposed in plain text.
Seamless Interoperability: Stalwart, ProtonMail, and WKD
A common hesitation when leaving a walled garden like ProtonMail is the fear of losing seamless, secure communication with other PGP and ProtonMail users. Fortunately, Stalwart Mail seamlessly interoperates with the broader PGP ecosystem right out of the box.
This interoperability is powered by Web Key Directory (WKD) support. Instead of forcing you to manually attach your public key to an email and relying on the recipient to accept it (a risky practice known as Trust on First Use), Stalwart automatically serves your uploaded public key via the standardized WKD protocol or integrates with public keyservers like OpenPGP.org.
When a ProtonMail user types your Stalwart email address into their client, ProtonMail automatically queries your domain’s WKD, discovers your public key in the background, and seamlessly encrypts the message before sending it. The experience is identical to emailing another Proton user, bridging the gap between independent servers and commercial E2EE platforms without friction.
The Verdict: ProtonMail abstracts away the complexity of encryption, making it accessible but centralized. Stalwart Mail gives you absolute sovereignty over your metadata and infrastructure. While self-hosting traditionally shifts the burden of operational security (OpSec) onto your engineering team, leveraging the RemoteRails Appliance eliminates this overhead by providing a standardized, pre-hardened deployment.
The Deliverability Nightmare
The biggest technical barrier to self-hosting email is deliverability. Big Tech providers (Microsoft, Google) aggressively filter inbound email based on IP reputation. If you spin up a Stalwart Mail server on a standard cloud VPS (DigitalOcean, Hetzner, AWS EC2), you will almost inevitably encounter bounce errors like this:
host outlook-com.olc.protection.outlook.com rejected command
MAIL FROM:<[email protected]> SIZE=1623 with code 550 (5.7.1)
Unfortunately, messages from [192.0.2.1] weren't sent.
Please contact your Internet service provider since part of their network
is on our block list (S3140).
This happens because Outlook, Gmail, and Yahoo often preemptively block entire IP subnets assigned to popular hosting providers. Even if your specific IP address is completely clean and brand new, you are penalized because other users on that same hosting provider have used neighboring IPs to send spam in the past.
Building IP reputation from scratch on a “bad neighborhood” subnet is a losing battle that takes months of low-volume, high-engagement warming—and even then, a single false positive can land your IP on a permanent blocklist. This is why configuring a dedicated SMTP relay through a highly reputable provider is not just an optimization; it is crucial for reliably reaching the inboxes of major email services.
The Solution: SMTP Gateways & E2EE Trust
To drastically improve deliverability to strict receivers like Outlook and Gmail, we configure Stalwart to route outbound mail through a trusted SMTP Gateway (or “Smart Host”) like AWS SES, Postmark, or Mailgun.
A common concern arises here: “Doesn’t routing through AWS SES ruin my End-to-End Encryption and privacy?”
The answer is No, provided you are using PGP.
When you send a PGP-encrypted email, the encryption happens on your local device before the message reaches your Stalwart server. By the time Stalwart forwards the message to AWS SES, the message body and attachments are mathematically unreadable ciphertext.
What the SMTP Gateway Sees (Trust Model)
The table below illustrates exactly what information is exposed to the SMTP Gateway when routing a PGP-encrypted message:
| Data Component | Exposed to SMTP Gateway (AWS SES, Postmark) | Can Gateway Read/Modify? | Why it’s Safe |
|---|---|---|---|
| Envelope Sender (MAIL FROM) | Yes ([email protected]) | Yes | Required for SMTP routing and bounce processing. |
| Envelope Recipient (RCPT TO) | Yes ([email protected]) | Yes | Required to deliver the message to the final destination. |
| Message Headers (Date, etc.) | Yes | Yes | Standard SMTP metadata. |
| Email Subject | Yes (Usually) | Yes | Note: Modern PGP/MIME (RFC 8551) supports “Memory Hole” or encrypted subjects, replacing the outer subject with “Encrypted Message”. |
| Message Body (Text/HTML) | No (It sees only PGP Ciphertext) | No | AWS SES sees an unrecognizable blob of PGP data. They cannot decrypt it without the recipient’s private key. |
| Attachments | No (Encrypted within the PGP blob) | No | Gateway cannot scan attachments for content or malware. |
Using an SMTP gateway trades metadata privacy (AWS knows who you are emailing) for maximized deliverability (though no service can offer a 100% guarantee, as domain reputation and content filtering still apply), while absolutely preserving the content privacy of the E2EE model.
Technical Nuances: DKIM vs. PGP Signatures
When routing outbound mail through AWS SES or Postmark, the gateway will typically strip your server’s DKIM signatures or apply its own DKIM signature to authenticate the message against your DNS records.
Some engineers worry that if AWS SES modifies the headers to apply DKIM, it will invalidate the PGP cryptographic signature, breaking trust. This is a misconception.
Here is how the authentication layers interact:
- PGP Signatures (Content Authentication): Your email client cryptographically signs the internal content of the message (the body and attachments) using your PGP Private Key. This signature is embedded inside the payload (either inline or as a
multipart/signedPGP/MIME attachment). - SMTP Relay (Stalwart -> SES): The encrypted and signed payload is sent to AWS SES over a TLS-encrypted connection.
- DKIM Signing (Transport Authentication): AWS SES takes the email, calculates a hash of specific outer headers (From, To, Date, Subject) and the outer body (which is just the PGP ciphertext block), and applies a DKIM signature using a key verified in your DNS.
Because AWS SES only manipulates the outer SMTP headers and wraps the payload without altering the bytes of the PGP ciphertext, the inner PGP signature remains perfectly intact.
When the recipient’s email client (e.g., Thunderbird) receives the email, it first verifies the DKIM signature to confirm the email came from your domain’s authorized sender (SES). Then, it decrypts the payload and verifies the PGP signature to prove that you explicitly wrote the message and that it wasn’t tampered with in transit.
A Note on Attachment Sizes and MIME Limits
When relying on an SMTP gateway to transmit PGP-encrypted messages, it is critical to understand how file attachments affect your overall message size. Because binary attachments must be Base64-encoded for SMTP transport, their size bloats by approximately 33%. A 10 MB attachment will actually consume closer to 13.5 MB of your total message allowance over the wire.
If your organization routinely sends large encrypted assets (such as logs, design files, or datasets), choosing the right SMTP provider is essential.
Here is a comparison of total message size limits across major SMTP providers:
| SMTP Provider | Max Total Message Size Limit | Notes |
|---|---|---|
| SMTP2Go | 50 MB | Best-in-class limit, ideal for heavy attachments. |
| AWS SES | 40 MB | Highly generous limit, though files over 10 MB may experience slight throttling. |
| SendGrid | 30 MB | Solid middle-tier limit. |
| SparkPost | 20 MB | Represents the maximum Base64-encoded size limit. |
| Mailjet | 15 MB | Lower allowance, requiring stricter attachment policies. |
| Postmark | 10 MB | Highly restrictive limit. Not recommended if your workflow relies on large, encrypted file transfers. |
As highlighted above, while Postmark is legendary for its raw transactional speed, its restrictive 10 MB size limit can be a severe bottleneck for E2EE email users sending anything beyond basic text and small PDFs. Services like AWS SES and SMTP2Go provide significantly higher limits, accommodating the overhead of Base64 encoding and large encrypted payloads natively.
Conclusion
Migrating from ProtonMail to a self-hosted Stalwart Mail infrastructure does not mean sacrificing security. By leveraging standards-based PGP and intelligent architectural routing, you can achieve the zero-knowledge content privacy of ProtonMail while retaining total data sovereignty.
By utilizing AWS SES or Postmark strictly as a dumb transport layer for encrypted ciphertext, you completely sidestep the self-hosted deliverability nightmare—ensuring your communications actually reach your clients’ inboxes while remaining cryptographically secure.