What SendGrid still does well
SendGrid's v3 API is well-trodden, the SDKs cover every mainstream language, and the operational maturity shows up in places like dedicated IP warm-up programs, sub-user permissions, and team workflows that large marketing ops departments actually need. For high-volume senders that have outgrown the free tier and are happy with Twilio's pricing curve, the platform is the path of least resistance.
What changes in 2026 is that "Twilio SendGrid" is no longer the only safe default. The pricing has climbed (the Essentials plan starts around $19.95/month for 50,000 emails and climbs sharply above that), the contract is annual in most tiers, and the message data lives on Twilio's multi-tenant Postgres.
The Cloudflare-native equivalent
Flowmails provisions a Worker in your Cloudflare account that exposes the same send / receive / webhooks API surface SendGrid does, but writes every message to your D1 database and every attachment to your R2 bucket. Email Services handles outbound signing and delivery; Email Routing handles inbound. There is no SendGrid-style shared relay — outbound ships from Cloudflare's own infrastructure, which means your reputation lives on your zone, not on a Twilio IP pool.
If you are already on Cloudflare for DNS, Workers, or R2, the operational footprint of adding email is roughly zero: one more Worker, one more D1 database, one R2 bucket. The Cloudflare Workers integration page has the install shape; the runtime tour explains what happens to a single inbound message.
API surface, mapped endpoint by endpoint
SendGrid's POST /v3/mail/send becomes POST /api/v1/messages (or the Worker endpoint in a self-hosted deploy) with the same JSON shape minus the marketing-template fields. Webhooks are signed with the same HMAC-SHA256 pattern SendGrid uses, but the delivery ID and the dead-letter log live in D1 so you can replay them with a SQL query instead of opening a support ticket.
Inbound uses SendGrid's Inbound Parse model: the Worker receives the parsed MIME, writes a row to D1, drops the body into R2 if it is over the size threshold, and exposes the row through the same /api/v1/messages list endpoint that send uses. The dashboard equivalent is the route tables page, which is the receive-side analog of SendGrid's Inbound Parse webhook URL config.
Quotas and limits, with numbers
SendGrid's free tier stopped accepting new signups in 2023. The paid plans start at ~50,000 emails / month on Essentials ($19.95) and climb in tiers. Dedicated IP is a paid add-on above 100k messages / month. Suppression management is available, but bounce / spam-list cleanup is operationally yours to monitor.
On the Cloudflare side, the receive Worker runs inside the Workers free tier (100k requests / day) or the paid plan (10M requests / day before Unbundled billing). D1 gives 5M reads and 100k writes / day on the free plan, with 50B reads / month on paid. R2 has 10GB of free storage and 10M Class A ops / month. Email Services itself has per-zone throughput limits, but they are sized for the same outbound volumes a SendGrid Essentials customer would send.
The migration story
Moving off SendGrid is a four-step affair: provision the Flowmails Worker in your Cloudflare account, point a subdomain at it for parallel send, flip your DNS records when you are confident, and retire the SendGrid account after the cool-down period for in-flight messages. The detailed diff between the two platforms — feature by feature, row by row — is on the Flowmails vs SendGrid matrix page; the short version is on the SendGrid alternative page.
When SendGrid is still the answer
If you send more than a million transactional emails a month, if you have a marketing-ops team that needs sub-user permissions and template approvals, or if you are on a Twilio master contract that already includes SendGrid credits, the case for switching is thin. For everyone else — especially teams whose Cloudflare bill already covers DNS, Workers, and R2 — the self-hosted alternative is meaningfully cheaper and meaningfully closer to your data.
