Cloudflare Email Routing alternative: what it can't do, and what to use instead

What Email Routing does well

Out of the box, Email Routing catches inbound mail at the MX layer for a Cloudflare-managed zone and forwards each message to a verified destination address. Configuration is point-and- click: enable the feature on the zone, add the MX records it publishes for you, verify the destination address, and you are done in under five minutes. For a solo developer who needs hello@theirname.dev to land in a personal Gmail, it is genuinely the easiest tool for the job.

Where it stops being enough

The trouble starts the moment you treat Email Routing as an email platform. There is no inbox; messages are forwarded, not stored. There is no outbox; you cannot send from hello@yourdomain.com without standing up an SMTP relay or paying for Email Services separately. There is no API for forwarding rules — the catch-all and per-address list are managed by hand, one rule at a time, through the dashboard.

If your product needs to read what arrived (a ticketing system, a chat product, a CRM, an automation), there is nothing to read against. The Worker receives the message and Email Routing hands it off — by the time your code sees it, the message has already left the CF edge.

The limits in concrete numbers

Email Routing has hard caps worth knowing about: the Workers free plan allows 100,000 requests per day, the paid plan 10 million before Workers Unbound billing kicks in. Each forwarded message counts as one request, but you also burn CPU time on parsing and address resolution. A 100KB message with three MIME parts can spend 50–80ms of CPU on a cold start. D1, the natural place to index and query your mail, allows 5 million reads and 100,000 writes per day on the free plan and 50 billion reads per month on the paid plan. R2 for attachments gives you 10 GB of free storage and 10 million Class A operations per month.

None of those numbers is the actual limit — the limit is that Email Routing itself doesn't give you a row to query. The Worker receives the envelope, and from that point on, what you build is up to you.

What "real email platform on Cloudflare" looks like

The shape most teams end up wanting: Email Routing (or Email Services for outbound) as the wire primitive, a Worker to receive and dispatch, D1 for indexed mail rows and route tables, R2 for attachments, and a control-plane UI on top. That is the architecture we walk through in the runtime tour — it is also the shape of Flowmails, which is essentially that stack plus a dashboard and a REST surface.

If you want the primitives without the dashboard, the Cloudflare Workers integration page shows the exact install path. If you want the whole package — inbox UI, send/receive API, route tables, AI draft, webhook fan-out — see how Flowmails provisions it.

When Email Routing is still the right tool

If you have one domain, one personal inbox behind it, and you never need to send from that domain, Email Routing is still the cheapest and fastest answer. It costs nothing beyond your Cloudflare zone subscription, it works in three clicks, and it stays out of your way. The moment your requirement list grows past that one bullet, the conversation has to move to a platform — Flowmails, or your own Worker.

Migration, when you are ready

Moving off Email Routing into a Worker-based pipeline is mostly a DNS change. You keep the MX records Cloudflare publishes for Email Routing (or swap them for Email Services if you want outbound too), add a Worker that subscribes to the email event, and start persisting rows. Existing forward rules are replaced by route-table entries — see the route tables explainer for the exact data shape. Most teams complete the migration in an afternoon, including the inbox backlog import.