Configuration

Sender domains, Cloudflare email bindings, recipient settings, and branded templates for transactional and product emails in Edge Kit.

Email configuration connects the messages your application renders to the domain that delivers them. Edge Kit already supplies React templates, translated subjects, HTML and plain-text rendering, and a shared sender used by auth flows, contact submissions, and background jobs.

Use your own verified domain and sender identity before sending customer email. Template previews can run independently while you prepare delivery.

Sender identity

The sender consists of a display name and an email address, for example My App <noreply@example.com>. Customers see that identity in their inbox, so it should match the product they registered for.

EMAIL_FROM supplies the default sender. Cloudflare's email binding also restricts which addresses the Worker may use. In the example above, the allowed address is noreply@example.com, without the display name.

Your environment values might look like this:

EMAIL_FROM="My App <noreply@example.com>"
CONTACT_EMAIL="support@example.com"

Replace both addresses with your own. The first is the verified outgoing identity; the second is the inbox that receives contact submissions.

Setting	Purpose
`EMAIL_FROM`	Default name and address for outgoing messages
`CONTACT_EMAIL`	Destination for contact form submissions
`EMAIL` binding	Delivery connection available to server operations
Allowed sender addresses	Addresses the binding permits the app to send from

An optional sender override still needs to satisfy the binding restrictions. Keep contact destinations and sender choices on the server; public form input should not choose arbitrary delivery recipients.

Domain and binding

Configuring the email delivery infrastructure for your application ensures that transactional and product messages reliably reach customers and users.

This involves verifying the sender domain, aligning environment variables, and integrating with Cloudflare's Email Service via appropriate Worker bindings.

Verify your domain

Onboard the sending domain through Cloudflare Email Service and complete its DNS verification requirements. Use Cloudflare's current setup instructions for the records required by your account.

Configure the sender

Set EMAIL_FROM for the environment and align its address with the email binding's allowed senders. The Wrangler email configuration shows the declaration already used by the kit.

Set CONTACT_EMAIL to an inbox your team can access. This address receives contact submissions and does not need to be the same as the outgoing sender.

Check a real message

With the production binding and verified sender, trigger an application message to a controlled recipient. Check the sender, subject, body, plain-text alternative, and destination links together.

Keep environment values with the corresponding deployment. A production email containing a localhost verification link usually points to an application-origin problem, not a rendering problem.

Branding and language

Shared layouts provide a consistent frame for account messages and product emails. Update their logo, product name, colors, support links, and footer alongside your application branding.

Use absolute, publicly reachable URLs for images displayed in email. An email client cannot resolve a development-only asset or a private route requiring the customer's application session.

Subjects and copy use the kit's translation catalogs. Pass the intended recipient's locale when the application sends a message, particularly for queued work that runs outside the original browser request. The base locale is the fallback when no locale is supplied.

The email overview covers the preview server and existing templates. Check longer translations in both the HTML layout and plain-text version before adding a new message to a customer flow.

Replies and recipients

The sending integration accepts a recipient address or an array and an optional reply-to address. A reply-to address directs customer replies without changing the verified sender identity.

For a product notification, you might send from a consistent product address and direct replies to support. For a contact submission, the recipient comes from your contact configuration while the submitted address belongs to the message context.

Only use customer-supplied addresses after appropriate validation, and retain the bot protection on public submission flows. Forms explains the included contact pattern.

Development modes

There are three distinct ways to inspect email:

Mode	Result
Template preview	A browser rendering using example template variables
Local application delivery	A simulated message produced by an actual application flow
Remote delivery	A real message sent using your Cloudflare account

The shipped local email binding uses simulated delivery. A successful local send therefore does not establish that your domain can reach a real inbox. Email delivery covers local output and deliberately enabling remote sending.

Delivery checks

Test at least one verification or reset message, one contact submission, and a queued welcome message. Together they cover direct sending, the configured contact destination, recipient language, and delayed processing.

If the template renders but no production message arrives, inspect domain verification, sender restrictions, and delivery logs. If direct messages work but a queued one does not, inspect the job and its eligibility checks through observability.

On this page