Cloudflare Email Service vs Twilio SendGrid

Cloudflare Email Service

Cloudflare API tokens can be limited to sending, given an expiry and restricted by IP address, and a public OpenAPI file covers 29 Email Sending operations. Sending is still in beta, with no SLA, no idempotency key and no published daily quota, and it needs a domain on Cloudflare DNS and the Workers Paid plan.

Twilio SendGrid

Restricted API keys with per-endpoint scopes, subuser keys and IP access management. No official MCP server that can send, only Twilio's docs search.

Cloudflare Email Service

1. POST to https://api.cloudflare.com/client/v4/accounts/{account_id}/email/sending/send with Authorization: Bearer <token>. The body needs to, from, subject and one of html or text
2. Don't retry a timed-out send blindly. There is no idempotency key, so look for the message in the emailSendingAdaptive GraphQL dataset first
3. On 429 (code 10004) wait for the retry-after header. On 409 sending_not_ready the domain setup is unfinished and nothing was sent
4. Read result.delivered, result.queued and result.permanent_bounces in the response. A 200 does not mean every recipient was accepted
5. Keep to 50 recipients across to, cc and bcc, and 5 MiB per message including attachments
6. For SMTP use smtp.mx.cloudflare.net on port 465 with implicit TLS, username api_token and the API token as password. Port 587 is not supported
7. By default one suppressed recipient fails the whole send. Turn on Drop suppressed recipients for the domain to send to the rest

Twilio SendGrid

1. Give an agent that only sends a restricted key with just mail.send
2. Set mail_settings.sandbox_mode to validate payloads without delivery
3. Authenticate a domain or verify a single sender before the first send
4. Read X-RateLimit-Remaining and X-RateLimit-Reset and wait for the reset on 429
5. Don't blindly retry a timed-out mail/send. There's no idempotency key, so the message can go out twice