← Articles

Email Forwarding with Cloudflare Workers: A Technical Deep Dive

How Cloudflare Email Workers handle inbound mail at the edge — parsing, forwarding, storage and filtering — with the classic pitfalls to avoid.

Email Workers are Cloudflare’s answer to handling inbound mail at the edge. Instead of an SMTP server, you write a handler that receives the raw message, decides what to do, and calls message.forward() or message.setReject(). Here is how the pieces fit together.

The event model

Pipeline order matters

  1. Parse — use a MIME parser like postal-mime; attachments stream out to R2 so large messages don’t sit in memory.
  2. Match rules — exact addresses first, then catch-all; first match wins.
  3. Apply filters — sender blacklist, subject regex, size cap, attachment condition.
  4. Forward — await message.forward(dest) per destination, each in its own try/catch.
  5. Store — R2 copy + D1 metadata, independent of the forward result.

Pitfalls to avoid

Beyond the raw Worker

Raw Workers are a good foundation, but management needs a panel: editable rules, searchable archives, per-rule stats. InboxFly wraps this exact pipeline (parse → match → filter → forward → store) in a self-hosted panel you deploy to your own account.

FAQ

What is the message size limit? 25MiB per message, enforced by the platform.

Can I reject mail at SMTP level? Yes — setReject bounces with a custom reason, which Cloudflare’s dashboard rules cannot do.

Open panel About InboxFly
© 2026 InboxFly — open source under MIT