Should You Self-Host Your Email Server? (Why I Never Do)

The Weekend I Tried to Save Twenty Dollars

It was 2023. I was deep into Clickly — my URL shortener, the project I over-engineered into a database degree — and I was in one of those moods where every recurring charge felt like a personal insult. Resend wanted $20 a month once I crossed the free tier. Twenty dollars. For sending emails. I remember thinking: I’m an engineer. Email is just SMTP. SMTP is a protocol from 1982. Why on earth am I paying a SaaS a monthly fee to run a forty-year-old protocol I could run myself?

So I did the thing. I rented a cheap VPS from Hostinger — the same box I used for tinkering with self-hosted PaaS tools — and I set out to run my own mail server. I was going to be the guy who paid zero for email. Passive-aggressively, in my head, I was already writing the blog post about how I beat the email SaaS racket.

That blog post is this one. It just has a very different ending than I planned.

By Sunday night I had a beautifully configured mail server that could not send a single email to a Gmail inbox. Not one. Everything I sent either bounced at the door or sailed straight into spam. I’d spent an entire weekend to lose the ability to email people, which I previously had for free on Resend’s starter tier. That’s the kind of optimization only I could pull off.

Let me walk you through exactly where it went wrong, because the lesson underneath it is worth more than the twenty dollars.

---

What “Self-Hosting Email” Actually Means

First, some honesty about the word “email,” because it hides two completely different jobs — the same way transactional and marketing email are two different animals.

Receiving mail is you having you@yourdomain.com and reading what people send you. Sending mail is your server pushing messages out to the world — the password resets, the OTPs, the receipts your SaaS fires off. Self-hosting the first one is annoying but survivable. Self-hosting the second one, at scale, reliably, into the inbox — that’s the part that broke me.

The tools themselves are genuinely great. The classic stack is Postfix (the MTA that moves the mail) plus Dovecot (the IMAP server that lets you read it), and if you don’t want to wire those together by hand, two lovely open-source projects do it for you:

• Mailcow — a Docker-based bundle with Postfix, Dovecot, spam filtering, webmail, DKIM signing, and a clean admin UI. GPL-licensed, actively developed, and honestly a pleasure to look at. It wants a beefier box though — the docs ask for around 6 GB of RAM.
• Mail-in-a-Box — a single install script that turns a clean Ubuntu server into a full mail stack. Lighter than Mailcow; it’ll run happily on a 1–2 GB VPS. The project is still shipping — v74 landed in January 2026.

Both will get you from a bare VPS to a working IMAP/SMTP server in under an hour. The software is not the problem. The software is fantastic. The problem is everything around the software — the internet itself has decided it doesn’t trust new mail servers, and it has good reasons.

---

Wall #1: Port 25 Is Just… Blocked

Here’s the first thing nobody tells you. Outbound email between servers happens on port 25. And basically every cloud provider blocks outbound port 25 by default, because compromised cloud boxes are the cheapest spam cannons on earth.

I’m not exaggerating the “every”:

• AWS throttles port 25 on EC2 and hasn’t handed out easy exceptions since 2020 — you file a request and wait.
• Google Cloud blocks outbound port 25 on all VMs, full stop, and never lifts it. No appeal, no form.
• DigitalOcean blocks it by default on Droplets.
• Even Azure blocks it on most modern subscriptions.

So step one of “just run SMTP myself” is discovering that the machine you rented physically cannot open the connection SMTP needs. You can beg your host to unblock it, and some budget VPS providers will, eventually, after you prove you’re not a spammer. But sit with that for a second: the entire infrastructure is built on the assumption that a random new server trying to send mail is probably a spammer. Which brings us to the wall that actually killed me.

---

Wall #2: Reputation Is a Game You Can’t Buy Into

Say you clear port 25. Your server can now technically send. Congratulations — you’ve earned the right to be ignored by Gmail.

Email deliverability runs on reputation: the mailbox providers watch your sending domain and your IP address and decide, based on history, whether your mail is trustworthy. A brand-new VPS IP has no history. Worse than no history — cheap VPS IPs are recycled, so there’s a real chance the address you were assigned was used by a spammer six months ago and is already sitting on a blocklist like Spamhaus. You inherit that sin the moment you boot up.

And the bar keeps rising. As of February 2024, Gmail and Yahoo made the rules explicit for bulk senders: you must have SPF, DKIM, and DMARC set up, a one-click unsubscribe header, and — the brutal one — you have to keep your spam-complaint rate under 0.30%. Miss it and you’re throttled or blocked. The big transactional services live and breathe this. They run pools of warmed-up IPs with years of pristine reputation, dedicated deliverability teams, and direct relationships with the mailbox providers. You, on a $4 VPS on a Sunday night, have a cold IP and a prayer.

There’s a whole ritual to earning reputation from cold — set your PTR/reverse-DNS record, publish SPF and DKIM and DMARC perfectly, then “warm up” the IP by sending tiny volumes and ramping slowly over weeks so you don’t look like a spammer who just turned on the firehose. I did the DNS records. I did them right. I still watched my test emails land in spam, because two days of good behavior means nothing against providers that measure trust in months and years.

That was the moment it clicked. I wasn’t fighting a config bug. I was a stranger trying to talk my way past a bouncer who trusts exactly nobody he hasn’t seen a hundred times before.

---

The Bill You Don’t See on the Invoice

Let’s say you’re stubborn — more stubborn than me — and you push through. You get the IP unblocked, you warm it up over a month, you claw your way to landing in the inbox. Now you own it. Forever.

• Security patches. A mail server is a permanently open door to the internet. Fall behind on updates and you’re an open relay pumping out spam for someone else within days.
• Blocklist babysitting. One bad stretch — a bug that loops, a compromised account — and you’re on Spamhaus. Getting off a blocklist is a paperwork grovel, and meanwhile none of your mail is arriving.
• The 3 AM class of problem. Deliverability failures are silent. No error, no crash. Your server happily reports “sent,” and the mail just quietly dies in a spam folder — exactly the way my password resets did the night that taught me email is two problems, not one. You find out when a user emails you asking why they never got their reset link. If they bother to email at all. Most just leave.

I do this math the same way I do it for self-hosting anything else. A VPS to run Mailcow is a few dollars a month. ZeptoMail will send you 10,000 transactional emails for $2.50 in credits that last six months. The “savings” from self-hosting are, at best, the price of a coffee — and the cost is your weekends, your sleep, and the invisible risk that your most important emails are silently failing. That’s not optimization. That’s setting money on fire to feel clever. And I love feeling clever, so believe me, I looked hard for a way to justify it.

---

When Self-Hosting Email Actually Makes Sense

I’m opinionated, not dogmatic. There are real cases where running your own mail is the right call — they’re just not “my SaaS needs to send password resets.”

• You want to control your inbox for privacy. If the goal is receiving — owning your personal mailboxes, keeping your correspondence off Google’s servers — Mailcow or Mail-in-a-Box are legitimately good. Receiving doesn’t fight the reputation war the way sending does. Just know you’ve signed up to be your own sysadmin.
• You’re doing it to learn. Genuinely one of the best ways to understand how email actually works. I don’t regret my lost weekend one bit — I understand SPF, DKIM, DMARC, and why deliverability is hard in my bones now, and that knowledge makes me sharper about the tools I do pay for.
• You’re at serious scale with a real team. When you’re sending millions and have someone whose actual job is deliverability, owning your infrastructure can pencil out. That is not you, and it certainly wasn’t me at $0 MRR.

Notice the pattern: every good reason is about receiving or learning or scale-with-staff. Not one of them is “a bootstrapped solopreneur trying to reliably send a few thousand transactional emails a month.” For that, the answer is boring, and boring is correct.

---

What I Actually Do (The Boring, Correct Thing)

After the weekend of shame, here’s my whole email setup, and it costs almost nothing:

• Sending transactional mail: Start on Resend’s free tier — 3,000 emails a month, capped at 100 a day. Outgrow it and move to ZeptoMail at $2.50 per 10,000. If you already live inside AWS and don’t mind the ceremony, Amazon SES is $0.10 per 1,000. If your business lives or dies on OTPs landing instantly, pay the premium for Postmark. All of them have spent years earning the reputation I couldn’t earn in a weekend.
• Sending marketing mail: a list-based tool like SendPulse, never the same service as your transactional mail. (The full why is in the complete email guide.)
• Receiving mail on my domain: Zoho Mail if I want cheap-to-free custom-domain mailboxes, Google Workspace if a client insists on the Google experience. This is the one place I’ll sometimes lean self-hosted for a personal domain — but never for anything a business depends on.

That’s it. Two or three tools, a handful of dollars, and I never think about port 25, PTR records, or Spamhaus again. The money I “wasted” on Resend that year bought me something self-hosting never could: the certainty that when a user clicks “reset password,” the email actually shows up.

---

The Bottom Line

Self-hosting your email server is one of those ideas that’s technically true and practically a trap. The software is free and excellent. The protocol is ancient and open. And none of that matters, because email isn’t a software problem — it’s a trust problem, and trust is the one thing you can’t apt install.

I’m the guy who benchmarked seven databases to shave pennies off a URL shortener, who put a CDN in front of Vercel to dodge a $20 plan. If I tell you the juice isn’t worth the squeeze, believe me — I squeezed. Pay the couple of dollars for a service that’s already won the reputation war. Spend the weekend you’d have lost on the only thing that actually moves the needle: getting users. (Email is a tiny line on the bill anyway — I added up the whole monthly cost of running a SaaS if you want the full tally.)

Self-host to learn. Self-host to own your inbox. But when it’s time to send the mail your product depends on — just pay. Your future self, not debugging deliverability at 3 AM, will thank you.

This is the Broken Engineer Guide — I over-engineer everything, lose a weekend to it, and write down the lesson so you keep yours. Now go send an email that actually lands.