Prepare a domain for Cloudflare Email Service

Cloudflare Email Service combines Email Sending for transactional outbound mail with Email Routing for incoming processing/forwarding. Enabling one does not automatically configure the other.

Choose the capability and deployment

1. Review current service availability and plan requirements for arbitrary-recipient sending versus verified-destination sending/routing.
2. Onboard the sending domain and publish the exact authentication records Cloudflare supplies.
3. For a Worker, configure an appropriately restricted send_email binding. For an external application, use the separate account-scoped REST/SMTP authentication model.
4. For receiving, configure Email Routing DNS and its rule/Worker or verified forwarding destination separately.

Do not replace a production mailbox domain’s MX records merely to test outbound sending. A sending binding also does not authorize an arbitrary unverified From domain.

Verify the right environment

Confirm domain state, binding name/restrictions, recipient eligibility, and account limits before a controlled send. Local simulation behavior may differ from remote delivery; do not present a local success as live email delivery.

Keep account tokens in backend secrets, never in a browser. Workers bindings avoid embedding an account API token in normal Worker sending code.

MailKite can provide a higher-level application SDK/webhook path, but its domain verification and credentials remain independent. Do not silently switch a live domain’s delivery provider to use a code example.