Should You Self-Host Email? An Honest Answer

Deliverability is the whole game, and it's rigged against you

Sending email is trivial. Getting it into someone's inbox instead of their spam folder — or getting it accepted at all — is a reputation contest you start out losing.

The moment you send from a fresh VPS IP, you're guilty until proven innocent. Large providers (Gmail, Outlook, Yahoo) score every sender on IP and domain reputation, and a brand-new IP with no history is treated as suspicious by default. Worse, VPS and datacenter IP ranges are collectively distrusted, because that's where most spam originates. Many of these ranges sit on blocklists before you ever touch them — you inherit the sins of whoever held that IP before you. Residential IPs get more benefit of the doubt, but you can't send mail from a residential connection because ISPs block outbound port 25 and their ranges are explicitly flagged as "not a mail server." So you're stuck on exactly the kind of IP the receiving world trusts least.

You can do everything right — set up SPF, DKIM, and DMARC correctly, add reverse DNS that matches your hostname, warm the IP up slowly, keep your volume clean — and still watch Outlook.com silently drop your messages into a void with no bounce and no explanation. Microsoft in particular is notorious for this. There's no support line, no appeal that reliably works, no one to ask. You did everything by the book and the mail still vanishes. That's the part the tutorials don't prepare you for, because their author's test email to their own Gmail landed fine and they called it a day.

And reputation isn't a one-time setup. It decays. Take a break from sending, or have one compromised script fire off garbage, or land on a blocklist because a neighbor on your IP range misbehaved, and you're back to square one — rebuilding trust you can't directly control.

The maintenance never ends

A mail server is not a thing you set up. It's a thing you run, forever, and it's arguably the least forgiving service to run because the failure mode is silent and the stakes are your actual communication.

You're now responsible for spam filtering that keeps up with an adversary who evolves weekly, for security patches on a service that is a permanent, attractive target, for TLS certificates, for blocklist monitoring, for the fact that if your one server is down for a day you might bounce mail that never gets resent. Email is the one service where "I'll fix it this weekend" can mean a job offer or a password reset landed in a black hole. When your self-hosted Nextcloud is down for an afternoon, you shrug. When your mail is down, you may not even know what you missed.

That is a real, recurring tax on your attention. For a hobby it might be a fun tax. For the address you give your bank, it's a liability you're volunteering for.

So who should actually do it?

Not nobody — just far fewer people than the enthusiast threads imply. The honest breakdown:

• Almost everyone, for primary personal or business mail: don't. Use a paid provider that isn't Google if de-Googling is the goal — Fastmail, Proton, Mailbox.org, Migadu. You get inbox placement, redundancy, and someone else fighting the reputation war, for a few dollars a month. This is not a compromise. It's the correct answer.

• People who want a vanity domain but not the burden: use a hosted provider with your own domain, or set up a forwarding-and-relay arrangement where inbound goes to a real provider and you only handle the domain. You get [email protected] without owning the deliverability problem.

• Transactional or one-way sending at low stakes: if you just need a server to send its own notifications (a monitoring alert, a cron report to yourself), self-hosting the sending side is fine, because you control the receiving end and don't care about Gmail's opinion. Even here, many people route through a relay to avoid the IP-reputation fight.

• The genuinely committed hobbyist who wants to learn how email works and accepts that some of their outbound will land in spam: go for it, with eyes open, and don't put anything important on it until it's proven itself for months. Run it as a learning project, not as your only address.

The tell is whether email is your hobby or just your tool. If SPF and DKIM sound like a fun weekend, self-hosting will teach you an enormous amount about how the internet actually works. If email is just how you talk to people and you need it to Just Work, every hour you spend on deliverability is an hour spent losing to Google at its own game.

The pragmatic middle path

If the real motivation is privacy and control rather than the mail server itself, there's a saner setup than running the whole stack. Own your domain. Point it at a privacy-respecting paid provider for the mail. Run the things you actually benefit from controlling — a VPN, a password manager, file sync, your own DNS resolver — on a VPS you rent with an email and a crypto payment, somewhere like NoctHost. You get most of the independence people are chasing, without betting your ability to receive a password-reset email on your skill at appeasing Microsoft's spam filter.

Self-hosting is a great instinct. Email is just the one service where the incumbents have quietly rigged the board, and the honest move is to pick your battles.

What this looks like on a VPS you rent

Before you plan any of this, check one thing: whether outbound port 25 is open at all. Almost every cloud blocks it by default, because spammers were the first customers of cheap compute, and providers got tired of the abuse reports. The block is at the network level, so it doesn't matter what your firewall says — connections to port 25 simply hang until they time out.

On NoctHost specifically, we tested it rather than guessing:

So on a Vultr server you can send mail *through* a relay — the port your app talks to is 587, and that works. What you can't do anywhere is deliver directly to Gmail's mail servers, because that conversation happens on port 25.

This is the norm rather than a quirk of one host: assume 25 is blocked, and treat a provider that opens it on request as a bonus rather than a baseline. It also quietly settles the question this post is about. If direct delivery is off the table unless you file a support ticket and convince someone you're not a spammer, "self-hosting email" in practice means self-hosting the mailbox and relaying the sending — which is the middle path above, arrived at by a different road.