Binding reference Bindings

Use Send Email when the worker should send outbound email with explicit address rules

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.

That distinction matters because outbound email is a binding you call from worker code, while inbound email handling is a worker event surface with its own test helper story.

Config key: bindings.sendEmail
Authoring shape: Record<string, { destinationAddress?; allowedDestinationAddresses?; allowedSenderAddresses? }>
Best for: Outbound notification email and controlled email-sending paths from worker code

Author it in the simplest shape that still says what you mean

Send Email bindings are easiest to trust when the allowed addresses are visible in config rather than buried in some last-minute secret or helper wrapper.

Devflare validates the main mutual-exclusion rule here too: use either one or a list of , not both.

Send Email binding authoring

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'email-worker',

bindings: {

sendEmail: {

TRANSACTIONAL_EMAIL: {

allowedDestinationAddresses: ['ops@example.com'],

allowedSenderAddresses: ['noreply@example.com']

SUPPORT_EMAIL: {

destinationAddress: 'support@example.com'

}

})

When this binding fits best

Use Send Email when the worker needs to send notifications or transactional messages outward.
Keep address restrictions explicit so the worker cannot quietly send anywhere it pleases.
Do not confuse outbound send-email bindings with inbound email processing handlers.

Notes worth keeping visible

and are mutually exclusive in one binding definition.
The local story for outbound email is strong, but it should still be documented separately from inbound email event helpers.
Preview resource lifecycle does not manage email addresses the way it manages storage resources, because the binding compiles the address rules as-is.

Outbound is not inbound

and handler tests are connected by the domain, but they are different contracts and should be documented that way.

Cloudflare docs vs the Devflare layer

Cloudflare send_email binding docs is the platform reference. This page is the Devflare translation layer: keep readable in source, understand the typed env surface, and know which local, preview, or remote lane actually matches the binding.

Reference

Cloudflare send_email binding docs

Cloudflare Docs

Platform reference for send_email binding restrictions, verified destinations, and Email Workers setup.

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.	First-class 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.

Go deeper only if this one-page guide stops being enough

Subpage

Send Email internals

Internals

See normalization, Wrangler , and the preview or runtime details behind the authored shape.

Subpage

Testing Send Email

Testing

Start from plus and only escalate when the binding or deployment model genuinely needs it.

Subpage

Send Email example

Example

Adapt one small end-to-end path before you hide the binding behind a bigger abstraction.