Email at Scale: SendGrid vs Mailgun vs Postmark vs AWS SES

AWS SES sends email at $0.10 per 1,000 emails. SendGrid charges $90-900/month for the same volume. Here's what you trade away and when SES makes sense.

By Andrii Votiakov on 2026-03-17

Transactional email is a solved problem, technically. SMTP, DKIM, SPF, DMARC — the protocols are three decades old. Yet companies routinely pay $500-2,000/month to send emails that cost AWS $2-8 to send. The gap is real, and it's mostly paid for convenience, deliverability reputation, and the fear of building something that bounces.

Quick answer

AWS SES at $0.10/1,000 emails is the cheapest option by far for pure volume. The catch: deliverability on SES requires work — dedicated IPs ($24.95/month each), warm-up periods, and bounce/complaint handling you manage yourself. Postmark is the right choice when deliverability matters more than cost. SendGrid and Mailgun are the middle ground, but they're increasingly expensive relative to what they offer. For most teams above 500k emails/month, SES wins on economics.

The real cost comparison

Current public pricing (March 2026, US region):

SES is 5-10x cheaper than SendGrid at scale. That's the headline. Everything else is context for whether you can actually capture that saving.

Worth noting: SendGrid and Mailgun both have base plan pricing that includes features (templates, analytics, inbound routing). Once you exceed the plan limits, overage rates apply — and overages are where invoices get surprising.

What you actually pay SendGrid for

SendGrid's pricing includes:

• Email Activity API — searchable 30-day email history. Useful for support. SES has CloudWatch + SNS events; less convenient.
• Template engine — Handlebars-based dynamic templates with a visual editor. You can replicate this, but you need to build or adopt something.
• Inbound email parsing — forward incoming mail to a webhook. SES has this too via SES Receipt Rules, but it's not as turn-key.
• Subuser management — send on behalf of multiple domains with separate statistics.
• Dedicated IP reputation management — tools to manage warming and monitor your IP reputation.

If you use all of this, SendGrid's pricing is more defensible. If you're using it as a dumb relay — send email, get delivery events back — you're overpaying.

When AWS SES is the right call

SES makes sense when:

• You're sending transactional email only (receipts, password resets, notifications) — not marketing blasts.
• Your team is comfortable managing DKIM/SPF records and bounce handling.
• You're already in AWS. SES is native — IAM auth, same billing, CloudWatch alerts.
• Volume is high enough that the $24.95/month dedicated IP cost is trivial vs the per-message saving.

SES does not make sense when:

• You need email warming from zero — SES shared IPs can have variable deliverability, and your first 10-30k emails need care.
• You're sending marketing campaigns — use SES + something like Mautic or Listmonk as the campaign layer on top.
• Your team has no one who wants to own deliverability — SES is not a "set it and forget it" service at scale.

The deliverability question

This is the honest part. Deliverability on SES requires active management:

IP warm-up — Start with 50-200 emails/day on a new dedicated IP, double every 2-3 days. Takes 4-6 weeks to warm a new IP to full volume. Skipping this tanks your reputation.

Bounce and complaint handling — SES publishes bounce and complaint notifications via SNS. You must consume these and suppress suppressed addresses. Letting your bounce rate exceed 5% or complaint rate exceed 0.1% gets your sending suspended.

DMARC alignment — Set up SPF, DKIM (SES does this automatically per-domain), and a DMARC policy. Gmail and Yahoo now reject email without DMARC.

If you're already doing this on SendGrid, the operational burden isn't higher on SES — it's just more visible.

Postmark: when deliverability beats cost

Postmark is the outlier. Their entire product is built around transactional email with industry-leading inbox placement. Separate streams for transactional and broadcast (marketing) email, so a spam complaint on a marketing blast doesn't hurt your password reset deliverability.

At $1.25-1.50/1,000 emails, Postmark isn't cheap. But for password resets, billing receipts, and security alerts where delivery failure has a real user impact — it's a reasonable spend. I've seen companies run Postmark for critical transactional flows and SES for notification volume. That split makes sense above certain volumes.

Mailgun: the reliable middle ground

Mailgun is cheaper than SendGrid and has better developer ergonomics for simple sending. Their inbound routing is solid. The EU data residency option (send + store in EU) is useful for GDPR-sensitive workloads.

Where Mailgun's pricing model can bite you: the Flex plan (pay-as-you-go) has no monthly commitment and is expensive per-message. The Foundation, Scale, and Custom plans have email limits with overages. Make sure you're on the right plan for your volume.

Self-hosting: Postal

If you want to run your own mail transfer agent, Postal is the open-source option worth looking at. It handles sending, bounce handling, click tracking, and basic analytics. Runs on a single VM. Honest compute cost: $50-150/month for most volumes.

The main concerns with self-hosted email:

1. IP reputation — Your sending IPs start cold and unknown. Getting delivered to Gmail requires careful warm-up and a clean list. If you're migrating from a provider with a good sending reputation, expect a temporary deliverability dip.
2. ISP postmaster relationships — At very high volume (50M+/month), ISPs expect you to have direct relationships and feedback loops. This is manageable but it's work.
3. Operational ownership — SMTP queue management, bounced message handling, retry logic — these are your problem now.

Self-hosting email at scale is a more serious undertaking than self-hosting most other SaaS categories. I generally recommend it only for companies above 50M+ emails/month or with specific data residency requirements that no SaaS provider can meet.

What you give up (moving from SendGrid to SES)

• Visual email template editor — Use MJML + your own CI pipeline, or Stripo as a cheaper standalone editor.
• 30-day searchable email history — SES logs events to CloudWatch; build a simple event store if you need searchable history.
• Suppression list sync — SES has its own suppression list; you manage it.
• One-click unsubscribe headers — SES supports List-Unsubscribe; you wire it up manually.
• Support — SES support is AWS support. Fine if you have a Support plan; frustrating if you don't.

What you gain

• 80-90% cost reduction on pure email sending.
• No vendor lock-in — SMTP is SMTP; migration to or from SES is a config change.
• AWS-native integration — IAM auth, same invoice, no separate vendor relationship.
• SES Suppression List — Global suppression list across all your sending; prevents repeat hard bounces.

Realistic numbers

Client — SaaS product, 8M transactional emails/month (receipts, notifications, password resets, weekly digests):

• SendGrid Scale plan: $1,850/month
• Replaced with: SES (2 dedicated IPs) + custom bounce handler + Postmark for critical auth flows (50k emails/month)
• SES cost: ~$830/month (including dedicated IPs)
• Postmark for auth emails: ~$75/month
• Engineering to build the suppression + event handler: 1 week one-time
• Total new cost: $905/month
• Saving: $945/month, $11,340/year

Not the biggest saving in dollar terms, but straightforward — the migration took less than 2 weeks and the result is a cleaner architecture with better visibility into email events.

See the build-vs-buy framework for how to score this kind of decision systematically. Email is one of the few categories where even partial self-hosting (SES) makes clear economic sense above modest volumes.

If your email bill feels high relative to what you're actually sending, book a call.