6 Myths About Sending Email From Cloudflare Workers

Search for "send email from Cloudflare Workers" and you will hit a wall of half-truths: that it is impossible, that you must use one specific vendor, that it is a toy not fit for real traffic. Most of these were never true, and the rest expired in 2024.

Cloudflare Workers grew up. The platform now has the pieces for a real email stack, but the lore around it has not caught up, and stale tutorials keep recycling claims that fall apart on contact. Here are the six myths that come up most, what is actually true, and where to read the full mechanics.

1. Myth: You can't send email from a Worker at all

You can. Workers expose outbound TCP sockets, including TLS/STARTTLS for allowed third-party submission services. The real boundaries are narrower: outbound port 25 is blocked, Workers cannot accept inbound TCP, and Worker TCP cannot connect to Cloudflare-owned IP ranges. That means Cloudflare's own smtp.mx.cloudflare.net:465 endpoint is for external clients; Workers should use the Email Service binding or HTTPS API. For the working patterns end to end, see sending email from a Cloudflare Worker, and for the option-by-option menu, the seven ways to send email from Cloudflare Workers.

2. Myth: You need MailChannels to send from Workers

That advice expired in 2024. For years, MailChannels offered a free send API built specifically for Cloudflare Workers, and so many tutorials leaned on it that "use MailChannels" became received wisdom. The free integration ended: it now requires a paid account and a domain-lockdown DNS record. So if you paste a 2022 snippet hitting the old free endpoint, it will fail with an auth error, and no amount of debugging your code will fix it. MailChannels is still a fine paid provider, just no longer the default or the only door. The full story of what changed is in the MailChannels deprecation.

3. Myth: An HTTP-to-SMTP relay is a hacky workaround

It remains a legitimate bridge when the target is unreachable from Worker TCP or when you need a normal Node SMTP stack. A relay accepts HTTPS from the Worker and holds the SMTP connection on TCP-capable infrastructure. For allowed third-party services, a Worker can also use the runtime's outbound connect() API directly; it simply cannot do direct-to-MX port 25, accept inbound SMTP, or reach Cloudflare's own SMTP endpoint over TCP. The tradeoffs are covered in relaying SMTP from a Worker.

4. Myth: Edge-sent email lands in spam more often

Where your fetch() runs has nothing to do with inbox placement. This myth assumes mailbox providers can tell a Worker apart from a traditional server and penalize it. They cannot, and they do not care. Inbox placement is decided by the sending IP's reputation, your DNS authentication (SPF, DKIM, DMARC), engagement, and list hygiene. A Worker calling a reputable sending path with correct DNS authenticates identically to anything else. If anything is hurting your placement, it is your records or your reputation, not the edge. Get the authentication right and the spam question mostly disappears.

5. Myth: Workers are too niche to run real production email

The platform has every primitive a real stack needs. The "it's a toy" framing imagines Workers as glue for tiny side projects. In practice you have Email Routing for inbound, Queues for reliable high-volume sending, D1 for storage, R2 for attachments and archives, and Durable Objects for stateful coordination. That is a complete email stack, not a demo. The honest caveats are operational (you own warmup, bounce handling, and monitoring instead of renting them), not architectural. We make the production-readiness case in full in whether Cloudflare email is production-ready, and the operational boxes to tick before you ship are gathered in the 12-point Cloudflare Workers email checklist.

6. Myth: You can't hold state, so reliable bulk sending is impossible

Durable Objects and Queues exist precisely for this. A Worker invocation is short-lived and stateless, so the leap to "you can't rate-limit or batch or retry" feels intuitive. It is wrong. A Durable Object gives you a single coordination point that can enforce per-domain rate limits and idempotency keys, and Queues give you batching, retries, and a dead-letter path so a traffic burst never blows your quota or drops a message. Stateless invocations sitting on top of stateful primitives is the normal shape of a Workers app. For the coordination patterns, see using Durable Objects for email.

The pattern under all six myths

Every one of these traces back to the same root: people assume Workers should behave exactly like a Linux host, then turn one runtime difference into “email is impossible.” The real model is more precise. The Worker orchestrates policy and state, then hands mail to the native Email Service binding, an HTTPS API, or an allowed third-party submission service over outbound connect(). Once the boundaries are explicit, the myths become architecture choices.

None of this means edge email is effortless. You do take on the parts a SaaS hides: warming a domain, handling bounces, and watching your complaint rate. But "harder to outsource" is a very different claim from "impossible," and the gap between those two is where most of these myths live.

Want the stack instead of the lore? Deploy your own email infrastructure on your own Cloudflare account in one command: npx tinbox init <domain>. It wires sending, inbound routing, storage, and DKIM together so you skip the myth-debugging entirely. It all runs on your own Cloudflare account, so your data and mail stay yours.