What Self Hosting Your Own Email Really Takes

I set up my first mail server in 1998 for a small engineering firm of twelve people. It was Sendmail on a beige tower under a desk, and the hardest part was understanding the configuration file. Nobody worried much about whether Hotmail would accept our messages. They simply did.

That world is gone. I still run my own mail for a few domains, and I still help small organizations do it, but the work has moved. The software is far easier than it was. The hard part now is persuading the large mailbox providers that a server they have never heard of deserves to be trusted. If you are considering it, here is what it really involves, without the cheerleading or the doom.

The parts of a mail server

"Running email" means running several services that cooperate:

• An MTA, the mail transfer agent, which sends and receives mail between servers over SMTP. Postfix is the most common choice on Linux.
• An IMAP server so your phone and laptop can read mail. Dovecot is the usual partner to Postfix.
• A spam filter for incoming mail. Rspamd is widely used and also handles DKIM signing for outgoing mail.
• TLS certificates so connections are encrypted, typically from Let's Encrypt with automatic renewal.
• Webmail, optional, if you want a browser interface.
• DNS records: MX, SPF, DKIM, DMARC, and ideally MTA-STS and TLS reporting.

Bundled projects like Mailcow and Mail-in-a-Box package all of this together and take much of the pain out of the initial setup. I recommend one of them to anyone doing this for the first time. You will still need to understand what each piece does when something breaks, but you will not spend a weekend reading Postfix documentation before sending your first message.

Where you run it matters more than what you run

This is the first wall most people hit, and it has nothing to do with software.

Home connections are usually a dead end for sending. Many residential internet providers block outgoing traffic on port 25, the port servers use to deliver mail to each other. Even when they do not, residential IP ranges commonly appear on policy blocklists such as the Spamhaus PBL, which exist precisely because home machines infected with malware used to send enormous amounts of spam. Mail from a home IP will be rejected by many large providers no matter how carefully you configure it.

A virtual server with a clean IP is the realistic option. Even then, some cloud providers block port 25 for new accounts until you ask, and you should check the IP address you are given against public blocklists before you build anything on it. You also need to set a reverse DNS record, called a PTR record, so the IP address points back to your mail server's hostname. Without a matching PTR, plenty of receivers will refuse the connection outright.

A workable compromise, which I use for one domain, is to receive mail on your own server but send outgoing mail through a reputable relay service. You keep control of your mailboxes and data, and outgoing messages ride on an established reputation.

The myth I would retire: it cannot be done anymore

Every few months someone declares that self hosting email is impossible because the big providers have shut out small servers. I understand the frustration, but I do not think it is accurate.

My personal domain has run on a small virtual server for years, and mail to Gmail and Outlook lands in the inbox the vast majority of the time. What it takes is a clean IP, correct authentication, matching reverse DNS, low and steady volume, and patience at the start. A brand new server has no reputation, good or bad, and providers treat unknown senders cautiously. For the first few weeks, I send mostly to people who know me and will reply, which builds trust quickly.

Self hosted mail is not blocked. It is unknown, and unknown takes a few weeks of good behavior to fix.

Where the pessimists are right is in bulk sending. If you want to send newsletters to thousands of people from a home grown server, you are fighting uphill. The reputation signals I described in how email deliverability works and why messages land in spam apply with full force, and a single server has no buffer when something goes wrong.

The ongoing work

The setup is a weekend. The upkeep is forever, though it is light once things settle. Here is roughly what my own routine looks like:

Downtime is more forgiving than people expect. Sending servers that cannot reach you will normally queue mail and retry for several days, so a few hours of outage rarely loses anything. Disk failure without backups, on the other hand, can lose years of correspondence in a moment. I keep nightly backups of the mail store on a separate machine in another location.

Security deserves its own sentence. An open relay, a server that forwards mail for anyone, will be found and abused within days. Weak passwords on mailboxes will be guessed, and the attacker will use your server to send spam, which wrecks your reputation. Strong unique passwords, rate limits on outgoing mail, and tools that block repeated failed logins are not optional.

Is it worth it

For a business that simply needs email to work, I usually recommend a hosted provider and spending the saved time elsewhere. For a technically curious person, a small group, or anyone who values owning their data, self hosting is a genuinely rewarding project, and it teaches DNS, TLS and networking in a way little else does. It is a lot like hosting a game server for friends, which Marisa wrote about in what self hosting a game server teaches new players, except that your friends are now every mail server on the internet and they are much less forgiving.

If you want to test the water, register a cheap second domain this week and set up receiving only, with a bundled project like Mailcow on a small virtual server. Send yourself mail from a Gmail account, read the headers, and get comfortable before you trust it with anything important. The self hosting section has more on choosing a server to run it on.