What actually decides whether your transactional email setup survives its first bad week? It is rarely the price per thousand messages. It is the workflow: how a template gets edited, how a bounce gets noticed, how a new domain gets authenticated, and who has to be awake when something breaks at 2 a.m. (Obsidian vs logseq local first notes compared by workflow)
Three tools dominate the conversation for teams shipping application email: Resend, SendGrid, and Amazon SES. They look interchangeable on a pricing page and behave nothing alike in daily use. This comparison focuses on the parts you will feel every week, and on the trends likely to shape how teams pick between them as tooling converges.
Why the sending API is the easy part
All three services accept a message and hand it to the internet. The differences start immediately after that.
Amazon SES is a raw sending API with account-level features layered on top: SMTP and API endpoints, sending limits, sandbox mode, configuration sets, and event destinations. It has no built-in visual template editor or campaign interface. Templates live behind the API. If you want a marketing dashboard, AWS expects you to bring one or assemble other services around it.
SendGrid splits its world in two. Marketing Campaigns (contacts, lists, single sends, automations) and transactional Mail Send are distinct product surfaces with separate APIs and separate pricing. That split is a feature for teams with a marketing department and a liability for teams that just want one place to look.
Resend is API-first with React-based templates. It leans hard into developer workflow: send through an SDK, write templates as components, receive events through webhooks. It is a newer entrant with a smaller feature surface than SendGrid’s marketing suite, and its scope is evolving quickly, so anything specific about its 2027 feature set should be treated as a trend, not a promise.
The onboarding gate: sandbox versus dashboard
The first real workflow difference shows up before you send a single production message.
New Amazon SES accounts start in a sandbox with restricted sending, historically limited to verified recipients and a low daily cap, until production access is requested and approved. That approval step is a workflow gate the other two do not impose in the same way. It is not a dealbreaker, but it means SES has a lead time. Teams that spin up SES the afternoon before a launch often discover this the hard way.
Practical tip: request production access the day you decide to use SES, not the day you deploy. Write the use-case description carefully. Vague answers get follow-up questions, and follow-up questions cost days.
SendGrid and Resend both let you verify a domain and start sending far sooner. Resend offers guided domain verification that walks through DNS records. SendGrid provides in-dashboard sender authentication setup, including domain authentication and link branding. SES expects you to configure DKIM, SPF, and DMARC yourself through Route 53 or your own DNS provider.
That last point deserves emphasis because it is the most common self-inflicted wound. Email authentication is a standards problem before it is a vendor problem. If you want the underlying rules rather than a vendor summary, the SPF specification in RFC 7208 explains how sending domains are authorized, and DKIM is defined separately in RFC 6376. Understanding both makes any provider’s setup screen less mysterious. (RFC 5321: Simple Mail Transfer Protocol)
| Workflow step | Resend | SendGrid | Amazon SES |
|---|---|---|---|
| Domain verification | Guided in-product | In-dashboard authentication | Manual DNS (Route 53 or external) |
| Time to first send | Minutes | Minutes | Hours to days (sandbox review) |
| Template editing | React components | Visual editor plus API | API only |
| Event model | Webhooks | Event Webhook (push) | Configuration sets plus destinations |
Templates: code, canvas, or nothing
How your team edits an email template tells you a lot about who owns email in your company. (Email deliverability)
With Resend, templates are code. React Email components live in your repository, get reviewed in pull requests, and deploy with your application. For engineering-led teams this is a genuine relief: no one logs into a dashboard at midnight to fix a typo in a receipt. For a marketing team that wants to change a hero image on a Tuesday, it is a bottleneck.
SendGrid offers a visual editor alongside its API. Non-technical teammates can build and edit campaigns without touching a repository. The tradeoff is drift: the template in the dashboard and the template in your codebase can quietly diverge, and nobody notices until a customer receives the wrong version.
SES offers no editor at all. Templates are stored and rendered through the API. That is either perfect discipline or pure friction, depending on your team.
The honest guidance here: pick the template model that matches who actually changes email content. If marketing owns it, a visual editor wins. If engineering owns it, code wins. Mixing ownership without agreeing on a source of truth is how teams end up with three versions of the same password reset email.
Event handling: push versus pull
This is the deepest workflow difference, and the one most teams underestimate.
SendGrid uses a push-based model through its Event Webhook, which delivers delivery, open, click, and bounce events to an endpoint you control. Your server receives a stream of JSON and decides what to do with it. Simple to reason about, but your endpoint becomes part of your email reliability story. If it goes down, events queue or drop depending on your setup.
SES uses configuration sets plus event destinations that route events to CloudWatch, SNS, Kinesis Firehose, or EventBridge. This is a pull and queue-based model. Nothing arrives at your server unless you build the consumer. In exchange, you get the durability and replay behavior of the surrounding AWS services, which matters enormously at volume.
Resend uses webhooks for events, closer to SendGrid’s model in spirit, with the same operational caveat: someone has to keep that endpoint healthy.
A practical mistake worth naming: teams wire up bounce and complaint events last, after everything else works. Then a hard bounce silently repeats for weeks, and the sending reputation that took months to build starts eroding. Set up event handling before your first production send, not after. If you are running SES alongside other AWS infrastructure, the same discipline that keeps storage and compute healthy applies here, and the operational lessons in this breakdown of Amazon S3 production mistakes that quietly break your stack transfer directly to event pipelines. (Use claude writing practical workflow that actually works)
Inbound email and the features nobody checks
SES supports receiving email through receipt rules. SendGrid and Resend have historically not offered inbound handling as a core feature. If your product needs to parse replies, route support mail, or accept email-to-ticket submissions, that capability can decide the choice on its own.
It is worth listing the less glamorous capabilities before you commit:
- Inbound email handling and reply parsing.
- Dedicated IP options and warm-up support.
- Subuser or team-level access separation.
- Suppression list management and its API.
- Sandbox or test mode for staging environments.
Write that list down, rank it honestly, and score each provider. Most teams discover their real requirement is number five, not the feature they were comparing on Twitter.
Cost, limits, and the 2027 trend line
Specific rate limits, free-tier quotas, and feature parity for 2027 cannot be known now. Any article claiming otherwise is guessing. What can be said is directional: API-first tools are converging on webhooks plus component-based templates, and the gap between “developer tool” and “marketing platform” is narrowing from both sides.
Cost comparisons also mislead when they ignore architecture. SES is cheap per message but assumes you already run AWS services; the surrounding infrastructure is part of the bill. That reality is familiar to anyone who has budgeted cloud spend, and the same accounting logic in this realistic look at Amazon EC2 costs for small projects applies to email infrastructure: the headline price is never the whole number. If your team is weighing storage and sync tools in the same planning cycle, this comparison of Dropbox alternatives by use case and this breakdown of Google Drive alternatives by use case show the same pattern of hidden workflow costs.
The broader lesson: pick the workflow that matches your team’s operating style, then optimize price. Reversing that order is how teams end up migrating twice.
Common mistakes that show up in every migration
A few failure patterns repeat across all three providers.
Skipping authentication before sending volume. DKIM and SPF records are not optional paperwork. Set them up, verify them, and check the results.
Treating staging and production as the same environment. Use sandbox or test modes so a staging run never touches real recipients or your sending reputation.
Ignoring suppression lists during migration. Bounced addresses and unsubscribes must carry over. Starting fresh means re-bouncing addresses that already told you no.
Letting one person own email. When that person leaves, nobody knows which dashboard holds the real template.
Conclusion
Resend, SendGrid, and Amazon SES all deliver email. They differ in who they assume is doing the work. Resend assumes a developer writing React components and wiring webhooks. SendGrid assumes a team with both marketers and engineers who need separate surfaces. SES assumes an engineer comfortable with DNS, IAM, and event pipelines, who values control over convenience.
For 2027, the safest prediction is convergence on the developer experience and continued divergence on the operational model. Choose based on the workflow you can actually staff, set up event handling and authentication before your first production send, and verify current limits against official documentation rather than any comparison article, including this one.
FAQ
Is Resend cheaper than SendGrid for transactional email?
Pricing changes often, so check current rates directly. Structurally, Resend’s API-first model tends to appeal to low-volume transactional senders, while SendGrid bundles marketing features that some teams pay for without using. Compare the plan that includes the features you actually need, not the entry tier.
Does Amazon SES require approval before sending?
Yes. New accounts start in a sandbox with restricted sending, historically limited to verified recipients and a low daily cap, until production access is requested and approved. Request it early, because approval can take days and is a common launch blocker.
Can SendGrid and Resend receive inbound email?
Historically, inbound handling has been a core SES capability through receipt rules, while SendGrid and Resend have not offered it as a primary feature. If parsing replies or routing inbound mail matters to your product, verify current support in each provider’s official documentation before deciding.
What is the main workflow difference between SendGrid and SES events?
SendGrid pushes events to your endpoint through its Event Webhook, so your server receives them directly. SES routes events to AWS services like CloudWatch, SNS, Kinesis Firehose, or EventBridge through configuration sets, and you build the consumer. Push is simpler to start; pull is more durable at scale.
Do I need DKIM and SPF with all three providers?
Yes. All three require proper email authentication, but the setup differs. SendGrid and Resend guide you through it in their dashboards, while SES expects manual DNS configuration. Skipping authentication is the fastest way to land in spam folders regardless of provider.
Which provider is best for a small engineering team?
A small engineering team that already runs on AWS often finds SES cost-effective, provided someone owns DNS and event pipelines. Teams that want templates in code and guided setup tend to prefer Resend. Teams with a marketing function alongside engineering usually get more value from SendGrid’s split surfaces.
