Cloudflare Email Routing is free and it works. It also assumes your DNS lives at Cloudflare, that every destination can click a verification link, and that anything beyond forwarding is a Worker you write yourself.
| Capability | MXcatch | Cloudflare Email Routing |
|---|---|---|
| Price | Free plan; paid tiers on the pricing page | Free |
| DNS must be at one provider | No — any DNS host | Yes — the zone must be on Cloudflare |
| Forward to any address | Yes | Only to addresses verified with Cloudflare first |
| Catch-all | Yes | Yes |
| Webmail inbox | Yes, on every plan | No |
| Webhooks | Built-in action, signed JSON, 5 retries | Only by writing an Email Worker |
| Custom processing | Configured in the UI | JavaScript you write and maintain |
| Archive to object storage | Built-in action | Worker plus R2, written by you |
| Routing rules | Sender, recipient, subject, body, regex | Address-level, or logic in a Worker |
| Message logs | Yes, with per-action status | Limited |
| Hosting | EU — Germany and Amsterdam | Global anycast |
Compiled from publicly documented behaviour. Cloudflare ships quickly — check their docs for the current state before deciding.
It is free, at any volume, with no plan to age out of. If your zone is already on Cloudflare, setup is a few clicks and the MX records configure themselves. For "route hello@my-domain.com to my Gmail", it is an excellent answer and this page is not going to talk you out of it.
Every forwarding target must confirm a link Cloudflare emails to it. Perfect for your own mailbox. Awkward the moment the destination is a shared address you do not control, a client's inbox, or an automated system with nobody to click anything.
Email Routing only works on zones Cloudflare hosts, and it manages the MX records itself. If your DNS lives at your registrar, Route 53, or a provider you chose for other reasons, using it means moving the zone. MXcatch needs two MX records wherever your DNS already is.
Anything else — a webhook, an archive, a Slack post — means an Email Worker. That is real JavaScript you write, deploy and own: parsing the MIME tree, decoding transfer encodings, pulling out attachments, storing them in R2, signing your own requests, and handling your own retries. It is a capable escape hatch, and it is also a project.
In MXcatch the same outcomes are actions you configure. The webhook arrives parsed and HMAC-signed with retries already handled; the archive is a prefix in a form field.
Email Routing has no inbox. Mail must go somewhere else to be read, which means every address you create needs a destination account behind it. MXcatch includes webmail on every plan, so a catch-all domain is readable without wiring it into a mailbox first.
When a message does not arrive, there is not much to look at. MXcatch keeps a log of every message with its per-action outcome — delivered, partial, failed with the error, or filtered if a rule dropped it.
These are not mutually exclusive, and the split is often the right answer. Keep Email Routing on the apex for personal forwarding, and point a subdomain such as inbound.your-domain.com at MXcatch for the mail that needs to become data. Nothing about your existing setup changes; you are adding a lane rather than switching.
mx1.mxcatch.net at 10, mx2.mxcatch.net at 20. MX records are DNS-only; the proxy toggle does not apply.ImprovMX if you want dedicated forwarding with outbound sending, and Mailgun Routes if you are already sending through Mailgun.
Two MX records at any provider, and a free plan to try it on.
Create your free account