Buyer's guide
The Private Email Server Software That Fits in a Cloudflare Account
Shop for private email server software and you'll meet two very different products wearing the same three words. One is a full mail server in a trench coat — capable, heavy, yours to keep alive. The other is a few hundred lines of code and a key that fits inside an account you already have. Telling them apart before you buy is most of the job, so here's the matrix and the questions that do it.
Both families can honestly call themselves private and self-hosted. The data is yours in each. What differs is everything around the data — what you operate, what you protect, what the bill tracks, and what happens the day the maker walks away. A buyer who knows which family a product belongs to, and has asked the handful of questions that expose the rest, almost never regrets the choice.
The two families, by name
Full classic suites bundle every piece of a mail system — a mail transfer agent, a storage backend, a spam filter, a webmail client — into one package you install on a server and run continuously. In practice that means a stack like Postfix (the MTA that moves the mail) paired with Dovecot (the IMAP server that stores it), usually wrapped by an installer such as mailcow, Mailu, or iRedMail that assembles the whole set on a virtual machine you then keep alive. Lightweight edge software does the opposite: it hands the heavy, always-on protocol work to a platform and keeps only the parts that define ownership — the code that receives and seals your mail, and the key that opens it. Blue Folder is this family: a Cloudflare Worker behind Email Routing, a few hundred lines small, with no virtual machine at all. Neither is wrong. They're built for different buyers.
One difference you can see: adding a domain
Naming the families stays abstract until you watch them do the same small job — point a new domain at your mail. The step that differs tells you most of what you'll be operating afterward.
- Postfix/Dovecot: edit the server's config and reload the daemon. You append the name to
virtual_mailbox_domainsin/etc/postfix/main.cf, provision the mailbox in Dovecot, runsystemctl reload postfix, and check that the box's reverse DNS and sending reputation cover the new traffic. It's a change on a machine you keep running. - Edge app like Blue Folder: add three DNS records —
MXtoroute1.mx.cloudflare.net,route2.mx.cloudflare.net,route3.mx.cloudflare.net— and the Worker that's already deployed catches the mail unchanged. No file to edit, no daemon to reload, nothing new to keep alive.
The feature matrix
Read this top to bottom as a decision, not a scoreboard. Each row is a question the two families answer differently, and the right answer depends entirely on who you are.
| What you're evaluating | Full classic suite | Lightweight edge software |
|---|---|---|
| What you run | An always-on server, patched and monitored | On-demand code; nothing runs between messages |
| Sending reputation | Yours to build and defend, tied to one IP | Carried by the platform's sending infrastructure |
| Moving parts to keep healthy | Several services, all at once | A receiving function and some storage |
| Where the key lives | Depends on the suite — verify it | On your device, derived from your passkey |
| Skill it assumes | A comfortable system administrator | Someone comfortable editing DNS |
| Cost shape | Ongoing server rental, scaling with load | Flat, low platform cost for services used |
| Time to stand up | A project | An afternoon |
| If the maker disappears | You keep running it — if you can operate it | You keep the source and the key; little to operate |
| Best fit | Tinkerers who enjoy the craft | Owners who want the result, not the job |
The question isn't "which mail server should I run?" It's "how little do I need to run to truly own my email?" For most buyers, the honest answer is a lot less than the old stacks assume.
Questions to ask before you commit
Once you've picked a family, these five questions separate software you can trust with your mail from software you can't. Good products answer all five without flinching; a dodge on any one of them is itself the answer.
- Who holds the key? The only acceptable answer is "you, on your device." If the operator can reconstruct your key, the privacy is a promise, not a property of the system — and promises change hands when companies do.
- Do I get the source? You should be able to read exactly what the software does and keep running it if the maker vanishes. "Trust us" is not a security model, and a binary you can't inspect is a black box you're renting.
- What are the honest limits? A trustworthy vendor volunteers them without being asked: inbound mail is plaintext for the instant before it's sealed, and outbound mail still passes through a sending provider. Storage, at rest, holds only ciphertext. Anyone claiming "unhackable" or "100% private" has told you something more useful than they meant to.
- Does my bill grow with my addresses? It shouldn't. Watch for designs that quietly recreate the per-mailbox meter you were trying to escape. The right shape is a flat platform cost whether you host one domain or many, plus a one-time purchase for the software — not a meter dressed up as a subscription.
- Will I actually open it every day? A private inbox you avoid because the app is painful protects almost nothing. The client should install to your home screen, read and reply from the right address, and unlock with a glance — software you'd have chosen even without the privacy.
Where buyers go wrong
Two mistakes account for most of the regret. The first is buying for the demo instead of the day-to-day: a product can seal mail beautifully and still lose you because the app is a chore to open, so you quietly drift back to the inbox you were trying to leave. The second is reading "self-hosted" as a privacy guarantee all by itself. Self-hosted only means the data sits on infrastructure you control; whether anyone else can read it is a separate question, settled entirely by where the key lives. A full suite on your own server can still keep a readable key beside the mailbox, and a lightweight tool is only as private as its encryption design. So ask the key question of both families, not just the one that sounds humble — the trench coat and the few hundred lines of code each have to prove the same thing.
Which family fits you?
If running infrastructure is the point — if the knobs are the fun — a full classic suite hands you every one of them, and the operational weight is a feature. If you want the ownership without the operations, owned addresses, your own key, no per-seat bill, and nothing to babysit, the lightweight edge software is the better buy. It asks for a setup afternoon instead of a standing commitment, and leaves you with source and a key that are genuinely yours. The matrix tells you which row you're standing in; the questions make sure the product in that row is honest.
- Is serverless email software really "self-hosted"?
- Yes. It runs in your own account, the source is yours, and the key is yours alone. You're hosting it on infrastructure you control rather than renting an inbox — the ownership is the same, the operational burden is far lower.
- Do I need to know system administration to use it?
- Far less than a full-stack suite requires. You point some DNS records and follow a setup guide; there's no server to maintain afterward. A done-for-you install removes even that step.
- How does the software make money if I only pay once?
- You buy the software — the source and a setup guide — as a one-time purchase, with optional paid setup. The recurring cost is the flat, low charge you pay the platform directly for the services it runs on, not a subscription to the vendor.
- What's the catch with the encryption?
- The honest limits: a brief plaintext moment when mail arrives before it's sealed, and reliance on a sending provider for outbound mail. At rest, storage holds only ciphertext sealed to your key.