Cloudflare Email vs Mails.ai — Workers-bundled routing vs agent-native

Cloudflare Email Routing is free if your domain is on Cloudflare. It forwards inbound email to a Worker. That’s the whole product. Mails.ai is a full email API for agents — send, receive, parse, and scan.

Cloudflare Email Routing is inbound forwarding bundled into the Workers ecosystem. Public Workers Email send is in beta as of April 2026. For Cloudflare-hosted apps wanting free inbound routing into a Worker, it is the natural choice. For an agent product that needs send + reply primitives + agent abstractions, the comparison is between different scopes, not features.

What Cloudflare Email does well

• Free for inbound routing. If your domain is on Cloudflare DNS, Email Routing forwards inbound to a Worker at no cost regardless of volume. Hard to beat $0/mo.
• Edge-native. Runs in Workers at Cloudflare’s edge by default. Low latency for compute that processes inbound mail.
• Bundled into the Workers ecosystem. If your agent-runtime is on Workers, the integration is one config block in the Worker’s wrangler.toml. No separate service to wire up.
• Cloudflare’s edge protection. The full DDoS/abuse mitigation stack applies to your inbound. Reasonable defaults on volumetric attacks.
• Simple setup on owned domains. If you control DNS in Cloudflare, enabling routing is a few clicks in the dashboard.

Where mails.ai is built differently

Cloudflare Email is inbound-only today. Workers Email send is in public beta. Even when send GAs, the surface is raw infrastructure (like SES), not the agent-API layer on top:

• Send is first-class today — REST, SDK, and MCP. Cloudflare send is in beta with a limited surface.
• Typed reply events — an injection score and sender reputation on every event before it reaches your code, and intent, entities and urgency on first-contact mail when classification is on (paid plans). Cloudflare delivers raw MIME to your Worker. See that post.
• Prompt-injection scanning — six-category scanner on every inbound. Cloudflare provides no equivalent. See that post.
• Per-agent reputation — send-side reputation scoring with suppression-at-send and complaint auto-suspend. Cloudflare does not do send-side reputation management today.
• MCP-native — one config snippet for Claude Code, Cursor, etc. Cloudflare has no MCP server.

When to pick Cloudflare Email

• Your product runs on Cloudflare Workers and you want inbound routing as a Workers binding.
• You need free inbound at any volume (and your domain is on Cloudflare DNS).
• Your inbound use case is “forward to a Worker that does X” rather than “deliver structured reply events to my agent runtime.”
• You are comfortable building the typed-event + injection scan + classifier layer yourself in your Worker.

When to pick mails.ai

• You need send + reply primitives, not just inbound forwarding.
• Typed reply events + injection scanning + reputation are load-bearing.
• Your agent runtime is not on Cloudflare Workers (Vercel, Lambda, GCP, custom, etc.).
• MCP-native distribution to Claude Code / Cursor matters.
• You want one vendor for the full agent-mail surface, not a stack of Cloudflare + something-else.

Architectural note

Cloudflare Workers is excellent serverless compute at the edge. If your agent runs on Workers, you have a sensible architecture: Cloudflare Email Routing → Worker (your code) → mails.ai for sends. The inbound side stays on Cloudflare; the send + reply primitives + structured reply events come from us. Two-vendor stack but each does what it is best at.

Most agent products though prefer one-vendor for the email surface so that send and reply share the same identity, reputation, and dashboard. In that case, forward each address to its agent’s forwarding address on mails.ai, from Email Routing or any mail service, with no MX change — we handle inbound delivery and typed-event parsing in one hop.