Self-hosting outbound email is one of those projects that looks like a weekend of Postfix configuration and turns out to be a permanent part-time job. The protocol is 40 years old and beautifully open; the trust infrastructure built on top of it is where your weekend goes to die.
What you’re actually signing up for
- A cold IP with no history. Your fresh VPS address has zero reputation (or worse—check what the previous tenant did with it). You’ll be warming it from nothing, and low-volume senders can barely sustain a warm IP at all.
- The checklist that never ends. Reverse DNS. TLS configuration. SPF, DKIM signing and key management, DMARC. Bounce processing. Feedback loop registration with each provider. Rate limiting and greylisting handling per destination. Blocklist monitoring, and the delisting rituals when you land on one anyway.
- Opaque failure modes. When Gmail starts deferring your mail, there’s no support ticket to file. You get a cryptic SMTP response and a long night of deliverability archaeology. Providers publish postmaster guidelines, not explanations.
- Zero economies of scale. Sending platforms run high-reputation pools, monitor them constantly, and remove bad actors—work amortized across thousands of senders. Alone, you do all of it for an audience of you.
The part worth keeping
Here’s the nuance: SMTP the protocol is great. It’s the provider-agnostic standard that lets Laravel, Rails, Django, Supabase, or a 20-year-old ERP send mail without caring who’s behind the socket. You can keep that portability—point your framework’s SMTP settings at a provider (with Resend: smtp.resend.com, your API key as the password) and you’ve kept the interface while outsourcing the reputation management.
The actual exceptions
Hard data-locality or air-gap requirements, or you’re literally building an email provider. Both are real; neither is asking this website. For everyone else, your product deserves the engineering hours more than your MTA does.