클라우드플레어 이메일 서비스 퍼블릭 베타 오픈

Cloudflare Email Service: now in public beta. Ready for your agents 2026-04-16 Thomas Gauvin Eric Falcão 6 min read Email is the most accessible interface in the world. It is ubiquitous. There’s no need for a custom chat application, no custom SDK for each channel. Everyone already has an email address, which means everyone can already interact with your application or agent. And your agent can interact with anyone. If you are building an application, you already rely on email for signups, notifications, and invoices. Increasingly, it is not just your application logic that needs this channel. Your agents do, too. During our private beta, we talked to developers who are building exactly this: customer support agents, invoice processing pipelines, account verification flows, multi-agent workflows. All built on top of email. The pattern is clear: email is becoming a core interface for agents, and developers need infrastructure purpose-built for it. Cloudflare Email Service is that piece. With Email Routing , you can receive email to your application or agent. With Email Sending, you can reply to emails or send outbounds to notify your users when your agents are done doing work. And with the rest of the developer platform, you can build a full email client and Agents SDK onEmail hook as native functionality. Today, as part of Agents Week, Cloudflare Email Service is entering public beta , allowing any application and any agent to send emails. We are also completing the toolkit for building email-native agents: Email Sending binding, available from your Workers and the Agents SDK A new Email MCP server Wrangler CLI email commands Skills for coding agents An open-source agentic inbox reference app Email Sending: now in public beta Email Sending graduates from private beta to public beta today. You can now send transactional emails directly from Workers with a native Workers binding — no API keys, no secrets management. export default { async fetch(request, env, ctx) { await env.EMAIL.send({ to: " [email&#160;protected] ", from: " [email&#160;protected] ", subject: "Your order has shipped", text: "Your order #1234 has shipped and is on its way." }); return new Response("Email sent"); }, }; Or send from any platform, any language, using the REST API and our TypeScript, Python, and Go SDKs: curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/email-service/send" \ --header "Authorization: Bearer <API_TOKEN>" \ --header "Content-Type: application/json" \ --data &#039;{ "to": " [email&#160;protected] ", "from": " [email&#160;protected] ", "subject": "Your order has shipped", "text": "Your order #1234 has shipped and is on its way." }&#039; Sending email that actually reaches inboxes usually means wrestling with SPF, DKIM, and DMARC records. When you add your domain to Email Service, we configure all of it automatically. Your emails are authenticated and delivered, not flagged as spam. And because Email Service is a global service built on Cloudflare's network, your emails are delivered with low latency anywhere in the world. Combined with Email Routing , which has been free and available for years, you now have complete bidirectional email within a single platform. Receive an email, process it in a Worker, and reply, all without leaving Cloudflare. For the full deep dive on Email Sending, refer to our Birthday Week announcement . The rest of this post describes what Email Service unlocks for agents. Agents SDK: your agent is email-native The Agents SDK for building agents on Cloudflare already has a first-class onEmail hook for receiving and processing inbound email. But until now, your agent could only reply synchronously, or send emails to members of your Cloudflare account. With Email Sending, that constraint is gone. This is the difference between a chatbot and an agent. Email agents receive a message, orchestrate work across the platform, and respond asynchronously. A chatbot responds in the moment or not at all. An agent thinks, acts, and communicates on its own timeline. With Email Sending, your agent can receive a message, spend an hour processing data, check three other systems, and then reply with a complete answer. It can schedule follow-ups. It can escalate when it detects an edge case. It can operate independently. In other words: it can actually do work, not just answer questions. Here's what a support agent looks like with the full pipeline — receive, persist, and reply: import { Agent, routeAgentEmail } from "agents"; import { createAddressBasedEmailResolver, type AgentEmail } from "agents/email"; import PostalMime from "postal-mime"; export class SupportAgent extends Agent { async onEmail(email: AgentEmail) { const raw = await email.getRaw(); const parsed = await PostalMime.parse(raw); // Persist in agent state this.setState({ ...this.state, ticket: { from: email.from, subject: parsed.subject, body: parsed.text, messageId: parsed.messageId }, }); // Kick off long running background agent task // Or place a message on a Queue to be handled by another Worker // Reply here or in other Worker handler, like a Queue handler await this.sendEmail({ binding: this.env.EMAIL, fromName: "Support Agent", from: " [email&#160;protected] ", to: this.state.ticket.from, inReplyTo: this.state.ticket.messageId, subject: `Re: ${this.state.ticket.subject}`, text: `Thanks for reaching out. We received your message about "${this.state.ticket.subject}" and will follow up shortly.` }); } } export default { async email(message, env) { await routeAgentEmail(message, env, { resolver: createAddressBasedEmailResolver("SupportAgent"), }); }, } satisfies ExportedHandler<Env>; If you're new to the Agents SDK's email capabilities, here's what's happening under the hood. Each agent gets its own identity from a single domain. The address-based resolver routes [email&#160;protected] to a "support" agent instance, [email&#160;protected] to a "sales" instance, and so on. You don't need to provision separate inboxes — the routing is built into the address. You can even use sub-addressing ( [email&#160;protected] ) to route to different agent namespaces and instances. State persists across emails. Because agents are backed by Durable Objects, calling this.setState() means your agent remembers conversation history, contact information, and context across sessions. The inbox becomes the agent's memory, without needing a separate database or vector store. Secure reply routing is built in. When your agent sends an email and expects a reply, you can sign the routing headers with HMAC-SHA256 so that replies route back to the exact agent instance that sent the original message. This prevents attackers from forging headers to route emails to arbitrary agent instances — a security concern that most "email for agents" solutions haven't addressed. This is the complete email agent pipeline that teams are building from scratch elsewhere: receive email, parse it, classify it, persist state, kick off async workflows, reply or escalate — all within a single Agent class, deployed globally on Cloudflare's network. Email tooling for your agents: MCP server, Wrangler CLI, and skills Email Service isn't only for agents running on Cloudflare. Agents run everywhere, whether it’s coding agents like Claude Code, Cursor, or Copilot running locally or in remote environments, or production agents running in containers or external clouds. They all need to send email from those environments. We're shipping three integrations that make Email Service accessible to any agent, regardless of where it runs. Email is now available through the Cloudflare MCP server , the same Code Mode -powered server that gives agents access to the entire Cloudflare API. With this MCP server, your agent can discover and call the Email endpoints to send and configure emails. You can send an email with a simple prompt: "Send me a notification email at [email&#160;protected] from my staging domain when the build completes" For