Amazon SES for email marketing: the complete guide

Amazon SES sends email for $0.10 per 1,000 messages and does nothing else. There is no list, no campaign editor, no unsubscribe page, and no idea who your contacts are. Every product people call “email marketing on SES” is something built on top of that API, whatever route you took to get there.

That gap between “an API that sends email” and “a tool you’d hand a marketer” is the reason an SES price and a Mailchimp price aren’t answering the same question. SES really is one of the cheapest ways to move bulk mail. It is also, by itself, missing everything a subscriber ever interacts with directly: the unsubscribe link, the preference center, the list they’re on in the first place.

Every figure below comes from Amazon’s own pricing and documentation pages. Prices and quotas change; check the source before you budget or build against them.

Key Takeaways

• SES charges $0.10 per 1,000 emails à la carte. New accounts and long-idle ones now default to a metered plan that charges more, since July 21, 2026.
• Every new account starts in a sandbox: 200 emails a day, one a second, verified recipients only, until AWS grants production access.
• SES gives you a delivery API, DKIM signing, and bounce and complaint feedback. It has no concept of a list, a campaign, a template, or an unsubscribe.
• Four real paths put a front end on it: self-hosted software, a hosted tool that still uses your AWS account, your own code, or a platform that offers BYOS as one of its sending modes.
• If you don’t want an AWS account, don’t want to review a production access request, or send too rarely to make the arithmetic work, SES marketing email isn’t for you yet, whatever the rate is.

What Amazon SES actually is

Amazon Simple Email Service is a regional API for sending and receiving email at the level of a single message. You call SendEmail, hand it a recipient, a subject, and a body, and SES attempts delivery. It sits in the same family as Amazon SNS and SQS: infrastructure a bigger system is built on, not a product a marketer opens and uses.

SES also receives mail, storing or forwarding inbound messages through its own rule sets and, more recently, through a separate product called Mail Manager. A marketing sender rarely touches that side at all; it matters mainly if you point a reply-to address at your own domain and want to do something with what comes back, and it bills on its own separate meter from outbound sending.

That makes SES a poor comparison to Mailchimp, Brevo, or any tool with “email marketing” in its name. Those products bundle a sending engine with everything around it: contact storage, segmentation, a visual editor, scheduling, unsubscribe handling, and reporting. SES is only the engine. It authenticates your sending domain with DKIM, tracks your account’s reputation, and tells you what happened to each message through events you subscribe to. It has no idea what a “contact” or a “campaign” is, because those concepts don’t exist below the API layer. As raw sending infrastructure, it’s a closer match for Mailgun or Postmark than for any of those.

People reach for SES anyway because the sending itself is cheap and because they already have an AWS account for everything else they run. Both are true. Neither means the rest of a marketing tool shows up for free.

Underneath the send call, SES organizes a few things worth knowing the names of, because you’ll see them in every console screenshot and every tool built on top. An identity is a domain or an individual address you’ve verified you control; you send “from” an identity. A configuration set groups settings you attach to a send: which events get published, which IP pool it goes out from, whether an account-level suppression override applies. And a dedicated IP pool is a way of grouping dedicated IPs so different kinds of mail, transactional versus marketing, build separate sending reputations. None of that is marketing-tool functionality: it’s plumbing a marketing tool, or you, configures once and mostly forgets about.

What it costs, in full

The rate everyone quotes is real: $0.10 per 1,000 emails, no monthly fee, no minimum, billed as you send. A newsletter of 20,000 subscribers mailed weekly is about 80,000 emails a month, which is $8.00.

That rate is called à la carte pricing, and it’s one of three ways SES now bills outbound email. On July 21, 2026, Amazon introduced three subscription plans as an alternative: Essentials, Pro, and Enterprise. New SES accounts, and any account and region combination with no metered SES activity since June 1, 2025, now start on Essentials rather than à la carte, and nothing prompts you to switch.

Essentials charges $0.16 per 1,000 emails up to 10 million a month, 60% more than à la carte at the entry tier, with no monthly account fee. Pro and Enterprise charge more per email again and add a flat monthly fee per account per region, $105 and $500. At real marketing-email volumes, most senders are better off checking which plan their account defaults to and switching to à la carte if none of a plan’s extras apply to them.

Rates from Amazon’s SES pricing page, as of July 2026. Outbound email only, no attachment data.

The rate you pick covers exactly one thing: handing a message to AWS and having it attempted. Everything else SES sells meters separately and is off by default, which is also how it gets left on: a dedicated IP, Virtual Deliverability Manager, inbound mail, Mail Manager archiving. None of them are needed to send a marketing campaign, and all of them are easy to switch on once and forget. A dedicated IP alone runs $24.95 a month per address at the standard rate, almost exactly what a quarter million emails costs to send at à la carte ($25.00). Whether that address is worth adding at all comes down to volume: a dedicated IP only earns its own reputation once you’re sending enough, consistently enough, to build one, rather than riding a shared pool’s.

Two costs never show up on the AWS bill at all. Amazon SNS, which SES uses to publish delivery, bounce, and complaint events, is billed separately and shows up as its own line in Cost Explorer. And nobody bills you for the work of watching your bounce and complaint rates, keeping a suppression list current, and reacting when AWS puts your account under review. SES charges nothing for that and expects you to do all of it.

A new AWS account may also carry a free-tier credit that applies to SES usage, on top of everything above. The terms and amount are account-specific and change, so check AWS’s current free tier page for yours rather than budgeting around a number from a blog post.

The sandbox: what every new account starts in

Every SES account, in every region, starts in the sandbox. AWS documents the restrictions plainly: you can send to verified email addresses and domains only, a maximum of 200 messages in any 24-hour period, and no more than one message per second. Bulk suppression-list operations are disabled too. You can build and test everything else while sandboxed; you just can’t reach a real audience.

The sandbox exists to stop SES being used to blast spam from a freshly opened account before anyone has reviewed it, and every account passes through it regardless of what it’s eventually used for.

Leaving it means requesting production access, and you do that inside your own SES console, not through any tool built on top of SES. AWS asks whether you send mostly marketing or transactional mail, your website URL, and up to four contact addresses for account communications, and asks you to confirm you’ll only mail people who asked for it and that you have a process for handling bounces and complaints. A verified sending domain strengthens the request, since it’s the clearest evidence of what you’re sending and from where. AWS’s stated response window is 24 hours, faster if nothing about the request needs a follow-up question, and once you submit it you can’t edit the details until the review finishes. What separates an answer that clears review quickly from one that stalls is mostly specificity in those same answers, covered one by one in getting out of the SES sandbox.

Once granted, production access removes the verified-recipient restriction and raises your quota and rate, though AWS is explicit that it does not publish one fixed starting number for a production account: what you get depends on your account, your region, and what you’re sending. It’s not a bigger tier you’re handed; it’s a number that grows as your account earns a track record.

Sending quotas and rate limits, once you’re out

SES governs two numbers per account, per region: a sending quota, the maximum number of emails in any rolling 24-hour period, and a maximum send rate, the number of emails SES will accept per second. Neither is fixed. AWS raises both automatically as an account demonstrates high-quality sending: real content going to real recipients, low bounce and complaint rates, and volume that regularly approaches the current quota without exceeding it. An account that never sends near its limit, or that sends mostly to addresses that don’t exist, doesn’t get raised automatically.

You can also request an increase directly through the Service Quotas console, and AWS’s stated turnaround for a sending quota or rate increase is up to 24 hours, the same window as the initial production access request.

There’s no ceiling published as a hard maximum. Very high-volume senders eventually need a dedicated IP and a sending review rather than a bigger number on the same shared infrastructure, but that’s a different conversation from the quota a marketing sender hits first.

In practice, this means a campaign sender’s real bottleneck usually isn’t the per-email rate: at even a conservative 10 emails a second, 50,000 emails clears in under an hour and a half. It’s the 24-hour quota, especially early on, when an account fresh out of the sandbox hasn’t yet earned a large one. Planning a launch campaign against a quota you haven’t confirmed in your own console is the most common way this catches people out.

What SES gives you

Strip away the marketing-platform comparison and SES is a genuinely capable delivery layer:

• A send API, over HTTP, SMTP, or an AWS SDK, with a template mechanism for merging per-recipient data into a message body.
• Domain authentication. SES generates the DNS records for DKIM signing and verifies a sending domain against them.
• Delivery events. Every send, delivery, bounce, complaint, open, and click can be published to Amazon SNS in near real time.
• An account-level suppression list. SES automatically adds addresses that hard-bounce or complain, and by default skips sending to them again, at the AWS account level. Soft bounces, re-imported addresses, and unsubscribes are never added to it automatically, so tracking and honoring those is work you build on top, covered in full in bounces, complaints and suppression in SES.
• A reputation dashboard, showing your bounce and complaint rates against the thresholds AWS enforces, and whether your account is healthy, under review, or paused.
• Multi-tenant separation, for accounts that need it: SES tenants let one AWS account keep separate configuration, reputation tracking, and suppression lists for different sub-brands or clients sending under the same account.

That’s a real foundation. It is also, deliberately, the whole of what SES gives you.

What you still have to build or buy

Everything a subscriber-facing marketing tool needs sits above that line, and SES has no opinion on any of it:

• Contacts. No table of subscribers, no fields, no import, no dedup. “Send to this list” isn’t a concept SES has.
• Segmentation. No concept of an audience or a filter. Every send is you supplying an explicit recipient list.
• A campaign and template system. No visual editor, no drag-and-drop blocks, no scheduling, no draft-and-send workflow, and no state machine deciding what a status change is allowed to do once you’ve built one.
• Unsubscribes. SES’s suppression list only knows about hard bounces and complaints. It has never heard of a person clicking “unsubscribe,” because SES has no unsubscribe link, no preference center, and no concept of consent. Building a compliant one-click unsubscribe is entirely your responsibility.
• Reporting people can read. SES gives you a stream of raw events. Turning that into “this campaign had a 34% open rate” is a data pipeline you build.
• List hygiene beyond bounces and complaints. Soft bounces, spam-trap hits, and stale addresses don’t touch SES’s suppression list at all; that judgment is yours.

None of this is a criticism of SES. It’s a scoping problem for anyone who reads “$0.10 per 1,000 emails” and assumes the rest comes with it.

The four ways to put a front end on SES

Once the gap is clear, there are four realistic ways to close it.

Self-hosted software means installing an application you run yourself and pointing it at SES for delivery. Sendy is the well-known example: a one-time $69 license, no subscription, that you host on your own PHP server and connect to your AWS account. You get a real campaign UI and list management for a fixed cost, and you take on running a server, applying updates, and being the one who notices when something breaks. That last part is easy to underweight: a missed security patch or a full disk is now your outage to diagnose, with no support line to call. Whether that trade is worth it comes down to what your own time watching a server is worth against the monthly fee a hosted alternative would charge instead, a comparison whether Sendy’s license still beats a subscription in 2026 works through in full.

Hosted tools built for BYOS give you a SaaS product, contacts, campaigns, templates, reporting, without the license fee or the server, but they still require your own AWS account for sending, so you carry two bills: the tool’s subscription and Amazon’s charge for the mail it sends. BigMailer and MailBluster are two examples in this category, and two of the five SES front ends we ranked head to head on price and free tier; we’ve written up both in detail, including where their pricing gets more complicated than the headline number: the BigMailer alternative comparison and the MailBluster alternative comparison.

Building it yourself means writing directly against the SES and SNS APIs: your own list storage, your own template rendering, your own suppression sync from the SNS bounce and complaint feed, your own unsubscribe link and preference handling. It’s the only option with no monthly software fee beyond the AWS bill, and the only one where every piece of the gap above is now a piece of software your team owns and has to keep correct, including the compliance parts that are easy to get subtly wrong. Sync your own suppression cache from SES’s a day late and you’re mailing someone SES already flagged. SES also only auto-suppresses hard bounces and complaints, never a soft bounce, however many times it repeats, so deciding when a repeatedly soft-bouncing address should stop being mailed is a rule you have to write yourself.

A platform that offers BYOS bundles the full marketing tool, contacts, campaigns, automations, forms, reporting, with a choice of how it sends: through the platform’s own infrastructure, or through your own AWS account connected by an IAM role scoped to only what SES setup needs, not standing access to the rest of the account. EmailFig works this way. What BYOS actually means here covers the mechanics: you launch one CloudFormation stack, EmailFig connects to it and provisions what SES needs, and after that every send goes out through your own account while AWS bills you directly for it. That gets you the same “your AWS bill, your reputation” arrangement as the hosted BYOS tools, inside a platform that also does the parts SES doesn’t: lists, campaigns, unsubscribes, and reports.

Connecting an account is covered in connecting your own Amazon SES account, and leaving the sandbox from inside that setup in requesting production access.

Who should not use SES for marketing email

Skip SES, in any of the forms above, if any of the following is true:

• You don’t want an AWS account. Every path above assumes you have one or are willing to create one, understand its console, and watch its bill. If that’s not appealing on its own, the $0.10 rate isn’t worth chasing.
• You can’t clear a production access review, or don’t want to. It’s a short request, but it is a request someone has to file, wait on, and occasionally follow up on. A tool that hides this from you doesn’t remove the step; it just means you’re waiting without knowing why.
• You send too rarely for the arithmetic to matter. SES’s savings show up at volume. A newsletter of 500 people sent monthly is a few hundred emails, cents either way, and a managed tool’s simplicity is worth more than the fraction of a cent it might save.
• You’d rather not own reputation and deliverability. On any BYOS arrangement, your bounce and complaint rates are your account’s, watched by AWS directly. A tool that sends through its own shared infrastructure absorbs that watch for you, at a cost baked into its price instead of billed separately by Amazon.
• You’re building for someone who will never touch AWS. If you’re setting this up for a client, a less technical cofounder, or anyone who won’t maintain the connection, the AWS layer becomes a support burden on you rather than a saving for them.
• The 200-email sandbox ceiling isn’t a rounding error for you. If you need to send a real campaign this week and haven’t verified a domain, filed a production access request, or budgeted the day or two AWS might take to answer, the timeline alone rules SES out for this launch, whatever it fits later.

Where that line actually falls in dollars, not just discomfort, is the point where the account overhead costs more of your time than the AWS rate saves, and it arrives sooner than most people expect at low volume.

None of this is an argument against SES for people it fits. It’s an argument against assuming it fits everyone, which is the assumption almost every page about SES pricing quietly makes.

Frequently asked questions

Is Amazon SES good for email marketing?

Amazon SES is good for the sending itself: fast, reliable, and among the cheapest ways to move bulk email. It is not, by itself, a marketing tool, since Amazon SES has no list, no campaign editor, and no unsubscribe page. It only becomes one once you add a front end, whether that’s self-hosted software, a hosted tool, your own code, or a platform offering BYOS on top of it.

How much does it cost to send 100,000 emails with Amazon SES?

At Amazon SES’s à la carte rate of $0.10 per 1,000 emails, 100,000 emails costs $10.00. An account that defaults to the newer Essentials plan instead pays $0.16 per 1,000, or $16.00 for the same 100,000 emails. Both rates are from Amazon’s SES pricing page; check which plan your account is actually on before you budget against either number.

How do I get out of the Amazon SES sandbox?

Every new Amazon SES account starts in a sandbox capped at 200 messages a day, sent only to addresses you’ve verified yourself. You leave it by filing a production access request in your own SES console, and AWS’s stated response window is 24 hours. Getting out of the SES sandbox covers what to put in the request to clear review quickly.

Do I need a dedicated IP on Amazon SES?

Only past a real amount of consistent volume. A dedicated IP has to be warmed and kept busy to earn its own reputation; below that volume it just trades a shared pool’s earned standing for a blank one. It also costs $24.95 a month, close to what 250,000 emails costs to send at the à la carte rate. Who needs a dedicated IP on Amazon SES works through where the volume crosses over.

Does Amazon SES handle unsubscribes?

No. Amazon SES’s suppression list only tracks hard bounces and complaints, never an unsubscribe click: no link, no preference center, no consent tracking. A compliant one-click unsubscribe is something you build on top of it.

What’s the difference between Amazon SES and Mailchimp?

Amazon SES is a delivery API: you hand it a message and it hands back events about what happened to it. Mailchimp is a full marketing platform built on infrastructure like that, bundling contact lists, a campaign editor, segmentation, and reporting together with the sending itself. Comparing Amazon SES’s $0.10-per-1,000 rate to a Mailchimp plan price compares an engine to a finished car; a fairer comparison for Amazon SES is against similar raw infrastructure, which is exactly what SES vs Mailgun vs Postmark works through.

Choosing a path

Start with the account question, because it decides everything after it. No interest in an AWS account, or in owning production access and reputation directly: a managed platform is the right shape, whether that’s a fully hosted tool or the managed side of a platform that also offers BYOS. Already comfortable there, or already running one: the choice becomes cost and ownership, self-hosted software for the lowest fixed cost, a hosted BYOS tool for the least maintenance, your own code for full control, or a platform’s BYOS mode for a full marketing tool without giving up the AWS-billed sending rate. BYOS is genuinely cheaper at scale, but it has a floor below which the AWS account costs more in attention than it saves in dollars, so that choice assumes you’re past it.

EmailFig covers both ends of that: managed sending for people who’d rather not open an AWS account, and BYOS for people who want their own. Both are free up to 4,000 subscribers, and BYOS and managed pricing sit side by side so the comparison is direct rather than something you have to reconstruct from two different pages. A closer look at what the AWS side of that bill actually adds up to, line by line, is worth reading before you commit either way: what Amazon SES actually costs.