Self-Hosted Mail Server: An Honest Account of What You Are Taking On

You can have a working mail server in an afternoon. Getting mail delivered to inboxes rather than spam folders is the hard part, and it depends on DNS records, IP reputation and consistent behaviour over months — none of which the installer sets up for you.

Self-hosting email has a reputation for being impossible. It is not. Modern packages have collapsed what used to be a week of Postfix and Dovecot configuration into a single deployment.

What has genuinely got harder is delivery. A handful of providers receive most of the world’s mail, and their filters are tuned against exactly the signal a new self-hosted server produces: an unknown domain on an unfamiliar IP with no sending history. That is the real project, and it is worth understanding before you start rather than after your first invoice lands in someone’s junk folder.

What you are actually running
The DNS records that decide whether mail arrives
Reputation, which you cannot configure
The ongoing maintenance nobody mentions
When self-hosting is the right call
How this fits the rest of the stack
FAQ

What you are actually running

A mail server is four services that people casually refer to as one thing:

An MTA (Postfix, Exim) that speaks SMTP to other servers — this is what sends and receives.
An MDA/IMAP server (Dovecot) that stores messages and serves them to your mail client.
A spam filter (Rspamd, SpamAssassin) for inbound, because without one an exposed mail server becomes unusable within days.
A signing and policy layer (OpenDKIM or built into the MTA) that proves outbound mail is genuinely from you.

Wiring those together by hand is the traditional rite of passage. There is no reason to do it now. The integrated distributions handle it:

Mailcow — Docker Compose based, well documented, the most common recommendation for a first self-hosted server.
Mailu — similar shape, lighter, also container based.
Mox — a single Go binary that includes everything and sets up DKIM, SPF and DMARC records for you. The lowest-friction option available today.
Mail-in-a-Box — opinionated and script driven, aimed at a fresh Ubuntu box you do not otherwise use.

Any of these gets you sending within a couple of hours. Then the actual work starts.

The DNS records that decide whether mail arrives

Three records do most of the work, and getting them exactly right matters more than anything you configure on the server itself.

SPF lists which servers may send for your domain:

example.com.  IN TXT  "v=spf1 mx a:mail.example.com -all"

End it with -all (hard fail), not ~all (soft fail). A soft fail says you are not confident about your own sending, and receivers treat it accordingly.

DKIM cryptographically signs outbound mail so a receiver can verify it was not altered and did come from you. Your mail package generates the key and gives you the record to publish. This is the one that most often gets published with the wrong selector or a line-wrapped key, and it fails silently.

DMARC tells receivers what to do when SPF and DKIM fail, and asks them to report back:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

Start at p=none and read the aggregate reports for a fortnight before moving to quarantine and then reject. Publishing p=reject on day one, before you have confirmed your own mail passes, is how people discover their password reset emails stopped being delivered.

Two more that are less discussed and still matter:

Reverse DNS (PTR). Your sending IP must resolve back to your mail hostname, and that hostname must resolve forward to the same IP. Many providers reject mail outright without it, and only your hosting provider can set it.
MX, pointing at the mail host by name — with a working A record and a certificate matching that name.

Reputation, which you cannot configure

This is the part that is genuinely outside your control, and it is why the advice to self-host is so contested.

A brand-new IP address has no sending history. Filters treat that as suspicious by default, because it is the profile of a throwaway spam source. You earn reputation by sending low volumes of mail that people actually want, consistently, over weeks.

Things that will hurt you before you send anything:

Your IP’s neighbours. Cheap VPS ranges are heavily used for spam and are often blocklisted as whole ranges. Check the IP against Spamhaus before you commit to it.
Residential IPs. Effectively all consumer ranges are blocked for direct SMTP. Home self-hosting means relaying outbound through a provider regardless.
Port 25 blocked outbound. Many providers block it by default on new accounts and will unblock it on request — or will not.

The pragmatic middle path is worth naming: run your own server for receiving and storage, where you have full control and no deliverability problem exists, and relay outbound through an established SMTP provider whose reputation is already good. You keep your data and your addresses; you rent the one thing that takes years to build.

The ongoing maintenance nobody mentions

Setup is a weekend. Operation is indefinite, and mail has a worse failure mode than most services: it fails quietly, and you find out when someone tells you they never got your reply.

What the job actually involves:

Security updates on a permanently exposed service. An open SMTP port is scanned continuously. Falling behind on patches is not an option you have.
Certificate renewal. Automated until the renewal hook does not reload Dovecot and clients start failing to connect.
Backups you have tested. Mail is often the only copy of something. An untested backup of a mail store is a rehearsal you have not done.
Blocklist monitoring. You need to know you have been listed before your customers do.
Disk. Mail stores grow steadily and a full disk on a mail server means silently rejected inbound mail.
Upgrades. Major version bumps of the mail stack occasionally require migration work with no rollback that preserves incoming mail.

None of this is exotic. It is just permanent, and it does not pause because you are busy.

When self-hosting is the right call

It is a good decision when the reasons are specific:

You have a legal or contractual requirement about where message data is stored.
You need an unusual number of addresses or aliases, where per-mailbox pricing genuinely stops making sense.
You want to understand the system properly, and a personal domain is a low-stakes place to learn it.
You are already operating servers, and one more is marginal rather than a new discipline.

It is the wrong call when the reason is cost. Hosted mail is a few dollars per mailbox per month. A VPS plus your time, plus the afternoon you spend delisting yourself from a blocklist, is not cheaper — and the failure mode is a customer email that never arrived and never bounced.

It is also the wrong call for transactional mail from an application. Password resets and receipts have to arrive on the first attempt, and that is precisely the guarantee a new self-hosted server cannot offer. Use a provider for that, whatever you do with your personal mail.

How this fits the rest of the stack

The general pattern here is worth extracting, because it applies well beyond mail: some services are cheap to run and expensive to run well, and the expensive part is reputation and operational continuity rather than compute. Mail is the clearest example. A database is a milder one — installing Postgres is trivial, and being confident your backups restore is not.

That is the line RunxBuild draws. Application services, static sites and managed MySQL or Postgres run on one deployment path with backups, private networking and connection limits handled, so the operational surface you keep is the part specific to your product. Mail is not something we offer, and this is one of those cases where a provider that specialises in it is the honest recommendation. If you are pricing what the rest of the stack costs, the RunxBuild hosting calculator shows the service, database, storage and bandwidth as separate line items.

Useful related references:

FAQ

Is it still possible to self-host email in 2026?

Yes, and it is easier to set up than it has ever been — Mox or Mailcow will have you sending in an afternoon. What is hard is deliverability. A new domain on an unknown IP has no reputation, and the major receivers treat that as suspicious until you build a sending history over weeks.

What DNS records does a self-hosted mail server need?

MX pointing at your mail host, SPF listing your sending servers with a -all hard fail, DKIM publishing your signing key at the right selector, DMARC starting at p=none while you read reports, and a PTR record so your sending IP resolves back to your mail hostname. Missing reverse DNS alone causes outright rejections.

Can I run a mail server at home?

For receiving and storage, yes. For sending directly, effectively no — consumer IP ranges are blocked for SMTP almost universally, and most home connections block port 25 outbound. The workable arrangement is self-hosting the server and relaying outbound mail through an established SMTP provider.

Should I use a self-hosted server for transactional email?

No. Password resets and receipts must arrive on the first attempt, and that is exactly the guarantee a server with no sending reputation cannot make. Use a dedicated provider for application mail regardless of what you do with your personal or company mailboxes.

How much maintenance does a mail server actually need?

Continuous rather than heavy. Security patches on a permanently exposed service, certificate renewals, disk headroom, tested backups, and blocklist monitoring. The real cost is that mail fails quietly — you usually learn about a problem when someone mentions they never received your reply.