Cloudflare Email Workers

Programmatically handle incoming email at the edge — parse, filter, forward, and trigger actions.

CloudflareIntermediate

Why

Email Workers let you run code on incoming email without a mail server. Parse MIME, check SPF/DKIM, forward to Slack, or auto-reply.

Free tier: 100k emails/month, no Postfix maintenance.

When

Use for support@ auto-routing, abuse@ parsing, bounce processing, and inbound email-to-webhook. Avoid for sending outbound email (use Resend/SES) or heavy spam filtering.

How

1. Enable Email Routing — dashboard → Email → Enable 2. Add catch-all or address rule → route to Worker 3. Write handler — export default { async email(message, env, ctx) {...} } 4. Parse — message.raw (ReadableStream), message.from, message.to, message.headers 5. Forward — message.forward("real@inbox.com") or message.setReject("550") 6. Reply — use MailChannels binding (free outbound from Workers) 7. Test — wrangler dev with --email flag simulates inbound

Example

export default { async email(message: ForwardableEmailMessage, env: Env, ctx: ExecutionContext) { // Reject if not from trusted domain if (!message.from.endsWith("@trusted.com")) { message.setReject("550 Not authorized"); return; } // Parse subject, route by prefix const subject = message.headers.get("subject") || ""; if (subject.startsWith("[URGENT]")) { await fetch(env.SLACK_WEBHOOK, { method: "POST", body: JSON.stringify({ text: `Urgent: ${subject}` }) }); } // Forward to real inbox await message.forward("support@real-inbox.com"); }, };

Common Problems

⚠No outbound by default — Email Workers are inbound-only, use MailChannels/Resend for sending
⚠10MB message size limit — large attachments truncated, offload to R2 via stream
⚠SPF/DKIM not auto-verified — check headers manually before trusting from address

Best Practices

✓Verify SPF/DKIM before acting — message.headers.get('received-spf'), prevent spoofing
✓Stream large messages to R2 — don't buffer in memory, 128MB Worker limit
✓Use catch-all + routing logic — one Worker handles all addresses, simpler than per-address

FAQ

What is Cloudflare Email Workers and what problem does it solve?

Programmatically handle incoming email at the edge — parse, filter, forward, and trigger actions. It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.

How do I get started with Cloudflare Email Workers in 5 minutes?

Two steps to run it: (1) Enable Email Routing — dashboard → Email → Enable; (2) Add catch-all or address rule → route to Worker. Validate on the free tier first, then wire into production.

What is the #1 pitfall with Cloudflare Email Workers?

The most frequent issue is: No outbound by default — Email Workers are inbound-only, use MailChannels/Resend for sending. Run a pre-launch checklist item by item, and add policy/config scanning in CI.

What are the best practices for Cloudflare Email Workers?

Best practices for Cloudflare Email Workers include: Verify SPF/DKIM before acting — message.headers.get('received-spf'), prevent spoofing; Stream large messages to R2 — don't buffer in memory, 128MB Worker limit; Use catch-all + routing logic — one Worker handles all addresses, simpler than per-address. The first one — "Verify SPF/DKIM before acting — message.headers.get('received-spf'), prevent spoofing" — should be a team default baked into your IaC templates.

How do I control cost and avoid bill surprises with Cloudflare Email Workers?

Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most Cloudflare Email Workers options offer a free tier — validate within free quota before scaling.