AWS SES: When NOT to Use It (and What to Pick Instead)

AWS SES has a deserved reputation: cheap (10 cents per 1,000 emails), reliable infrastructure, integrated with the rest of AWS. For high-volume teams with deliverability engineering capacity, SES is the obvious choice. For everyone else it is a sneaky trap — the cheap price hides multiple weeks of work to get to acceptable deliverability, plus ongoing operational burden that other providers handle for you.

This article is the inverse of a SES pitch. It catalogues the situations where SES is the wrong choice and what to pick instead. Some of these are personal experience. Some are well-trodden patterns. None are unique opinions in the deliverability community.

How SES Differs from Managed ESPs

SES is closer to an SMTP relay than to a Mailgun/Postmark/SendGrid-style ESP. You bring the deliverability operations, SES brings the throughput. Specifically, SES does not:

• Pre-warm new dedicated IPs (you must script the ramp).
• Curate shared pools — you share IPs with whoever else is using SES.
• Maintain a suppression list across regions (per-region only, until 2023).
• Provide a dashboard for reputation, bounce trends, complaint patterns.
• Block sends that violate best practices.
• Offer human deliverability support unless you have an enterprise support contract.

If you do not have someone on the team who already does this work, SES is the wrong fit.

Reason 1: You Are Under 200k/month

At low volume the headline price difference is meaningless. SES at 100k/month costs ~$10. SendGrid Essentials at 100k costs $20. Postmark costs $15. The $5-10/month "savings" do not justify the operational overhead.

Below 200k/month, pick a managed ESP. The deliverability work alone is worth more than 5 engineer-hours/month, which is the rough overhead of running SES yourself.

Reason 2: You Have No Dedicated Deliverability Owner

SES requires someone who watches bounce rates, suppresses bad addresses, requests sandbox escalation, files re-warm-up tickets after volume drops, and handles complaint rate alerts. If nobody on your team owns this, the bounce rate climbs and AWS will pause your account.

AWS's pause email is brutal: your account goes into review pause, you have 24-48h to respond with a remediation plan, and during the pause you cannot send. This has caught many teams off guard.

Reason 3: You Are Brand New to Email

SES sandbox is a deliberately restrictive starting environment: you can only send to verified addresses, max 200/day. To "graduate" you must file a sandbox-escalation request explaining your use case, expected volume, list-acquisition method and bounce handling.

This is fine if you have done it before. If you are new to email it is a 2-3 day delay while you write the right request — and a 50% chance of rejection if the request looks like a marketing volume play without strong list hygiene.

Reason 4: You Need Built-In Templates or Marketing

SES has a basic template feature (SendTemplatedEmail) but no editor, no version history, no team workflow, no audience segmentation. If your marketing team needs anything beyond "send this HTML to this list", SES is not their tool.

⚠️ Warning: SES Pinpoint, AWS's "marketing" layer on top, has been deprecated/repositioned multiple times. Do not bet a marketing roadmap on it.

Reason 5: You Want EU Data Residency

SES has multiple regions but the suppression list and reputation engine have historically been per-region with surprising cross-region effects. Setting up a clean EU-only SES practice requires explicit IAM and config work, and you still rely on AWS's US-based engineering for the underlying service.

If "EU data residency" is on your compliance checklist, pick an EU-native ESP and skip the AWS region complexity.

Reason 6: Your Reputation Is Already Damaged

SES gives you a shared pool reputation that mirrors AWS's general SES traffic. If your sending pattern is risky (re-engagement, cold), other SES customers in the same pool penalise you, and you penalise them. Managed ESPs with curated pools shield you from this.

Conversely, if your sending pattern is impeccable, SES gives you no premium for it — the shared pool reputation is the average.

Reason 7: You Need Send-Time Guardrails

SES will happily ship whatever you give it. No policy enforcement. The HBO Max-style "Integration Test #1" incident is structurally enabled, not prevented, by SES.

If you need policy-as-code at the send boundary (recipient allowlist, hold-window, content guardrails, idempotency), SES does not provide it. You can build it as a Lambda layer in front of SES, but you are now running an ESP yourself.

When SES IS the Right Fit

• You ship > 5M/month and have a dedicated deliverability engineer.
• You are already deep in the AWS ecosystem (IAM-controlled access, KMS encryption, integrated with SQS/Lambda).
• You ship pure transactional with verified consent and zero re-engagement.
• You can afford 2-4 weeks to graduate sandbox and pre-warm dedicated IPs.

What To Pick Instead

For SaaS under 500k/month: Postmark or Target

Both deliver transactional well, both have idempotency primitives, both have observability out of the box.

For developer-led startups: Resend or Target

Clean API, modern dashboard, no AWS boilerplate.

For European companies: Target or Mailgun EU

EU data residency by default, EU-based support.

For mixed transactional + marketing: Mailgun or SendGrid

Marketing features built in, decent transactional.

The Hybrid Model

Some teams use SES for marketing blasts (cheap, high volume, separate reputation) and a managed ESP for transactional (reliability, observability). This works if both are on different domains.

The opposite — SES for transactional, managed for marketing — is rarer because the cheap part of SES (volume marketing) is where you want it.

The Operational Math

At 1M/month:

• SES: $100 + ~5 engineer-hours/month = ~$500 fully loaded.
• Managed ESP: $200-500 with zero engineer-hours = $200-500.

SES is cheaper only if you have spare engineer capacity. If you are paying market rates for engineers, the math often flips against SES.

Closing

AWS SES is excellent infrastructure used by sophisticated teams to ship enormous volumes of transactional email cheaply. For everyone else, the unmanaged nature of SES turns the cheap price into a hidden ongoing cost. Target SMTP gives you managed deliverability with idempotency, suppression, policy enforcement and observability built in, and the Send-Time Firewall enforces guardrails that SES does not even attempt. If you ever planned a 6-month "SES migration project", check whether one of the managed alternatives gets you to the same outcome in a week.