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 Cloudflare replaces the box
Cloudflare Email Routing covers the part of a self-hosted 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. Cloudflare handles the IP reputation, the MX, the TLS, and the queue.
For sending, Cloudflare Email Services is the outbound counterpart: the Worker calls send_email and the platform signs and delivers the message through Cloudflare's own sending infrastructure, including the DKIM setup, the warm-up, and the bounce handling. The commitment you give up is control over the sending IP — for most teams that is a feature, not a bug.
The hybrid that is the most common answer
The shape most small teams settle on by mid-2026 is hybrid: Cloudflare Email Routing + Email Services on the wire, D1 for the searchable inbox rows, R2 for attachments, and a Worker for the dispatch logic. The data still lives in your Cloudflare account, the worker is still your code, and the inbox is still something you own end to end. What you have given up is the metal: no Postfix, no Dovecot, no SpamAssassin, no certbot, no fail2ban, no PTR record, no warm-up window.
This is the architecture Flowmails provisions when you connect a Cloudflare account. The Worker is installed in your account, not in ours — you can read every line of it and replace any piece. The D1 tables live in your account. The R2 bucket lives in your account. The dashboard and the REST surface are the only thing that runs on our infrastructure, and they talk to your Worker through the SDK over sdk.flowmails.net. The self-host email data in D1 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, the Cloudflare 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 hybrid Cloudflare shape is what self-hosted email looks like in 2026. You keep the data, you keep the control, you keep the ability to read every line, and you skip the Friday night reading Postfix logs. The runtime tour shows the data path of a single inbound message end to end.
