AWS SES vs SendGrid vs Mailgun — Which Email Service Should You Use?

Picking an email service has gotten complicated with all the competing claims, pricing tiers, and “best for developers” badges flying around. As someone who’s run all three of these in production — got paged at 2am because of all three, too — I learned everything there is to know about this particular corner of infrastructure the hard way. Once as a junior dev who picked wrong. Once as a tech lead trying to slash costs. Once for a client whose deliverability had cratered so badly their support replies were landing in spam folders.

Quick Verdict — SES for Cost, SendGrid for Features

Stop here if you want the short version. AWS SES if you’re cost-sensitive and already living in the AWS ecosystem. SendGrid if you need marketing and transactional email under one roof — or just want something that works without a week of configuration. Mailgun if you’re building microservices and inbound email parsing is a real requirement.

That’s the actual answer. Everything below is the math and context behind it.

SES charges $0.10 per 1,000 emails. That price is genuinely hard to argue with. When I moved a client off SendGrid’s Essentials plan onto SES, the monthly bill dropped from $89.95 to under $12. Same volume. Same results. Dramatically different invoice.

SendGrid wins on features and ease of use. The dashboard is polished. The API is clean. The documentation doesn’t make you want to change careers. If cost isn’t your obsession, it’s the more comfortable choice — especially when your team includes non-developers who need to manage templates or pull engagement metrics without filing a Jira ticket.

Mailgun sits in a specific niche. It’s excellent in that niche. But recommending it as the default answer for most teams would be dishonest.

Pricing at Scale — The Math That Matters

Probably should have opened with this section, honestly. Pricing is usually the first thing teams argue about and the last thing anyone actually calculates properly before signing up.

10,000 Emails Per Month

At 10K/month, here’s the rough breakdown:

• AWS SES — $1.00/month sending from outside EC2. Free if you’re sending from an EC2 instance or Lambda. Yes, actually free.
• SendGrid — Free tier covers 100 emails/day, roughly 3,000/month. For 10K you’re on Essentials at $19.95/month for up to 50,000 emails.
• Mailgun — Flex trial gives you 1,000 emails free, then pay-as-you-go at $0.80 per 1,000. So around $7.20 for those 9K paid emails. The Foundation plan at $35/month includes 50,000 — overkill at this volume.

Winner at this scale — SES if you’re on AWS. Mailgun pay-as-you-go if you’re not.

100,000 Emails Per Month

• AWS SES — $10.00/month. That’s it. No plan tiers. No gotchas buried in the fine print.
• SendGrid — Essentials caps at 100K emails for $29.95/month. But Essentials doesn’t include dedicated IPs or email validation. For those you’re on Pro, starting at $89.95/month for 100K.
• Mailgun — Scale plan at $90/month covers up to 100,000 emails, includes dedicated IPs and more advanced analytics.

The SendGrid Pro vs Mailgun Scale comparison is basically a wash on price. SES wins by a factor of 3x to 9x depending on which SendGrid tier you actually need.

1,000,000 Emails Per Month

• AWS SES — $100/month. Flat. Predictable. The kind of number that looks like a typo when you first see it.
• SendGrid — At 1M emails you’re into custom enterprise pricing territory. Their published Pro tier tops out around 1.5M for roughly $749/month.
• Mailgun — Custom pricing at this volume. Expect a sales call.

At high volume, the SES cost advantage becomes extreme. A company sending 1M emails/month could save $7,800 per year just by switching — I’ve watched that argument win budget conversations in under ten minutes.

One thing worth factoring in — SES doesn’t bundle dedicated IPs the way SendGrid Pro does. Adding a dedicated IP to SES runs $24.95/month per IP. Still usually cheaper overall, but include it in your math before presenting numbers to anyone.

Deliverability — Which Actually Reaches the Inbox?

Don’t make my mistake. In 2021 I launched a new SES sending domain without properly warming it up — skipped a step I thought was optional — and watched open rates fall off a cliff within a week. Learned to take deliverability setup seriously after that, regardless of which provider you’re using.

All three services can hit excellent deliverability numbers. The difference is how much work it takes to get there.

AWS SES

SES deliverability requires more manual configuration. DKIM, SPF, DMARC — you’re setting those up yourself. New IP addresses need warming up gradually, though SES now offers a managed IP warm-up option that helps. You also start in a sandbox environment where you can only send to verified addresses until you request production access — a step that genuinely confuses a lot of developers the first time they hit it.

The Reputation Dashboard shows complaint and bounce rates. The feedback loop system works well. But the responsibility for your sending reputation sits heavily on you, which is either reassuring or terrifying depending on your team.

SendGrid

SendGrid is easier out of the box. Onboarding walks you through domain authentication. Dedicated IPs come with guided warm-up schedules on Pro. Their deliverability insights dashboard is genuinely useful — ISP-level delivery data without digging through raw logs.

SendGrid also has deliverability experts you can actually talk to on higher-tier plans. That’s not nothing. When you have a serious deliverability problem at 11pm before a product launch, a human being on the other end of a support chat is worth real money.

Mailgun

Mailgun’s deliverability is solid. Infrastructure is well-maintained. Their Email Validation product — $1.20 per 1,000 validations, billed separately — lets you clean lists before sending and knock down bounce rates proactively rather than reactively.

The Mailgun Inbox Placement testing tool, available on Scale plans, is genuinely useful for checking deliverability across major email clients before a campaign goes out. SendGrid has something comparable. SES does not.

Honest take — configure any of these three properly and you’ll get good deliverability. SES just demands more upfront work to reach that point. If your team doesn’t have someone comfortable with DNS records and bounce handling, start with SendGrid.

Developer Experience

Bad developer experience creates bugs. It slows down integrations. It causes the kind of subtle mistakes that result in emails silently failing in production for three days before anyone notices a support ticket drop-off.

AWS SES

SES is deeply integrated into the AWS ecosystem — if your application runs on EC2, ECS, Lambda, or anything else in AWS, IAM-based authentication is seamless. You’re already managing IAM roles. Adding SES permissions is maybe two minutes of work. The AWS SDK v3 for JavaScript has solid SES support. Python’s boto3 is reliable. Go, Java, Ruby — the official SDKs cover you.

The SES API itself isn’t the most elegant thing ever designed. It’s functional, it’s well-documented in the AWS docs, but those docs have a certain density to them that takes getting used to. SES v2 is cleaner than the original, though you’ll occasionally hit Stack Overflow answers referencing the old v1 API that don’t directly translate. Configuration Set management and event destinations work well once you understand the mental model. That “once you understand” phrase is doing a lot of heavy lifting.

SendGrid

The SendGrid Web API v3 is one of the better-designed email APIs out there. Clear endpoints, predictable response formats, error messages that tell you what actually went wrong. The official Node.js library (@sendgrid/mail) is widely used and well-maintained. The Python library is solid. Documentation includes working copy-paste code examples in seven languages.

Dynamic templates using Handlebars syntax are easy to work with. The template editor in the dashboard means your marketing team can update copy without touching code — that separation of concerns is genuinely underrated when you’re tired of being pinged about a typo in a confirmation email.

SendGrid’s event webhook system is robust too. Bounce, click, open, unsubscribe events all POST to an endpoint you define. Easy to implement, well-documented, reliable in my experience across multiple production integrations.

Mailgun

Mailgun’s API is clean and REST-based. Documentation is good. But what Mailgun does that neither SES nor SendGrid handles as well is inbound email parsing — you configure a route that parses incoming emails and POSTs the structured data (headers, body, attachments, the whole thing) to your application endpoint. For building email-based workflows, support ticket ingestion, or any feature where users send email to trigger application logic, Mailgun’s inbound routing is meaningfully better than the alternatives.

The mailgun.js SDK is maintained and functional. The Python SDK less so — I’ve personally fallen back to raw HTTP requests for Mailgun integrations because the Python library was lagging behind actual API capabilities. Not a dealbreaker. Just a real thing that happened on a real project.

When to Use Each

Use AWS SES When

• Your application already runs in AWS and you want unified IAM permissions, billing, and ecosystem consistency
• You’re sending high volumes of transactional email and cost is a primary concern — $0.10/1,000 doesn’t budge at scale
• You have engineering resources to handle DKIM setup, bounce handling, and suppression list management properly
• You don’t need a polished marketing email interface — pure transactional, developer-managed, no frills

Use SendGrid When

• You need marketing and transactional email from a single platform with shared or separated sending infrastructure
• Your team includes non-developers who manage templates, view analytics, or run campaigns without writing code
• You’re not in the AWS ecosystem and want a standalone service with an API that just works
• Deliverability out of the box matters more than saving $50/month — the easier warm-up process and better default tooling are real advantages
• You want access to dedicated deliverability support when things go sideways at volume

Use Mailgun When

• You’re building microservices or serverless functions that need lightweight, pay-as-you-go email without committing to a monthly plan
• Inbound email parsing is a core feature requirement — Mailgun’s routes system is meaningfully better than the alternatives for this use case
• You want email validation built into your sending workflow without managing a separate service
• Your sending volume is irregular — heavy some months, light others — and you want pricing that actually reflects that

That’s what makes this comparison endearing to us developers — there’s no universally wrong answer, just wrong answers for your specific situation. Most teams default to SendGrid and do fine. Teams that do the math switch to SES. Teams building email-native features discover Mailgun. None of them are bad choices. But now you have the information to pick based on your actual constraints, rather than whatever came up first in a Google search at 10pm when you needed to just ship something.