Don't self-host transactional email. I'll say the position up front because most posts on this bury it under six paragraphs of throat-clearing about "it depends": for a normal SaaS sending password resets, receipts, and the occasional notification, running your own mail server is a worse decision than paying $20 a month for someone who already solved it. Not because it's technically hard to stand up Postfix. Because getting it to actually deliver mail, reliably, to Gmail and Outlook and every corporate spam filter in between, is a different and much longer project.
This is also the one exception in the rule I use for deciding what to self-host, so it's worth spelling out properly instead of gesturing at it. The rule is: self-host what fails loudly and where you already hold the expertise, pay for what fails silently or needs reputation you don't have. Email fails on both counts at once, and that's the whole argument. Everything below is just defending it against the obvious objections. People arriving at email deliverability from a marketing team will find the XenGrowth practice closer to their day.
What actually happens when you stand up your own SMTP server?
You get a working mail server in about twenty minutes. Postfix installs cleanly, the daemon starts, you can send yourself a test email and watch it land. What you don't get, on day one, is anyone downstream trusting the IP address it's sending from. Every mailbox provider maintains its own reputation score per sending IP, built from delivery history, spam complaint rates, and blocklist hits, and a brand-new IP has none of that history — good or bad. It starts at zero, which mailbox providers treat closer to suspicious than neutral, because a fresh IP sending unsolicited mail is exactly what a spammer's setup looks like too.
Building that reputation up takes a slow, consistent sending pattern over weeks, sometimes months, and it's fragile the entire time: one bulk import that fires a thousand emails at once, one contact form abused by a bot, one customer who marks a legitimate email as spam because they forgot they signed up, and the reputation you were building resets or goes negative. A provider that's been sending at scale for years absorbs that kind of noise. A brand-new IP does not.
Why isn't SPF, DKIM and DMARC just a checkbox you tick once?
Because there's no partial credit. SPF has to list the exact sending IP. DKIM has to sign with a key that matches what's published in DNS, byte for byte. DMARC has to actually align the From domain with what SPF and DKIM report, not just exist as a record. Get any one of these slightly wrong — a typo in a DNS record, a key rotated on the mail server but not in DNS, a subdomain that isn't covered — and the message doesn't bounce with a helpful error. It either gets silently dropped, or it lands in spam, and either way nothing in your application tells you that happened. For the the operations side of this angle, see The XenGrowth resource library.
Compare that to almost every other failure in a self-hosted stack. A crashed container returns a 502. A full disk throws an error you can grep for. Email misconfiguration produces no error at all, on your side, ever. The only signal is on the receiving end, in a spam filter's internal scoring, which you never see.
Why don't Gmail and Yahoo just trust you the way they trust everyone else?
They don't trust anyone by default — established senders have just already cleared the bar. Gmail and Yahoo formalized their bulk-sender requirements in 2024: SPF, DKIM, and DMARC alignment, a spam-complaint rate kept under roughly 0.3%, and a one-click unsubscribe header on anything that qualifies as bulk mail. That's the codified version of a filtering behavior mailbox providers had already been running informally for years — unfamiliar senders get scrutinized harder, established ones get the benefit of the doubt on borderline messages. A provider like Resend is sending from IP ranges mailbox providers have seen millions of legitimate messages from already. A server you spun up last week hasn't earned that yet, and won't for a while.
A shared blocklist listing you because another customer on a nearby IP block got flagged, even though you did nothing wrong
A spam-complaint rate that creeps up from a handful of confused users, quietly dragging your whole domain's reputation down
A DKIM key rotated on the server but not updated in DNS, breaking every signature until someone notices
A subdomain used for transactional mail that was never added to the SPF record, so its mail authenticates as nothing
A receiving server that accepts the message, then routes it straight to spam with zero bounce or notification back to you
What would you actually have to build if you insisted on running your own?
It's more than a Postfix install, and this is the part that doesn't show up until you're already committed. A serious self-hosted sending setup needs a warm-up schedule that ramps volume slowly over weeks rather than firing at full volume on day one, because mailbox providers throttle or block sudden bursts from unfamiliar IPs regardless of how correctly everything else is configured. It needs feedback-loop processing so that when a recipient marks a message as spam, that signal gets back to you and suppresses future sends to that address — without it, your complaint rate keeps climbing every time someone who forgot they signed up hits the spam button. It needs bounce handling and a suppression list, so a hard bounce doesn't get retried indefinitely and drag reputation down further. And it needs someone actually reading DMARC aggregate reports, which arrive as machine-readable XML, not a dashboard alert.
A slow, deliberate volume ramp-up over several weeks, not a full-speed launch
Automated bounce handling with a suppression list, so hard bounces stop retrying
Feedback-loop processing from every major mailbox provider that offers one
Someone parsing DMARC aggregate reports on a schedule, not just publishing the record
A plan for what happens when the sending IP lands on a shared blocklist anyway
That last one is worth sitting with. Getting off a blocklist isn't instant even once you've fixed whatever triggered it — most blocklist operators require a delisting request, a review period, and proof the underlying issue is resolved, and some run on a fixed schedule rather than reacting immediately. In the meantime, mail from that IP keeps getting rejected or spam-foldered by everyone who subscribes to that list, for a problem that might have taken you days just to notice existed. None of this is exotic — it's the actual job description of a deliverability team, which is precisely what a provider like Resend already employs so you don't have to build one. XenGrowth on governed AI marketing workflows goes further into AI agents and marketing automation.
What does it actually cost you when this goes wrong?
Nothing, as far as your own systems can tell. Your app calls the send function, gets a 200 back from the mail server, and logs a success. There's no exception to catch, no retry to trigger, because as far as the sending side is concerned, nothing failed. The email genuinely left your server. It just never arrived, or arrived somewhere the recipient will never look.
The failure you'd actually have to debug isn't 'the email didn't send.' It's 'a customer emailed support asking why they never got a password reset three days ago,' with a perfectly clean application log telling you everything worked.
That's the shape of every email deliverability incident: discovered downstream, after the fact, by someone other than you. Contrast that with the failures on the rest of a self-hosted stack — a crashed container, a full disk, a reverse proxy returning a 502 — all of which announce themselves immediately, to you, in a place you're already watching.
So what does Resend actually cost, and is it worth it?
For most SaaS sending patterns, not much. Resend's free tier gives 3,000 emails a month, but caps at 100 a day — that daily cap is the one that actually bites, not the monthly total, because a single busy signup day can burn through it even for a low-volume product. Past that, paid plans start at $20/month for 50,000 emails, with Pro at $35 and Scale at $90 both selling the same 100,000-email allowance and differing on features rather than volume. It tops out at $1,150/month for 2.5 million emails before Enterprise pricing kicks in. XenGrowth on building one SEO and GEO content system goes further into AI search, GEO and discovery.
Plan | Price/month | Emails included | Daily cap |
|---|---|---|---|
Free | $0 | 3,000/month | 100/day |
Paid (entry) | $20 | 50,000/month | No fixed daily cap |
Pro | $35 | 100,000/month | No fixed daily cap |
Scale | $90 | 100,000/month | No fixed daily cap |
Highest published tier | $1,150 | 2,500,000/month | No fixed daily cap |
Is there ever a real case for self-hosting email?
Yes, and it's worth being honest about it instead of pretending the answer is always no. The case is volume math and data residency, in that order. At volumes far past what most SaaS products send — think tens of millions of emails a month, sustained — per-email provider pricing starts to compound into a genuinely large bill, and a team with the in-house deliverability expertise to run its own sending infrastructure at that scale can make the numbers work. That team also isn't reading a post titled "should you self-host email" for the first time; they already employ people whose job is exactly this. The other real case is regulatory: some data residency or compliance requirements mandate that mail infrastructure, not just storage, stay within a specific jurisdiction or specific hands, which rules out third-party providers regardless of cost.
Self-hosted SMTP | Resend (managed) | |
|---|---|---|
Where it makes sense | Sustained volume in the tens of millions/month, or a hard data-residency requirement | Everything below that volume — the vast majority of SaaS products |
Time to first reliable send | Weeks to months of reputation-building and DNS tuning | Working correctly on day one |
What breaks silently | SPF/DKIM/DMARC misalignment, IP reputation drift, blocklist entries | Nothing on your side — Resend's own dashboard shows delivery and bounce events |
Who owns the fix when it breaks | You, with no dashboard telling you it broke | Resend's infrastructure and support, whose job is exactly this failure mode |
Cost at low volume | "Free" on the invoice, expensive in the time and reputation it actually costs | $0–$20/month for most SaaS sending patterns |
What if you're already self-hosting everything else on your stack?
That's exactly the situation where this exception matters most, not least. If you're already running a complete self-hosted stack — your own database, your own PaaS layer, your own reverse proxy — it's tempting to treat email as just one more service that belongs on the same box, on principle. It isn't the same kind of service, and the 80/20 read on which parts of self-hosting are actually worth the effort puts email squarely in the "buy this" column for exactly the reason above: the effort-to-savings ratio here is the worst on the entire stack, because the effort is measured in months of reputation and the savings, at normal volume, are measured in tens of dollars.
None of this is an argument that self-hosting email is impossible, or that nobody should ever do it. People run their own mail servers successfully, and some of them have good reasons to. It's an argument that the reasons have to be specific — real volume math, or a real compliance requirement — and not "the VPS is already paid for" or "I don't like paying for things I could technically run myself." For a password reset and a handful of transactional emails a day, the honest math says pay the $20 and spend the saved months on something the business actually needs.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
If email deliverability is part of a growth programme rather than a standalone build, XenGrowth is the companion reading.
Four questions, and a warning: this is the one comparison in the cluster where the post has a strong opinion. Deliverability is not a technical problem you can solve by being good at Linux.
