Cloudflare Email Service
Retrieve current Cloudflare documentation and installed Workers types before
using API signatures, limits, pricing, or CLI commands. Email Service is evolving
and the Workers binding, REST API, SMTP, and Email Routing have distinct
contracts.
Choose the surface
| Need |
Use |
Reference |
| Send from a Worker |
Email binding |
sending.md |
| Send from outside Workers |
REST API or SMTP |
rest-api.md |
| Receive, forward, reject, or parse mail |
Email Routing email() handler |
routing.md |
| Configure domains or agent tooling |
Wrangler/API/MCP setup |
cli-and-mcp.md |
| Diagnose bounces, authentication, or reputation |
Deliverability |
deliverability.md |
Prefer the Worker binding inside Workers unless the existing application already
has a reason to use another supported surface. Do not invent one request shape
for all surfaces: field names and response envelopes differ.
Verify prerequisites and boundaries
- Resolve the exact account, domain, environment, and sending or routing
configuration before changing provider state.
- Confirm the sending domain is onboarded and that the target Worker environment
has the required binding.
- Keep API tokens and message secrets in the platform's secret mechanism, never
in source or diagnostic output.
- Treat inbound
message.raw as a single-use stream; buffer it once when several
consumers need the content.
- Forward only to destinations allowed by the current Email Routing contract.
- Preserve the existing application handler when adding email; do not expand a
delivery task into unrelated persistence, marketing, or workflow architecture.
For Agents SDK email, verify the installed Agents SDK version and read both the
Agents and Email Service documentation. Do not assume their release cadence or
types are synchronized.
Validate the owning path
Use a controlled address and a non-sensitive fixture. Verify the exact sender
domain, recipient handling, text/HTML or raw MIME shape, and the surface actually
used by the application. Distinguish provider acceptance, queueing, delivery,
bounce, forwarding, and application processing; one does not prove the others.
1---2name: cloudflare-email-service3description: Implement or debug Cloudflare Email Service sending, Email Routing, or an Agents SDK email handler. Use for the Workers email binding, Email Service REST API, SMTP, inbound `email()` handlers, domain onboarding, deliverability, or Cloudflare email tooling. Do not trigger for provider-neutral email design or non-Cloudflare mail services.4---56# Cloudflare Email Service78Retrieve current Cloudflare documentation and installed Workers types before9using API signatures, limits, pricing, or CLI commands. Email Service is evolving10and the Workers binding, REST API, SMTP, and Email Routing have distinct11contracts.1213## Choose the surface1415| Need | Use | Reference |16| --- | --- | --- |17| Send from a Worker | Email binding | [sending.md](references/sending.md) |18| Send from outside Workers | REST API or SMTP | [rest-api.md](references/rest-api.md) |19| Receive, forward, reject, or parse mail | Email Routing `email()` handler | [routing.md](references/routing.md) |20| Configure domains or agent tooling | Wrangler/API/MCP setup | [cli-and-mcp.md](references/cli-and-mcp.md) |21| Diagnose bounces, authentication, or reputation | Deliverability | [deliverability.md](references/deliverability.md) |2223Prefer the Worker binding inside Workers unless the existing application already24has a reason to use another supported surface. Do not invent one request shape25for all surfaces: field names and response envelopes differ.2627## Verify prerequisites and boundaries2829- Resolve the exact account, domain, environment, and sending or routing30 configuration before changing provider state.31- Confirm the sending domain is onboarded and that the target Worker environment32 has the required binding.33- Keep API tokens and message secrets in the platform's secret mechanism, never34 in source or diagnostic output.35- Treat inbound `message.raw` as a single-use stream; buffer it once when several36 consumers need the content.37- Forward only to destinations allowed by the current Email Routing contract.38- Preserve the existing application handler when adding email; do not expand a39 delivery task into unrelated persistence, marketing, or workflow architecture.4041For Agents SDK email, verify the installed Agents SDK version and read both the42Agents and Email Service documentation. Do not assume their release cadence or43types are synchronized.4445## Validate the owning path4647Use a controlled address and a non-sensitive fixture. Verify the exact sender48domain, recipient handling, text/HTML or raw MIME shape, and the surface actually49used by the application. Distinguish provider acceptance, queueing, delivery,50bounce, forwarding, and application processing; one does not prove the others.
swyxio