Self-hosted email alternative: control without the server

Self-hosting email is the decision to run the SMTP stack yourself: the mail transfer agent, the IMAP store, the spam engine, TLS certificates, DNS authentication records, reverse DNS, backups, and the reputation of an IP address that large receivers have never heard of. What it buys you is total custody. What it costs is not the initial setup, which is a good weekend. It is the trickle afterwards, forever.

I want to be fair to it, because I have run my own mail and the people who do it are not wrong about what they want. They are frequently wrong about what they have to accept to get it.

What does self-hosting email actually cost?

Not money. Attention, in small unpredictable amounts, concentrated on the one part you cannot control: whether other people’s servers accept your mail.

Start with the plumbing, which is the easy half. SPF, DKIM and DMARC records that align. A PTR record matching your HELO name, which means an IP whose reverse DNS you can set. Certificates renewing on their own for years without a human noticing. MTA-STS and TLS reporting if you want inbound TLS to be enforced rather than opportunistic. Patching a mail daemon that is directly exposed to the internet. A spam stack that needs corpus training and tuning. Backups that you have actually restored from once, rather than backups you have configured.

Now the hard half. Many clouds block outbound port 25 by default — Google Cloud does not open it at all, AWS requires a request, Azure blocks it for most subscription types — so your choice of host is constrained before you begin. A fresh IP on a small block gets greylisted, deferred or refused by large receivers regardless of how correct your configuration is, and warming it is a matter of weeks of low, consistent, wanted volume. Blocklists need monitoring, because you find out you are on one from a bounce message, usually from the recipient who mattered. Since February 2024 Google and Yahoo have required authenticated mail, DMARC for bulk senders, one-click unsubscribe and a spam complaint rate under roughly 0.3 percent — a floor that keeps rising and that nobody consulted you about.

The steady state is perhaps an hour a month. The bad state is a Saturday spent proving to a reputation system that you are not a spammer, while your invoices sit undelivered. That variance is the real price, and it does not go down with skill. It goes down with volume history you cannot fake.

What did you actually want from self-hosting?

Almost always three things, and none of them is the mail server: custody of the archive, mail on your own domain, and the freedom to leave.

Custody means the bytes sit somewhere nobody can take from you — no suspended account swallowing twelve years of correspondence, no jurisdiction attached to a vendor’s incorporation, no export ticket to file. Your own domain means the addresses are yours, so the provider is an implementation detail rather than your identity. Portability means the archive is in a format you can read with something other than the vendor’s own software.

There is a fourth, quieter motive: not being a data source. No scanning, no ad targeting, no model training on the contents of your inbox.

Look at that list and notice what is absent. Nobody wanted to operate an MTA. Nobody wanted opinions about greylisting. The daemon was the toll, not the destination.

When is self-hosting email genuinely the right call?

Five situations, and they are real ones.

When the mail never leaves your network. Internal notifications, cron output, ticketing, monitoring alerts — a local MTA delivering to local mailboxes sidesteps every deliverability problem, because there are no external receivers to convince.

When you need protocol-level control that hosted services do not expose: unusual routing, custom Sieve at scale, per-domain policies, integration with something ancient and load-bearing.

When regulation or an air gap requires you to operate the whole path, and no amount of contractual custody substitutes for physical control.

When you already run monitored infrastructure with someone on call. If Prometheus is already alerting and a person already carries a pager, adding mail is a marginal cost rather than a new discipline.

And when running it is the point. Learning how mail works by operating it is a genuinely good use of a weekend, and I would not talk anyone out of it.

Two lighter variants deserve a mention because they solve most of the problem. Receive-only self-hosting is easy — inbound has no reputation requirement. And relaying outbound through an authenticated smarthost while keeping your own IMAP store hands off the single hardest part while you keep the rest.

What is the middle path?

Managed routing plus storage you own. A provider handles the MX records, the SPF, DKIM and DMARC verification, the spam filtering and the sending reputation; each message is encrypted and written into object storage in your own account — your S3 or R2 bucket, your WebDAV server, even a Git repository.

The split follows the failure modes, which is why it holds up. Losing your archive is permanent and unrecoverable. A misjudged spam verdict is an annoyance you fix on Tuesday. Outbound reputation is decided by strangers using data you cannot access. Handing the reversible, expertise-heavy problems to someone whose full-time job they are, while keeping the irreversible one yourself, is the allocation I would choose on purpose even if self-hosting were free.

What you get concretely: backup becomes bucket versioning and a lifecycle rule instead of a feature request. Migration becomes re-pointing the writer instead of extracting the archive. Region and jurisdiction become two settings you choose separately. And if the routing service disappears next month, you lose an interface rather than a decade of mail.

What does the middle path not give you?

Four things, and pretending otherwise would be dishonest.

You still trust a routing operator. Spam filtering has to read the message, so your plaintext exists in someone else’s memory before it is encrypted at rest. Any service that filters your mail and also claims never to see it is describing something that cannot work.

Transport metadata stays exposed. SMTP negotiates in the open between hops, so envelope addresses, timestamps and the path a message took are visible to every relay that handles it. Where a message rests is not how it travelled.

You do not get to change the mail server. If you wanted to patch Postfix, this is not that.

And custody hands you the responsibility that comes with the power. A permissive bucket policy publishes your mail. A deleted bucket deletes your mail. Nobody is going to restore it from the backup you did not take. That is the deal, and it is the same deal self-hosting offers — minus the part where a reputation system you have never met decides whether your mail arrives.