7 Things You Can Do With Cloudflare Email Routing

Most people enable Cloudflare Email Routing to forward hello@theirdomain.com to a Gmail account and stop there. The forwarding is the boring 5 percent. The Worker handler behind it is a programmable inbound-email pipe, and it is free.

The marketing screenshot for Cloudflare Email Routing is "forward an address to your real inbox." That works. But the same feature hands you an email() Worker handler that fires on every inbound message, so you can parse, store, classify, and act on mail without running a mail server. Seven things worth doing, ordered from five-minute win to inbound platform.

1. Consolidate addresses across domains without a mailbox each

Email Routing lets you point any address at a destination without provisioning a mailbox for it. Want sales@, support@, and noreply-replies@ to all land in one place? Map them as routing rules; no IMAP account, no seat, no per-mailbox fee. This is the classic use, and it is the right starting point because it forces you to get MX and verification working before you touch any code. If you have not enabled it yet, the order of operations matters: see setting up MX records for a Cloudflare inbox before adding rules, or routing rules will silently match nothing.

2. Run a free catch-all so no address bounces

A catch-all rule resolves every address at your domain, even ones you never created. Turn it on and literally-anything@yourdomain.com routes somewhere instead of bouncing. That sounds like a spam magnet, and it can be, so pair it with a handler that filters rather than a blind forward to your personal inbox. The real value is dynamic addresses: per-signup aliases, plus-addressing you actually control, or unique reply addresses per thread. For the patterns and the trade-offs, see the catch-all guide. Catch-all plus a Worker is where forwarding stops being a hack and starts being infrastructure.

3. Pipe inbound mail straight into a Worker

This is the trick that changes what Email Routing is. Bind a route to a Worker that exports an email() handler, and Cloudflare invokes it with the raw message on every inbound email. From there you control everything: read headers, stream the body, accept or reject, forward conditionally, or hand the message to the rest of your stack. No SMTP server, no polling, no cron. The full setup, including the wrangler.jsonc binding and a minimal handler, is in the Email Routing tutorial. The next four items are all things you do inside this handler.

4. Turn inbound email into a webhook or a database row

The most common Worker move is to convert an email into a structured event. Parse the sender, subject, and body, then fetch() your app's webhook endpoint, or write a row directly to D1 if your app lives on Cloudflare too. Inbound mail becomes a first-class trigger: a customer replies, your system reacts, no Zapier in the middle. The pattern (and the gotchas around verifying the message really came through your route) is covered in turning inbound email into a Worker webhook. Treat the email like any untrusted input: validate before you act on it.

5. Route per-tenant or per-brand addresses to different handlers

Because Email Routing is enabled per zone and the handler sees the recipient, one account can serve many domains and brands from a single Worker. Branch on the to address or the domain inside email(): support@brand-a.com goes to tenant A's logic, support@brand-b.com to tenant B's, each with its own templates, storage, or downstream webhook. For agencies and multi-brand setups this removes the "one mail provider account per client" tax entirely. The routing and isolation patterns are in custom domains per tenant, and the operational gotchas of running many brands on one account are collected in tips for running multi-tenant email on one Cloudflare account. Note the honest caveat: running many domains through one shared Worker is straightforward, but full per-tenant isolation (separate deployments, separate keys) is more deliberate work than a single branch statement.

6. Parse MIME, store attachments in R2, and make threads searchable

The raw message Cloudflare hands you is MIME, not a tidy JSON object, so the real work in the handler is parsing it: multipart bodies, encodings, attachments, and the header soup that ties a reply to its thread. Once parsed, the natural home for the message body is D1 and for attachments is R2 (zero egress, so re-reads are free). Put the bodies in an FTS5 table and the whole archive becomes searchable. This is the difference between "an email arrived" and "I have a queryable inbox." Building this by hand is doable but fiddly, which is exactly the layer a deployable stack like Tinbox ships for you on top of Email Routing.

7. Drive replies, tickets, and automated actions from inbound mail

With parsing in place, the handler can close the loop and act. Open a ticket, post to Slack, file a task, or send an automated reply that threads correctly so the conversation stays intact in the recipient's client. Reply threading is its own small science (in-reply-to and references headers, quoting, message IDs), and getting it wrong scatters one conversation into five; see reply-by-email threading for the rules. One honest limit to keep front of mind: the reply itself cannot go out over Email Routing or raw SMTP, because Workers cannot open outbound port 25 for direct-to-MX SMTP. Outbound goes through a provider HTTP API or a relay, so an inbound-to-reply flow is always inbound (Email Routing) plus outbound (a sender) wired together.

Where this leaves you

Cloudflare Email Routing is a free inbound pipe with a Worker on the end. Forwarding is the demo; catch-all, the email() handler, per-tenant routing, MIME parsing into D1 and R2, and email-as-a-trigger are the actual product surface. The two things it deliberately does not do are give you a webmail inbox and send mail, so a complete stack pairs Email Routing (receiving) with a sender (transactional out) and a place to read it (an inbox UI). For the receiving half end to end, see the steps to receive inbound email on your own Cloudflare account; for the outbound half, the ways to send email from Cloudflare Workers covers why the edge has no port 25. You can assemble all of that yourself from the links above, and plenty of people should.

If you would rather not hand-roll the MIME parsing, the D1 schema, the R2 attachment store, the search index, and the inbox UI, that bundle is what Tinbox deploys onto your own Cloudflare account in one command.

Deploy your own email stack: npx tinbox init <domain>. It runs the email() handler on your own Cloudflare account, so your data and mail stay yours.