Binding reference Bindings

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

The send_email binding lets Workers send outbound email through Cloudflare Email Routing.

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
Authoring shape
Best for: Outbound notification email and controlled email-sending paths from worker code

Add the binding to config

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'

}

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first Send Email path close to the route, handler, or service method that needs it.

Keep this first path small enough that the config, env binding, and user-visible behavior are easy to review together.

Send one email from the worker

import { env } from 'devflare/runtime'

export async function fetch(): Promise<Response> {

await env.SUPPORT_EMAIL.send({

from: 'noreply@example.com',

to: 'support@example.com',

subject: 'New support request',

text: 'A customer asked for help.'

})

return new Response('sent')

}

Local and Remote Support

Devflare can run useful Send Email application behavior locally for ordinary development and tests. Cloudflare still owns production limits, quotas, billing, and deployed account behavior.

Outbound local support; distinct from inbound email event testing. Start locally with plus ; that lane should cover the normal Send Email application flow without requiring a Cloudflare connection.

Use Cloudflare when the assertion depends on deployed limits, account state, lifecycle behavior, billing, or other production-only Send Email details.

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.

Testing path

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.

Open the next page when you need it

Subpage

Send Email internals

Internals

Check emitted Wrangler , preview behavior, and Cloudflare-specific details.

Subpage

Testing Send Email

Testing

Pick the plus path first, then move to remote checks only when the test needs them.

Subpage

Send Email example

Example

Copy a fuller application path when the quick example is too small.