Cloudflare Email Routing, and what you still have to build

If your domain is on Cloudflare, Email Routing is a checkbox away and it costs nothing. You create rules mapping addresses on your domain to destination addresses you have verified, Cloudflare publishes the MX records for you, and mail starts flowing. There is also a catch-all, and there are Email Workers — a Worker invoked with the inbound message instead of an HTTP request, which can forward it, reject it, or reply to it.

It is a genuinely good piece of free infrastructure, and for a large number of people reading this page it is the correct answer. We would rather say that in the first paragraph than have you discover we left it out.

The reason there is a comparison to make at all is that “a Worker can receive the message” and “your application can work with the mail” are separated by a surprising amount of engineering, and the gap is invisible until you are in it.

An Email Worker hands you the message as a stream. Here is where that starts, and it looks encouragingly short:

export default {
  async email(message, env, ctx) {
    // message.from, message.to and message.headers are available.
    // message.raw is a ReadableStream of the full RFC 5322 message.
    await fetch("https://your-app.example.com/hooks/inbound", {
      method: "POST",
      body: message.raw,
    });
  },
};

That works, and it is also the moment the problem moves rather than gets solved: your application now receives raw MIME over HTTP and has to parse it. So the parsing moves into the Worker, and the list of things you own grows:

• A MIME parser in the Worker. Multipart bodies, quoted-printable and base64 encodings, character sets that are not UTF-8, HTML alternatives, inline images referenced by Content-ID. Real mail from real clients breaks parsers in ways test fixtures do not.
• Attachment storage. A webhook body is the wrong place for a 20 MB PDF, so attachments go to R2 — which means bucket lifecycle rules, key naming, and signed download URLs with expiry.
• Retries, with state. If your endpoint is down, the Worker has one chance. Doing better means a queue, a backoff schedule and somewhere to keep the message meanwhile, because the message itself is not retained anywhere.
• Threading. Grouping a reply with the message it answers means storing Message-ID, In-Reply-To and References and resolving them — a table, an index and the edge cases where a client sends neither header.
• Sending, separately. Replying to the message currently being handled is supported. Replying an hour later, or sending anything not in reply to a live invocation, needs a different provider entirely — so you are back to SES, Resend or Postmark for the outbound half, with its own DKIM setup.
• Spam decisions. Whether to act on a message that failed SPF or looks like spam is a judgement your Worker has to make, from the headers, on its own.

Where the Cloudflare column says partly, it almost always means “possible, in a Worker you write and maintain”. That is a real answer, not a dodge — for some readers it is the preferred one.

These are not mutually exclusive, and the combination is a reasonable destination rather than a compromise. Keep your zone on Cloudflare — Email Routing and an inbound MX record for the same domain are the one thing that does conflict, since a domain has one set of MX records and they point at one receiver.

So the split is per domain or per subdomain:

• Cloudflare Email Routing on yourdomain.com for the handful of human addresses — hello, billing, you.
• Inboundr on mail.yourdomain.com or a dedicated domain for the machine addresses — ticket intake, agent inboxes, per-customer reply addresses. DKIM is per domain, so the subdomain signs independently and a reputation problem on one does not touch the other.

Plenty of accounts run exactly this way. Nobody should move their personal mail off free forwarding to make a comparison page tidy.

Because a domain has one MX record set, moving is a cutover rather than a gradual roll. The sequencing below avoids a window where mail bounces:

1. 1Decide the hostname first. If any address on the domain should stay on Cloudflare forwarding, use a subdomain for us — that turns a cutover into an addition, and step four stops being risky.
2. 2Add the domain or subdomain in the console and publish the DKIM record in Cloudflare DNS. This does not affect delivery, so it is safe while Email Routing is still live.
3. 3Create the endpoint that will receive the mail — a webhook, or a forward to the same mailbox Cloudflare was delivering to if you want a like-for-like swap first.
4. 4Lower the TTL on the existing MX record, wait for the old value to expire, then replace it with ours. Disable the Email Routing rules afterwards, not before.
5. 5Send a test message and confirm it arrives at the endpoint. The console shows the parsed message and the delivery attempt.
6. 6Keep the Cloudflare rules disabled but present for a week. Turning them back on and restoring one MX record is a five-minute rollback.