What "self hosted email server" used to mean
In the 2000s, the canonical self-hosted mail server was a Linux box running Postfix for SMTP, Dovecot for IMAP, SpamAssassin or Amavis for spam filtering, OpenDKIM for signing, OpenDMARC for policy, and either a hand-rolled webmail on top of Roundcube or no webmail at all. You paid for a VPS, you configured a static IP, you waited for it to earn reputation, you kept it patched. It worked. It also took about a day to set up the first time and another half-day every time you added a domain.
The same shape is still possible today. Most of those packages still exist, still patch, and still integrate. What has changed is the deliverability bar: Gmail and Outlook have tightened their bulk sender requirements every year since 2023, and the bar is now high enough that a fresh IP with no history will get throttled for the first month. So the old self-hosted path now also includes a warm-up window, an explicit DMARC policy, a working unsubscribe header on bulk sends, and SPF aligned to the sending IP.
The real operational burden, line by line
The first cost is the server itself. A self-hosted mail server needs a static IP with reverse DNS, a 1 vCPU / 2 GB VPS at minimum, and ideally a second one for redundancy. That is roughly $10–$25 per month before you send a single email. The second cost is the security surface: SSH hardening, fail2ban or equivalent, a real TLS cert (Let's Encrypt via certbot is fine, but it has to renew), and the patches that come out every Tuesday for at least three different daemons.
The third cost is the deliverability work — PTR record, SPF, DKIM, DMARC, then the slow warm-up where you throttle to maybe 50 messages per hour for the first week. The fourth cost is the spam filtering — false positives on outbound are easy, false negatives on inbound mean your inbox becomes unusable. The fifth cost is the long tail: greylisting, FBL feedback loops, suppression lists, bounce classification, and the day your IP gets on a blocklist because someone spoofed your domain. None of these is a deal-breaker; together they are roughly one engineer-day per month of attention.
Where a domain provider takes over the box
Cloudflare Email Routing is the first provider we support, and it covers the part of a mail server that people actually want: it gives every address on your domain an MX record, catches the inbound message at the edge, and either forwards it to a verified destination or hands the envelope to a Worker for processing. You do not run Postfix. You do not run SpamAssassin. You do not run a greylisting daemon. The provider handles the IP reputation, the MX, the TLS, and the queue. Cloudflare is one option here, not a requirement — any domain provider with an email routing product can be pointed at Flowmails the same way.
For sending, you choose per domain: Cloudflare Email Sending or Resend. With Cloudflare, a thin sender worker is deployed into your own account with a single send_email binding, and it signs and delivers the message through Cloudflare's own sending infrastructure, including the DKIM setup, the warm-up, and the bounce handling. The platform calls it over HTTPS with a per-domain secret, so no long-lived Cloudflare credential sits on our side. With Resend, the same platform calls api.resend.com with your key. Either way, the commitment you give up is control over the sending IP — for most teams that is a feature, not a bug.
What Flowmails actually runs
The shape most small teams settle on by mid-2026 is a hosted platform with a thin edge: one mail worker, one API, one dashboard, and no MTA to operate. Inbound, your domain provider forwards to a per-domain routing address; a shared worker applies the route table, stores the message, and fires the webhooks. Outbound, the provider you picked for that domain does the delivery. The metal is gone — no Postfix, no Dovecot, no SpamAssassin, no certbot, no fail2ban, no PTR record, no warm-up window.
The part worth being precise about: the mail worker is one shared, multi-tenant deployment that Flowmails operates — not something we install in your account. Every tenant's mail is isolated by domain_id, and a domain's inbound mail arrives at a routing address of the form rec_{domain_id}@flowmails.net. Attachments live in platform storage keyed by domain id, and the route table — which local parts are accepted at all — sits in a shared KV namespace under the same key. You never migrate NS records, deploy a worker, or paste a long-lived token: you log in with your domain provider, tick the domain, and the platform writes the DNS records, the catch-all, and the forwarding rule through the provider's API.
The dashboard and the REST surface are the only things that talk to it, over sdk.flowmails.net. The where email data lives post walks through the data-residency side of that choice.
When to still run Postfix yourself
The honest answer is that there are still reasons to run your own mail server. If you are a regulated entity that needs the sending IP to live in a specific data center or under a specific ASN, a provider's shared sending IP is not for you. If you send more than 5 million emails per month and the per-message cost is a board-level line item, SES with a commitment discount still wins on raw unit economics. If you run a privacy-preserving service where the design is no third party sees the envelope, then yes, you need the box.
For the other 95% of teams — the SaaS startup, the indie developer, the small support desk, the side project that grew up — the hosted shape is what custom-domain email looks like in 2026. You keep control of the domain, the routing rules, the API key, and the ability to read every message through a documented API, and you skip the Friday night reading Postfix logs. The runtime tour shows the data path of a single inbound message end to end.