Cloudflare pushed Email Sending into public beta last week as part of Agents Week, with an announcement so thickly frosted in agent language that you could miss the actual product underneath. Strip the framing away and what’s shipping is a transactional email API with a Workers binding, a REST endpoint, SDKs in three languages, and automatic SPF, DKIM, and DMARC configuration. The agent hooks are real enough (the Agents SDK gets an onEmail handler, there’s an MCP server, a Wrangler CLI, and an open-source reference inbox) but they are integrations on top of the core service, not the core service itself.
The interesting question isn’t whether Cloudflare can build an SES competitor. It’s whether Cloudflare can run one without their own reputation problem eating the product from the inside.
The pricing tells you what kind of product this is
Email Sending is priced at $0.35 per 1,000 messages. SES is $0.10 per 1,000. Resend’s base plan is $20/month flat. This is the first Cloudflare service I can remember that costs more than the AWS equivalent at steady state, which inverts the usual pattern where Cloudflare wins on R2 egress or Workers invocations and treats hyperscaler pricing as a starting point to undercut.
The 3x markup suggests Cloudflare is pricing for the reputation work, not the compute. Sending SMTP packets is trivial. Keeping a pool of IPs out of Spamhaus, Barracuda, and every large mailbox provider’s internal blocklist is the whole job, and it is a full-time operational commitment indefinitely. The person running a large email sending service in the HN comments pegged this at fifteen years of ongoing engineering effort with most of their team’s work going into abuse mitigation. That is what the extra $0.25 per thousand is buying, or being asked to buy.
The reputation problem Cloudflare already has
Cloudflare’s CDN and WAF reputation among mailbox operators, anti-abuse researchers, and the Spamhaus crowd is not neutral. Spamhaus published a paper in 2024 flagging 1,201 unresolved SBL listings on Cloudflare infrastructure and noting that 10.05% of domains on their Domain Blocklist were on Cloudflare nameservers. That number has since dropped to 47 active listings, which is real progress, but the underlying tension hasn’t gone away. Cloudflare’s position on takedowns (minimal, legally-driven, deliberately neutral) works for a CDN where the IP reputation game is one-directional. It does not work for email sending, where the reputation flywheel is bidirectional and unforgiving.
Thomas Gauvin, the author of the launch post, responded in the HN thread that Email Service uses reserved IPs separate from Cloudflare’s general pools, and that they are ‘well aware’ of the deliverability stakes. I believe him on the IPs. The harder question is whether the same anti-abuse posture that works for the CDN business will be tolerated by Gmail and Outlook when the abuse vector is outbound email rather than hosted websites. Microsoft in particular is notoriously opaque about deliverability decisions, and their filters reject mail for reasons nobody outside the Exchange Online team can reliably diagnose.
The agent framing is mostly misdirection
The launch wraps everything in agent vocabulary: email is the ‘most accessible interface in the world,’ your agent can ‘orchestrate work across the platform and respond asynchronously,’ Agentic Inbox is a ‘reference application for email-native agents.’ The Cloudflare team are capable engineers and I don’t think this is accidental. Agents Week needed an email story, and positioning a transactional email API as agent infrastructure lets the launch ride the AI narrative without having to defend a pure ‘we built SES’ framing to the Cloudflare blog audience.
The actual agent-specific pieces are modest. The onEmail hook on the Agents SDK is genuinely useful if you are building a Durable Object per conversation thread, because the agent’s state naturally corresponds to an email thread’s identity. The address-based resolver routing support@yourdomain.com to a ‘support’ Agent instance is a nice primitive. The HMAC-signed reply routing to prevent header forgery is the kind of detail that shows someone on the team actually thought about email security, which is more than most ‘AI email’ products have done.
None of this changes the fundamental product. You could build an email-native agent on Resend and a queue today. What Cloudflare is selling is the bundle: sending, routing, Agents SDK, Durable Object state, R2 for attachments, Workers AI for classification, all in one billing relationship and one deployment target. That’s a real offer, but it is the same offer Cloudflare has been making across every other product category for three years. The agent framing is the wrapper.
What to actually do with this
If you are already on Cloudflare Workers and sending fewer than 100,000 transactional emails per month, switching from Resend or SES for the binding convenience probably makes sense once the beta matures. The $0.35 per thousand is more than SES but less than the total cost of operating your own sending domain reputation, and the env.EMAIL.send() binding removes an API key from your secrets list.
If you are sending volume (millions per month) and deliverability is revenue-critical, wait six months and watch the reputation data. Cloudflare has never operated an email sending service at scale before. The team running it can be excellent and the product can still end up in spam folders because the reputation game has physics that no amount of engineering effort can shortcut in the first year.
And if you are building an actual agent that sends email, the question to ask isn’t whether Cloudflare’s service works. It’s whether your agent should be sending email at all. Several HN commenters pointed out that agent-produced email is, almost by definition, unsolicited bulk messaging from the recipient’s perspective. The launch post’s examples (build notifications, shipping confirmations, support replies) are the ones that would pass that test. The pitch deck examples, where your agent reaches out to prospects or sends cold outreach on your behalf, are the ones that will burn the shared IP pool down for everyone else.