How Devflare wires Send Email from config to runtime
The send_email binding lets Workers send outbound email through Cloudflare Email Routing.
Send Email compiles into Wrangler output, normalizes message input at runtime, and supports local address restrictions instead of treating email as an unbounded free-for-all.
That runtime normalization is worth calling out because it lets worker code send higher-level message shapes while Devflare translates them into the lower-level form the email path needs.
- Normalization
- The schema normalizes address restrictions and runtime message helpers normalize composed email input
- Compile target
- Wrangler
- Preview note
- Address rules compile as authored; there is no separate preview resource lifecycle for email destinations
How authored config becomes Wrangler config
The schema work here is less about ids and more about safety rules: which addresses are permitted and which combinations are invalid.
At runtime, Devflare can normalize higher-level email message shapes into raw MIME-backed delivery when the outbound path needs it.
Send Email config and emitted Wrangler output
Use this when you need to check how the Devflare config becomes Wrangler-compatible config.
What local runtime support covers
- Local send-email bindings can be created and enforced in the default runtime/test context.
- Address restrictions are part of the local contract, which keeps the binding honest during development.
- Inbound email helper APIs exist too, but they serve the inbound event story rather than replacing outbound bindings.
Compile, preview, and cleanup behavior
- Compile turns the authored send-email rules into Wrangler-facing entries.
- The binding rules are emitted as-is; there is no preview resource provisioning story for destination addresses or sender allow-lists.
- The runtime normalization step is the subtle part worth documenting because it shapes how friendly outbound code can look.
Safety rules are part of the binding
The point of the schema is not only to make email possible. It is also to keep where the worker may send email visible and reviewable.
Cloudflare docs vs the Devflare layer
Cloudflare send_email binding docs is the platform reference. Use this internals page when you need to compare Cloudflare's product docs with Devflare config, generated env types, local support, and preview behavior for .
| Question | Cloudflare docs | This Devflare page |
|---|---|---|
| Primary focus | Platform reference for send_email binding restrictions, verified destinations, and Email Workers setup. | How to author , what the runtime surface looks like, and how Send Email fits a Devflare project. |
| Testing and runtime lens | Cloudflare’s docs focus on the raw binding API, product semantics, and platform limits for the binding itself. | Outbound local support; distinct from inbound email event testing. Use the Devflare guidance when you need the honest local harness or the right remote gate instead of only the product API shape. |
| When to open it | When you need the platform contract, limits, APIs, or account-level product details. | When you are wiring, testing, previewing, or reviewing the binding inside a Devflare app. |
Previous
Send Email
Send Email is a real binding surface in Devflare, and it is worth documenting separately from inbound handlers so the two flows do not get blurred together.
Next
Testing Send Email
Send Email is stronger locally than many platform-service bindings because outbound email can be exercised in the default harness, while inbound email has its own related helper surface.