Cloudflare Email Service: private beta

Original Article ↗ Hacker News Discussion ↗

Integrated email on Cloudflare: appeal and use cases

  • Many developers welcome built-in transactional email in Workers to avoid juggling SES/SendGrid/Resend for simple things like signups, password resets, and contact forms.
  • People using Cloudflare’s developer stack (Workers, KV, R2, Queues, Durable Objects) see this as another step toward Cloudflare as a full-stack “AWS-like” cloud with much better DX.
  • Some like that Cloudflare will auto-handle SPF/DKIM/DMARC and hope for features like idempotency keys and simple APIs/SMTP so existing apps can swap providers easily.

Alternatives, pricing, and “root” providers

  • Thread compares this to SES, SendGrid, Mailgun, Postmark, Resend, Mailgun/Mailjet, Zeptomail, smtp2go, etc. Many want SES-level pricing with Resend-level ergonomics.
  • Small projects are very sensitive to fixed monthly plans; pay‑per‑use or very low tiers are strongly requested.
  • Several mention that most “modern” email services are just wrappers around a small number of underlying MTAs; some welcome Cloudflare as another “root” sender.

Self‑hosting vs middlemen

  • Long debate: some say email is now too hostile and reputation‑driven for ordinary people to self‑host, forcing everyone to use intermediaries.
  • Others with long-running personal mailservers insist deliverability is fine if you have clean IPs, correct DNS (SPF/DKIM/DMARC, rDNS), and modest volume; tools like docker-mailserver, mailu, mox are cited.
  • Consensus: bulk or marketing traffic from fresh or cheap VPS IPs is very likely to be treated as spam; low‑volume personal mail is much more feasible.

Centralization, MITM, and governance concerns

  • Strong worries about Cloudflare becoming a single chokepoint: already fronting a huge share of HTTP(S) traffic, now potentially a big email sender too.
  • Critics describe Cloudflare as de facto MITM for web and soon mail, an attractive asset for intelligence services and censorship regimes, and a “protection racket” securing business traffic while reshaping the internet around commercial norms.
  • Some argue such critical infrastructure should be regulated like a utility or even nationalized; others mistrust governments more than corporations and instead advocate decentralization and multiple independent providers.

UX, blocking, and bot defense

  • Many users complain about Cloudflare CAPTCHAs, “infinite challenges,” and opaque blocking, especially from VPNs, CGNAT, Tor, niche browsers, and privacy setups (heavy adblocking/JS blocking).
  • Site operators counter that bot/DDoS traffic is overwhelming and Cloudflare dramatically cuts load and cost; they see CAPTCHAs as an unpleasant but necessary tradeoff.

Deliverability, reputation, and reliability questions

  • Some are skeptical Cloudflare can maintain clean IP/sender reputation at scale, given potential abuse and their “libertarian” compliance stance.
  • Others point out that email deliverability is already dominated by a few big providers (Google, Microsoft); Cloudflare may simply become another large, trusted origin.
  • There’s lingering distrust from the earlier Workers–MailChannels integration that vanished, stranding some users; people want assurances this is a long‑term, first‑party product.

Vendor lock‑in and “eggs in one basket”

  • Some worry that moving DNS, hosting, and email to Cloudflare concentrates too much risk (downtime, policy change, account bans).
  • Others argue Cloudflare’s ubiquity actually makes them a “safe” dependency, and lock‑in for stateless/static use cases is relatively low compared to traditional clouds.