First separate receiving from sending
If you want hello@yourdomain.com forwarded to an existing inbox, Cloudflare Email Routing is the direct fit. SES can receive and process mail too, but that involves AWS configuration rather than a simple forwarding rule. Neither service is automatically a complete Gmail-style mailbox for your team.
For receipts, login links or alerts, compare Cloudflare Email Sending with SES outbound delivery. Cloudflare's current documentation labels sending beta and provides a Workers binding, REST API and SMTP. Arbitrary recipients require Workers Paid. The older ability to send only to verified destination addresses is a separate case.
A useful bill comparison
| Outbound emails/month | Cloudflare email usage | SES basic outbound usage |
|---|---|---|
| 1,000 | Included with Workers Paid | $0.10 |
| 10,000 | $2.45 plus Workers Paid | $1.00 |
| 100,000 | $33.95 plus Workers Paid | $10.00 |
Cloudflare includes 3,000 outbound emails and charges $0.35 per additional 1,000. SES base outbound sending is $0.10 per 1,000. These calculations exclude promotions, attachment data, paid IPs and surrounding infrastructure. Cloudflare's required Workers subscription is additional if you do not already have it; SES receiving, storage and processing are separate charges. This table compares transport, not a finished newsletter application.
Ten thousand subscribers receiving four newsletters generate 40,000 deliveries: $12.95 in Cloudflare email usage or $4 in SES base outbound usage under those assumptions. You still need consent records, unsubscribe handling, campaign scheduling and reporting.
Stack fit matters more than a few dollars
A Workers app can keep email configuration near the rest of its Cloudflare deployment. An AWS application can use SES with IAM permissions, regional identities and its existing event-processing services. The cheaper API becomes expensive if the team has to operate an unfamiliar cloud solely for email.
For SES, confirm production access and sending quotas in the intended region before cutting over. A sandbox account is not ready for arbitrary customers. For Cloudflare, validate beta availability, sending limits and the current support terms against your production requirements.
Receiving without breaking your existing inbox
Do not replace a domain's MX records just to test an API. Those records control incoming mail and can displace an existing mailbox provider. Use a dedicated receiving subdomain if you need a separate processing path. Outbound authentication and inbound routing are related DNS work, but changing one does not require moving all company mail.
For a support-ingestion app, test attachments, forwarded messages, duplicate deliveries and malformed mail. Save a stable inbound event identity before creating tickets. If an HTTP callback is retried, it should find the existing ticket rather than create another.
Map the architecture before comparing unit prices
Start with where the business event occurs. If a Worker already handles the event, Cloudflare sending can keep the integration close to that code. If an AWS service produces the notification and your team already operates AWS permissions, monitoring and queues, SES can fit the existing operational model. Moving the event across clouds solely to save a small amount on transport can introduce more failure handling than it removes.
Draw the route from the business event to the final delivery event. Include the queue, renderer, provider request and status storage. Assign an owner to each step. Neither a Worker binding nor an SES send call eliminates the need to decide what happens when a receipt is accepted just before your application loses its connection. Your notification ID and retry policy should exist before the provider-specific implementation.
Understand what the Cloudflare beta means for your rollout
Cloudflare's documented sending service and Email Routing are distinct capabilities. A domain that successfully forwards incoming messages is not thereby ready to send application messages to arbitrary recipients. Confirm the account eligibility, paid Workers requirement, authentication and limits for the sending path you intend to use. Do not use an old routing tutorial as the setup guide for outbound delivery.
Because outbound sending is documented as beta, make product maturity an explicit evaluation criterion. Verify the current availability, support arrangements and any constraints your business needs before moving critical notifications. Beta status alone does not tell you whether the service fits your application, but a production decision should be based on today's published behavior and a tested fallback plan. Keep template and business logic sufficiently separate that a transport limitation does not require rewriting the whole workflow.
Treat SES production access as a project task
An AWS account and a verified domain do not remove the need to check the account's current SES sending status, regional setup and quotas. Confirm that the intended region can send to your real recipients at the required rate. Include this in the project checklist before scheduling a customer cutover; a successful test to a verified address is not a capacity test for the production audience.
For the pilot, use the same region and configuration you intend to operate. Document who can inspect failures and where the team will see bounce and complaint information. When a quota or rate limit is reached, the application should queue or reject work predictably rather than lose notifications. Preserve a record of messages not yet attempted so an operator can distinguish a backlog from a completed send.
Add application costs to the sending calculation
At a 10,000-subscriber baseline, four newsletters generate 40,000 recipient deliveries. Add password resets, receipts and any onboarding sequence separately. A single API call with several recipients still represents several deliveries for budgeting purposes. If attachments are common, include relevant data charges and provider restrictions in the full model. Use the same message and recipient assumptions for both vendors.
Then list costs outside transport: the required Workers plan, AWS services around SES, queues, storage, monitoring and operator time. Existing infrastructure may make some of these marginal costs small, but a new team still has to build and maintain the missing pieces. If a teammate spends hours each month reconciling failed campaigns, that work matters more to the business than a few dollars of base email usage.
Keep inbound DNS changes independent
Sending and receiving share a domain but do not require moving together. A company can keep its existing mailbox provider while adding an authenticated sending subdomain for application mail. Before changing DNS, inventory the records used for ordinary employee inboxes, forwarding, DKIM and return paths. Do not overwrite MX records simply because an outbound setup guide mentions email DNS.
If incoming messages are part of the application, test that workflow separately. Use a real reply with an attachment, a forwarded message and an unexpected sender. Decide whether the application stores the original message or just parsed fields, and what happens if processing is temporarily unavailable. A working outbound pilot says nothing about whether your inbound support or reply-handling path survived the configuration changes.
Evaluate reliability at your application boundary
Use explicit test cases: a temporary provider error, an invalid recipient, a delayed delivery event and duplicate notification work. The application should record useful status without assuming a successful send request means a customer received the email. For time-sensitive messages, measure the interval from business event to provider acceptance and inspect the queue separately from the provider's downstream delivery behavior.
Maintain a bounded retry policy and an operator-visible failure state. If the provider accepts a message but the client times out, do not automatically issue the same customer message elsewhere. Resolve acceptance where possible and use the provider's documented duplicate-prevention features only within their actual guarantees. Your own application still needs a durable decision about whether the business notification has already been processed.
Which team should choose which service?
Cloudflare is worth piloting when Workers is already your application boundary, the current sending beta covers your requirements and the team values that integration. SES is worth choosing when AWS is already the operational home, its current regional limits fit and the team can run the surrounding messaging application. Both decisions should include who will support the system after the developer finishes the initial integration.
If neither team wants to build audience management, templates and investigations, compare a managed email application before choosing the cheapest transport. Infrastructure is a good purchase when you already have the surrounding system or deliberately want to own it. It is a poor substitute for that system when the immediate business need is simply for a marketer to send a reliable campaign next week.
A pre-launch infrastructure checklist
Make the launch decision from a short operating document: the sending account is eligible, the domain is authenticated, the chosen region or service supports the workload, the queue has a bounded retry policy and an operator can identify unsent notifications. Include the date on which you checked the current service limits. This is especially useful when the Cloudflare sending beta or an SES account quota can change between the prototype and production rollout.
For an existing AWS application, list what would actually move if Cloudflare became the sender. For a Worker-centered application, list the additional AWS resources and operational permissions required for SES. Count those changes alongside the price calculation. If both paths fit, choose the one that leaves fewer unowned components. The team needs a clear answer to who investigates a missing receipt at the end of the month, not merely which request was shorter in a sample script.
Which should you pick?
Choose Cloudflare when Workers integration and simple routing are the main advantages. Choose SES when AWS integration and low base delivery cost justify owning the extra application layer. Choose a managed campaign platform such as Sequenzy when you want that application layer provided. A low transport bill alone does not give a marketer an editor, segments or safe unsubscribe behavior.
Sources and scope
Updated November 3, 2026. We publish Sequenzy and have a commercial interest in this comparison. This is a documentation-based evaluation, not a hands-on benchmark or independent ranking. Prices are USD list prices or explicitly labeled calculations; taxes, promotions and optional services can change the total. Confirm the selected plan before purchase.
