vs Cloudflare Email·Bundled threat — Workers-tied·5 min read

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

www.cloudflare.com/products/email-routing/

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 in the closed beta— REST, SDK, and MCP. Cloudflare send is in beta with a limited surface.
Typed reply events— intent, entities, urgency, injection score, sender reputation parsed before reaching your code. 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.
Behavioral pool routing— send-side segregation by behavior. 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 outbound 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, point your domain MX records at mails.ai directly — we handle inbound delivery and typed-event parsing in one hop.

Side-by-side

Cloudflare Emailvs Mails.ai — feature matrix.

Dimension	Mails.ai	Cloudflare Email
Send API	Send is first-class — REST, SDK, MCP	Workers Email send in public beta (April 2026); not GA
Inbound API	Typed reply events delivered via webhook or MCP	Email Routing forwards inbound to Worker (raw MIME)
Typed reply events	Intent, entities, urgency, injection_score, sender_reputation	Worker receives raw MIME; you parse
Prompt-injection scanning	Six-category scanner, injection_score on every event	Not in scope
Behavioral pool routing	Behavioral classifier on send	Inbound-only product today; no send-side reputation management
MCP server	Drop-in MCP server for Claude Code, Cursor, etc.	No MCP support
Workers integration	Webhook-based (any infra)	Native — Email Routing → Worker as the design center
Edge distribution	Webhook-based delivery (your endpoint, your edge or origin)	Native — runs in Workers at the edge by default
Free tier	3,000 events/month + 1 agent	Email Routing free for unlimited volume on owned Cloudflare DNS domains
DDoS / abuse mitigation	Behavioral pool routing + per-agent reputation	Cloudflare's full edge protection stack against inbound abuse
Custom domain support	Phase 2 (DKIM CNAMEs + SPF + DMARC + MX)	Native — must be on Cloudflare DNS, then routing config in dashboard

FAQ

Questions readers ask after this page.

Cloudflare Email is free. Why pay for mails.ai?

Cloudflare Email is free for inbound routing into Workers. It does not send (yet — beta), it does not parse intent or entities, it does not scan for prompt injection, it does not provide reputation management. For an agent product that needs send + reply primitives + agent abstractions, the comparison is not really 'free vs paid' — it's 'inbound forwarding only' vs 'full agent-API surface.' Different shapes.

Workers Email is shipping send. Won't they catch up?

Workers Email send is a useful primitive — when GA, it will be a viable AWS SES alternative for Cloudflare-hosted apps. But like SES, it's raw send infrastructure, not the agent-API layer. The typed-event + injection-scanner + classifier abstractions are application-layer choices that Cloudflare's Workers product team is unlikely to prioritize, since their design center is general-purpose serverless compute, not agent-native communication.

Can I use both — Cloudflare Email for inbound routing, mails.ai for agent surface?

Yes, but it's redundant. Cloudflare Email Routing forwards inbound to a Worker; the Worker would then need to call mails.ai's parser API to get typed reply events. Simpler architecture: skip the Worker, point your DNS MX records at mails.ai directly. We handle the inbound delivery + typed-event parsing in one hop instead of two.

What about edge deployment?

Cloudflare Workers' edge model is appropriate when your agent-runtime itself runs on Workers (low latency, distributed). Mails.ai delivers via webhook to whatever your agent runtime is — Vercel, Lambda, GCP, your own infrastructure, including a Cloudflare Worker. The choice of whether your agent runs on the edge is independent of which email API you use.