Proton Mail and Self-Hosted Mail: An Honest Comparison
“Self-hosted” sounds like the more private option and the more capable one, and it is neither by default. Hosting your own mail moves the trust boundary rather than removing it: you take on the server, the patching, the deliverability, and the availability, in exchange for control over where the data sits and who can be compelled to hand it over. This guide compares the two approaches on the dimensions that actually decide whether one suits you, without recommending either for everybody.
Table of contents
- What “self-hosted” actually means
- The three layers people conflate
- The comparison that matters
- Deliverability, the unglamorous problem
- Who each suits
- The middle options
- FAQ
- Bottom line
What “self-hosted” actually means
The phrase covers several arrangements that are quite different, and the difference decides most of the trade-offs.
- Using a provider that encrypts your mail at rest and in transit, run by someone else. This is what most people in this category actually use. The provider holds the servers; the encryption protects the content from the provider and from anyone who obtains the servers.
- Running the server yourself, on your own hardware or your own rented machine. You control the machine, the storage and the configuration. You also now own uptime, patching, backups, spam filtering, DNS, reputation and every incident response that follows.
- Running the server yourself, on rented infrastructure that someone else physically controls. The disk may be encrypted, but the operator of the machine can still access the running system while it is on. This is meaningfully different from the second case and frequently confused with it.
- Running the server at home, on hardware you own. The strongest control case, and the one with the most single points of failure: your power, your connection, your router, and the fact that you need it working at all times for it to be useful.
The arrangement matters more than the label. “Self-hosted” can describe the weakest or the strongest version of the same idea depending on who controls the disk.
The three layers people conflate
Most confusion about this comparison comes from mixing three separate questions together.
Layer one: encryption in transit. Whether your mail travels over an encrypted connection. Both approaches here do this; it is table stakes and no longer a differentiator.
Layer two: encryption at rest, and who can read it. Whether the stored mailbox is readable by the machine's owner, and whether the provider can produce a plaintext copy of a message on request. This is the layer where a hosted encrypted service differs most from a self-hosted one, because with a hosted service the provider controls the key material and can be compelled to use it, while with a server you control, the compelled party is whoever can take the disk or the running machine.
Layer three: the metadata. Who sent what, to whom, when, and how large. A hosted encrypted service still sees at least some of this, because it has to route the mail. Self-hosting does not remove metadata either — your own mail server sees it, and so does every other server your mail passes through, and so does the recipient's.
The honest summary is that neither approach makes metadata disappear, and the difference in layer two is a difference in who holds the keys, not in whether anyone can read anything.
The comparison that matters
Setting the philosophical question aside, here is where the two approaches differ in ways you will actually feel.
- Setup effort. A hosted service is an account and a login. A self-hosted mail server is DNS configuration, certificates, a reputation history, spam filtering, and a long tail of small problems. This is the biggest single difference and it is not close.
- Ongoing maintenance. Patching, monitoring, disk management, backups that are actually restorable, and keeping up with changes in how other mail servers treat yours. Someone has to own all of it.
- Deliverability. A provider has an established sending reputation. A new server has none, and getting one means configuring reverse DNS, keeping a consistent sending address, avoiding patterns that look automated, and often submitting to blocklists. This is discussed separately below because it is where most self-hosted attempts fail.
- Availability. A hosted service has redundancy and a support team. A self-hosted server at home is available exactly as often as your power and your internet connection are.
- Cost. A hosted service costs a subscription. A self-hosted setup costs a server or hardware, a domain, a certificate, and your time. The time is the expensive part.
- Client access. A hosted encrypted service may offer its own web client and native apps, which is part of why encryption is usable at all. A self-hosted server can be configured to work with ordinary mail clients, but the integration is the work.
- Scale. One person, one address, one device: self-hosting is manageable. A family, a team, a company: the operational load multiplies with every mailbox, every alias and every device.
Deliverability, the unglamorous problem
It is worth spending a paragraph on this, because it is where self-hosted mail projects most often end, and it is not a privacy question at all.
Large mail providers protect their users against exactly what a new self-hosted server does: sending a batch of mail to recipients who have not asked for it, from an address with no history, from infrastructure that has not been seen before. A new server trips these filters. The consequences are concrete: your mail is rejected, it lands in spam, or it is silently dropped. The recipient sees nothing and concludes you are not sending.
The mitigations are known and they are unglamorous: a static IP, matching reverse DNS, a consistent sending hostname, a real domain with a long history, and a gradual sending pattern that does not look like a bulk operation. All of them require time to establish. A hosted provider has already done this. This is the practical reason most people who value encrypted mail end up with a hosted encrypted account, and it is worth weighing explicitly rather than discovering it later.
Who each suits
A hosted encrypted service suits people who want encrypted mail without an infrastructure project. It suits families, small teams, anyone on a phone who wants to read mail in an app, and anyone whose mail matters more than their hosting setup. The compromise is that you accept the provider's terms and their compelled-disclosure position, and you accept that they can see metadata.
Self-hosting suits people who already run infrastructure and enjoy it, who have a specific reason their mail must not sit on someone else's systems, or who need controls a hosted service does not offer. It suits an organisation with the staff to own it. It does not suit someone who wants it to work quietly, because it will not be quiet.
Neither suits someone whose threat model does not include a mail provider at all. If your concern is malware, a lost laptop, or a company laptop with disk encryption disabled, mail infrastructure is the wrong place to spend the effort.
The middle options
Before committing to either, it is worth knowing that the choice is less binary than it looks.
- Hosted service, custom domain. You get the provider's infrastructure, its deliverability and its app, on an address you own. This is the option most people who want “my own domain” actually want.
- Hosted service for mail, self-hosted for something else. A self-hosted server for a newsletter or a small site, with mail hosted elsewhere. Very common and often sensible.
- Self-hosted for receiving, hosted for sending. Receiving mail is comparatively easy to get working; sending is where deliverability bites. Some setups do exactly this split.
- A mail server you run, on rented infrastructure, with encrypted disks. A middle position on control, and it is worth understanding precisely what it does and does not protect.
FAQ
Is self-hosted mail really more private?
It depends which question you are asking. Against the provider, yes: with a server you control, there is no company that can be asked to hand over a decrypted mailbox. Against everyone else in the path, no: your recipients' providers still see who sends what, and the metadata still exists at every hop. Self-hosting changes who holds the keys. It does not make metadata disappear.
Can I use my own domain with a hosted encrypted service?
Generally yes, and it is the option to look at first if the appeal of self-hosting is about owning the address rather than owning the server. The details vary by provider and plan. [VERIFY the current domain and customisation options with any provider you consider.]
What breaks first in a self-hosted setup?
Almost always deliverability, and usually a long time after the setup worked. Mail sends correctly to your own accounts for weeks, and then some recipient's provider starts rejecting it. The fix is usually a long and unsatisfying process of establishing reputation.
Is it worth it for one person who just wants encrypted mail?
Almost certainly not, and the reason is not the technology. It is that the operational load of running a mail server is a fixed cost that does not shrink for one user, while the privacy benefit over a good hosted service is one of degree rather than of kind. The fuller comparison of encrypted mail setups is in encrypted email for a small team.
What about receiving mail only?
Receiving-only is a much smaller problem. No reputation to build, no sending filters to satisfy, and a misconfiguration affects you alone rather than other people. It is a reasonable first step, and a reasonable place to learn the operational side before committing to the harder half.
Bottom line
Self-hosted mail moves the trust boundary rather than removing it, and it costs you an infrastructure project to do it. The hosted encrypted route gives you encryption without the project, at the price of trusting a provider and accepting that metadata exists either way. For most people, the hosted option is the better trade because the operational load of self-hosting does not shrink when you are one person. For someone who already runs infrastructure, or who has a specific reason their mail must not sit on another organisation's systems, self-hosting is a reasonable choice — provided you go in knowing that deliverability is the hard part and it will not be solved for you. Whichever you pick, the questions that matter are the four in the logging-policy guide applied to mail: what is stored, what is readable, for how long, and who can be compelled to look.
If you want to see what current hosted options cost before deciding, the link below goes to our own page for the category.