Email Sending enters private beta on Workers

Cloudflare has announced the private beta of Email Sending, a new capability for sending transactional emails directly from Workers. The feature joins the existing Email Routing product under the new Cloudflare Email Service umbrella, giving developers a unified API for both inbound and outbound email on the Cloudflare developer platform.

Email remains a critical channel for application developers, whether for signup validation, notifications, invoices, or increasingly as an interface for AI agents and automated workflows. Cloudflare is positioning Email Service as a simplification of what has traditionally been a fragmented and operationally heavy part of application development. Sending an email is reduced to adding a binding to a Worker and calling send:

export default {
  async fetch(request, env, ctx) {

    await env.SEND_EMAIL.send({
      to: [{ email: "[email protected]" }],
      from: { email: "[email protected]", name: "Your App" },
      subject: "Hello World",
      text: "Hello World!"
    });

    return new Response(`Successfully sent email!`);
  },
};

Deliverability as a platform concern

Email deliverability is treated as a first-class engineering problem rather than an afterthought. Cloudflare is integrating Email Sending with its DNS infrastructure to automate the configuration of SPF, DKIM, and DMARC records, so that receiving mail servers can verify the sending domain. The service also runs on Cloudflare's global network, which the company says helps keep latency low for emails delivered to users worldwide.

The rationale is straightforward: a magic link that arrives late can mean a lost user, and an email that lands in spam can break a core user flow. By handling the underlying deliverability mechanics, Cloudflare aims to remove the need for teams to manage their own sending infrastructure or configure it from scratch.

Built into the Workers development workflow

Email Sending is designed to feel native to the Workers ecosystem. Key aspects of the transactional email workflow are addressed directly:

  • Configuration is handled through the Email binding in wrangler.jsonc, eliminating the need to manage API keys or other secrets.
  • Developers can leverage existing Workers to process incoming mail, store attachments in R2, and offload email sending to background tasks via Queues.
  • Local development is supported: wrangler can emulate Email Sending locally, allowing testing of user journeys without switching between tools.
  • Production observability includes bounce rates and delivery events, so teams can investigate a missing email by examining delivery status rather than guessing.

For teams building on existing email tooling, Email Service is compatible with both REST APIs and SMTP for external service integration. Frameworks like React Email can continue to be used: render a template with the library and pass it to the send method as normal.

import { render, pretty, toPlainText } from '@react-email/render';
import { SignupConfirmation } from './templates';

export default {
  async fetch(request, env, ctx) {

    // Convert React Email template to html
    const html = await pretty(await render(<SignupConfirmation url="https://your-domain.com/confirmation-id"/>));

    // Use the Email Sending binding to send emails
    await env.SEND_EMAIL.send({
      to: [{ email: "[email protected]" }],
      from: { email: "[email protected]", name: "Welcome" },
      subject: "Signup Confirmation",
      html,
      text: toPlainText(html)
    });

    return new Response(`Successfully sent email!`);
  }
};

Combining inbound and outbound email

The complete picture involves more than just sending. Email Routing allows developers to create custom addresses on their domain and handle incoming messages programmatically with a Worker. This opens up several application patterns:

  • Using Workers AI to parse, summarize, and even label incoming emails, such as flagging security events or generating automatic responses.
  • Creating support tickets in systems like JIRA or Linear from emails addressed to [email protected].
  • Processing invoices sent to [email protected] and storing the attachments in R2.
export default {
  // Create an email handler to process emails delivered to your Worker
  async email(message, env, ctx) {

    // Classify incoming emails using Workers AI
    const { score, label } = env.AI.run("@cf/huggingface/distilbert-sst-2-int8", { text: message.raw" })

    env.PROCESSED_EMAILS.send({score, label, message});
  },
};

With both inbound and outbound paths available, a full loop can be closed entirely on Cloudflare. A Worker could receive an email to a support address, parse its content, create a ticket via a third-party API, and send an immediate confirmation back to the user with the ticket number — all from the same platform.

Pricing and availability

Email Sending will require a paid Workers subscription and will be charged per message. Cloudflare notes that final pricing is not yet set; the company plans to update its documentation and changelog and notify users before charging begins. Email Routing limits will remain unchanged.

The private beta is scheduled to launch this November. Developers interested in Email Sending can join a waitlist, while Email Routing remains available now and free of charge, and will be folded into the new email sending APIs as they become available.