Self-Host Email vs Use an API: A Decision Framework

Every team that ships email eventually has the same conversation. Someone in engineering says "we should just self-host this, it's only Postfix" and someone in ops says "we tried that in 2019 and it ate three weekends a quarter." Both are right, and neither answer settles the question.

This post is a decision framework, not a sales pitch. PostStack does both — we run our own Postfix and Dovecot in Hetzner, and we expose them as an API plus mailboxes you can rent. So the question we get asked weekly, by people evaluating us against rolling their own, is fair: when does self-hosting actually make sense, and when are you about to set €500/month worth of operator time on fire to save €30 in API fees? Here's how to answer it for your situation.

What you're actually deciding

"Self-host" and "use an API" are too coarse. There are at least four distinct options on the spectrum, each with a different cost shape:

1. Pure SMTP relay (you run Postfix, you own deliverability). A Hetzner box, a Postfix install, your own DKIM/DMARC/SPF, your own bounce handling, your own RBL monitoring. €5/month for the VPS, plus your time.
2. Smart relay (you run Postfix, but route through someone else's MX). You keep an internal-facing relay for queueing and retries, and hand outbound mail off to AWS SES, Postmark, or PostStack for last-mile delivery. They own reputation; you own queueing and shape. Common in Kubernetes shops where every pod can talk to a local relay.
3. API-only (you call POST /emails, they do everything). The Resend/Postmark/SendGrid model. Fastest to integrate, slowest to escape.
4. Hybrid (you run mailboxes for inbound and an API for outbound). This is what most teams converge on after a year — programmatic outbound through an API, real human inbox at support@ through IMAP. PostStack exposes both. So does Migadu (mailboxes only) plus your favourite API (outbound). Most other big-name providers don't offer this — that's why you see this shape land here.

If you start the conversation as a binary, you'll pick the wrong answer. The right question is which combination of the four matches your team and traffic shape.

The five variables that decide

There are exactly five variables that should drive this. Most "build vs buy" essays ignore the operational ones and over-weight the per-message cost.

1. Volume and shape

Below ~50,000 emails/month, the cost difference between any provider and self- hosting is rounding error. The dominant cost is your time, and self- hosting at low volume gives you a steady drip of small operational tasks (TLS cert rotation, RBL appeals, Postfix updates) that don't justify themselves.

Above ~5,000,000 emails/month, the API per-message cost compounds visibly. At 5M sends with Postmark or SendGrid you're paying €1,000-2,000/month. A self-hosted setup at that volume is €100/month in infrastructure plus a serious deliverability engineer's attention. The math starts favouring DIY.

Between those two, traffic shape matters more than volume. A smooth 100k/month is easy. A 100k/month that's actually 90k in two days around your monthly billing run is a deliverability problem — burst sending will get you graylisted at Gmail and blocklisted at smaller MTAs unless you've warmed your IP. Providers handle this for you with shared pools and reputation buffers; self-hosters absorb it themselves.

2. Deliverability sensitivity

Ask yourself one question: if 5% of our emails silently disappear into spam for a week, how bad is that?

• Internal CI notifications? Annoying, but recoverable. Self-host is fine.
• Password reset emails for a SaaS? You'll have churned customers before you notice. Pick a provider that publishes inbox placement rates.
• Invoice and dunning emails? You will literally lose revenue. Don't self-host unless you have someone full-time on deliverability.
• Marketing broadcasts to a cold list? Your reputation will be ruined within a month either way. Self-hosting buys you slightly more control over the ruins.

Deliverability is not a "set up DKIM and go" problem. It is an ongoing relationship with Gmail, Outlook, Yahoo, and the smaller MTAs. Their reputation models have at least a 30-day memory. A bad week becomes a bad month becomes a switched provider. If you self-host, you are signing up to be in that loop forever.

3. Compliance and data residency

If you ship to European customers, you have a non-trivial GDPR conversation about where email content is stored. We covered this in detail in our GDPR-compliant email API guide — short version, US-headquartered providers carry US CLOUD Act exposure even when they route through EU regions, and several DPAs have ruled this out for certain workloads.

Self-hosting on a German VPS sidesteps that completely. You are the controller, your hosting provider is the processor, and there is no third-party data path to explain to the auditor. For some buyers — public sector, healthcare, regulated fintech — that simplicity alone is worth the operational cost. For others — consumer SaaS, B2B tooling — the EU-headquartered API providers (PostStack, Mailjet, Tipimail) give you the same compliance posture without the operational burden.

4. Inbound email needs

If your product needs inbound email — support@yourcompany.com, reply parsing, ticket creation from email, IMAP access for a customer — you have already narrowed your options. Most transactional email APIs are outbound-only. You need either:

• An IMAP/POP3 server (Dovecot, Stalwart, Cyrus) you run yourself.
• A managed mailbox provider (Migadu, Fastmail, Zoho) glued to your outbound API.
• A platform that does both — PostStack mailboxes are real Dovecot mailboxes managed via the dashboard, with IMAP/POP3/submission credentials and webhook delivery on inbound.

The reason most APIs don't offer this is that running mailboxes is operationally very different from running outbound. Storage costs, IMAP idle connections, per-user authentication, sieve filters — these don't compose neatly into a "send" endpoint. If you don't need inbound, ignore this column. If you do, halve the list of viable providers immediately.

5. Operator availability

This is the variable nobody puts on the spreadsheet, and it dominates everything else. Self-hosting Postfix is not technically hard. The hard part is thecontinuous attention: Hetzner pulls a route, your IP gets listed at Spamhaus for an hour, a Yahoo postmaster ticket needs a response, a customer's DMARC report shows an alignment failure on a Tuesday morning.

If your team has someone whose job already includes "deliverability engineer" or "email administrator," self-hosting is reasonable; you're paying them anyway. If your team is three engineers shipping product, every hour spent on email is an hour not spent on the thing customers pay you for. The right comparison there isn't €30/month vs €5/month — it's €30/month vs the €500/month opportunity cost of an engineer-week per quarter.

The two scenarios where self-hosting clearly wins

Despite all of the above, there are two situations where rolling your own is the right call.

1. Internal-only or strict-network email. If the email never leaves your network — service-to-service notifications, internal monitoring digests, CI build emails to a closed group — you don't need deliverability reputation because Gmail isn't in the loop. A Postfix on the same VPC as your apps, submitting to your internal MX, is the simplest possible answer.

2. Massive sustained volume with dedicated infrastructure team. Above 10M sends/month, with someone whose job is email, the per-message economics flip. You are SendGrid's customer at that point, paying their margin on every send. Building your own version of what they do is a defensible engineering project.

If you are not in one of those two situations, an API is almost certainly the right answer.

The scenario where an API clearly wins

A SaaS team of fewer than fifteen engineers, sending fewer than 1M emails/month, where any single bad week of deliverability is felt by paying customers. This is the population that should never self-host outbound. The opportunity cost of every engineer-hour is high; deliverability is genuinely hard; the cost of an API at this volume is a rounding error in the company's budget.

Within that, the choice between providers narrows on three variables: pricing, compliance, and feature scope. PostStack's pricing page covers our take — €5/month for 10,000 emails, no metered surprises, EU data residency by default, mailboxes and broadcasts on the same plan. We're not the right answer for everyone, but we are the right answer for "EU-positioned SaaS that wants both API sending and real mailboxes from one provider."

The hybrid pattern most teams end up with

A surprising number of teams converge on the same answer after eighteen months, regardless of where they started:

• Outbound transactional email through a provider's API (low volume, high sensitivity, want someone else's reputation).
• Inbound email and team mailboxes via either a managed mailbox host or a platform that does both.
• An internal SMTP relay for service-to-service email, ops digests, and CI notifications — usually a Postfix container in their own infrastructure.
• Marketing broadcasts through whichever provider has the better list-management tooling — or, increasingly, whichever provider also handles transactional, to keep the operator surface area small.

This isn't a stable architecture because anyone designed it; it's an emergent pattern from "what hurt us least over time." The pattern is what PostStack is built around — outbound API, mailboxes, broadcasts, and an SMTP submission endpoint for the cases where you really do want to talk to us via SMTP from a smart relay.

The decision framework

If you've read this far, here's the framework in five questions. Answer them in order; the first "no" tells you the answer.

1. Is the email purely internal or to a strictly closed list? If yes, self-host a Postfix and stop reading.
2. Are you sending more than ~5M emails/month with a dedicated email engineer? If yes, self-host with a real warm-up plan and someone responsible for inbox placement.
3. Are you in the EU and is data residency on your DPIA? If yes, you want an EU-headquartered API provider, not US-hosted, regardless of region.
4. Do you need inbound email or mailboxes for product or support? If yes, you need either Dovecot you run, a managed mailbox host glued to an outbound API, or a platform that does both.
5. Do you have an engineer whose job already includes deliverability? If yes, self-hosting is plausible. If no, an API is going to be cheaper than you think once you price your own time honestly.

What PostStack actually optimises for

We are deliberately positioned at the intersection of small to mid-volume SaaS, EU-headquartered companies, and teams that want both outbound and mailboxes from one place. We are not the cheapest at huge volume — at 50M sends/month, AWS SES will beat us. We are not US-headquartered, so if your customers are mostly in the US it doesn't matter that we're EU. We are not a replacement for an internal SMTP relay.

What we do well is "EU SaaS at <1M sends/month that needs predictable pricing, working DKIM/DMARC out of the box, mailboxes on the same plan, and a free tier generous enough to evaluate without a credit card." If that's you, the pricing page lays out the plans and /alternatives covers the head-to-head with the major providers.

And if you read all this and concluded "no, I really do want to self-host" — honestly, good. The world needs people who run their own Postfix. We just want you to have made the choice deliberately rather than because someone in standup said "how hard can it be."