How to use Amazon SES to send newsletters at scale

If you’re running more than one newsletter and you’ve started doing the math on Resend, Postmark, or Mailchimp at 100,000 emails a month, you’ve probably already arrived at the same conclusion most operators do eventually: Amazon SES charges per email sent with no per-contact fees, and at volume that is hard to ignore. This post is the playbook for moving to SES. Implementation, the parts vendors don’t tell you, and what to do six months later when reputation problems show up.

The case for SES, in one paragraph

SES’s pay-as-you-go price is $0.10 per 1,000 emails sent (AWS SES pricing, checked 27 October 2026; AWS also lists subscription-style tiers, so read the page for current prices). There is no retainer: you verify a domain, you send mail, you pay for what you use. At that rate, a single newsletter sending to 1,000 subscribers daily costs about $3 a month, and 100 newsletters at the same volume about $300. Compare that with the current price pages of the providers you’re considering. The tradeoff: SES gives you a sending engine, not a mailing platform. You bring everything else — list management, unsubscribe links, bounce handling, analytics. If your stack already provides those (or if you’re running One Two Three Send and they’re built-in), this is the right tradeoff. If you want a dashboard that shows you a graph of opens, SES is the wrong product.

Cost math, with real numbers

Assume a brand averaging 1,000 active subscribers, sending five newsletters a week. That’s about 22,000 emails a month per brand.

Brands	Emails/month	SES cost at $0.10 per 1,000
1	22,000	$2.20
10	220,000	$22
100	2,200,000	$220

Prices for Resend, Postmark and Mailgun change often, so check their own pricing pages for your volume before you decide. Price isn’t everything: Postmark’s bounce dashboard, for example, is worth weighing. Whether SES is worth the implementation work depends on your volume and how much setup you want to own.

Setup, in the order you should actually do it

Step 1: Request production access. Today. Before anything else.

SES starts every account in sandbox mode: 200 emails a day, and you can only send to addresses you’ve verified. Nobody mentions this until you’re trying to debug why your test send works to your own inbox but fails to your subscribers’. Production access is a one-paragraph form in the SES console. AWS says its support team gives an initial response within 96 hours (SES production access docs, checked 27 October 2026). Submit it on day one of your migration project so the clock is running while you do everything else. The form asks for your mail type, website URL and contact addresses, and asks you to confirm that recipients opted in and that you handle bounces and complaints. Be specific about how.

Step 2: Verify your sending domain (not your email address)

You can verify a single email address ([email protected]) but don’t. Verify the domain (yourbrand.com). Domain verification gives you DKIM signing for everything sent from any address at that domain, which is the deliverability win. In the SES console, “Verified identities” → “Create identity” → “Domain” → enter the domain → enable DKIM. SES gives you three CNAME records to add to your DNS. They look like random123._domainkey.yourbrand.com pointing at random123.dkim.amazonses.com. Add them to your DNS. Wait 10 minutes. Refresh the SES console. Three green checkmarks. The pitfall here: many DNS managers strip the trailing period on CNAME values, or auto-append the parent domain. If your DKIM checkmarks stay yellow after an hour, the cause is almost always that your CNAME target now reads random123.dkim.amazonses.com.yourbrand.com instead of just random123.dkim.amazonses.com. Edit the record, remove the appended bit.

Step 3: Create the credentials

You have two paths here, and which one you pick determines how much code you’ll write. Path A — SMTP credentials. SES SMTP settings → “Create SMTP credentials”. AWS generates an IAM user behind the scenes and gives you an SMTP username and password. Plug those into any SMTP-capable mail tool (including the SMTP option in One Two Three Send). Zero new code. Endpoint is email-smtp.us-east-1.amazonaws.com:587. Path B — IAM access keys for the SES API. Create an IAM user with the AmazonSESFullAccess policy (or scoped down to ses:SendEmail on your verified domain ARN, which you should do for production). Grab its access key ID and secret access key. Use these to sign SES API v2 requests directly with AWS Signature v4. To start, use Path A. SMTP is fast enough and saves you the SigV4 signing implementation. At higher volumes, Path B becomes worth it because you can attach configuration sets, message tags, and skip the STARTTLS roundtrip.

Step 4: Set up the From address and reply-to

Your From: address must be at the verified domain. [email protected] works. [email protected] does not, even if yourbrand.zendesk.com resolves — Zendesk’s domain isn’t verified in your SES account. Set a real reply-to. Subscribers reply. If your reply-to is noreply@, you’re throwing away the most valuable feedback signal a newsletter has.

Step 5: Send your first email

The acid test: send to a Gmail address, an Outlook address, and a Yahoo address you control. Open Gmail’s “Show original” view on the received message. You should see:

• SPF: PASS (with amazonses.com)
• DKIM: PASS (signed by yourbrand.com)
• DMARC: PASS (only if you have a DMARC record — see pitfalls)

If any of those say NEUTRAL or FAIL, fix that before sending to a single real subscriber. Inbox providers are unforgiving with new senders, and your first sends set the reputation that follows you.

Step 6: Set up bounce and complaint handling

Skip this step and your bounce and complaint rates can climb unnoticed until AWS puts your account under review or pauses sending (SES reputation metrics). Create an SNS topic (ses-feedback). In the SES configuration set, attach event publishing for Bounce and Complaint events to this topic. Wire the topic to an HTTP endpoint on your site that flips the matching subscriber’s status to bounced or complained and stops sending to them. This is the difference between “I send mail with SES” and “I run a newsletter on SES that won’t get suspended in month four.”

SES vs the rest, honestly

vs Resend — Resend has a beautiful API and a dashboard that’s a joy to use. Compare its current pricing against SES at your volume. vs Postmark — Postmark is known for transactional email and a detailed bounce dashboard. Check its current pricing for broadcast sending at your volume. It can be worth using for transactional emails (welcome flows, password resets) even if you use SES for newsletters. vs Mailgun — Another sending API. Compare its current pricing and features against SES for your volume. vs Mailchimp / ConvertKit / Beehiiv — Different category. Those are mailing platforms (list, editor, analytics, automation). SES is a sending engine. You wouldn’t compare a hosting provider to Squarespace; same logic applies. vs SendGrid — SendGrid is what you use when your dev team wants to use SendGrid. It’s fine. Check its current pricing for your volume.

Pitfalls, in the order operators usually hit them

1. The sandbox catches everyone. First send to a real subscriber bounces with “Email address is not verified” and you spend two hours debugging your code. The error message means SES, not your subscriber’s address. Submit the production access request before you do anything else. 2. DMARC alignment. If you have a _dmarc TXT record set to p=reject, your SES emails will fail DMARC unless your From: domain matches the DKIM signing domain. SES handles this automatically when you verify the full domain (Step 2 above), but if you verified only an email address, you’ll fail DMARC alignment and your mail may be filtered or rejected. Verify domains, not addresses. 3. Bounce and complaint thresholds. AWS publishes the levels it acts on (SES sending review FAQs, checked 27 October 2026): a bounce rate of 5% or more puts your account under review and 10% or more can pause sending; a complaint rate of 0.1% or more puts it under review and 0.5% or more can pause sending. AWS recommends keeping bounces below 2% and complaints below 0.1%. Clean lists before you migrate to SES. Run a list-validation pass through a service like NeverBounce or Kickbox first. 4. The shared IP problem (and the dedicated IP solution). SES sends from shared IP pools by default. If another SES customer on your IP range sends spam, your reputation gets dinged through no fault of your own. For many senders shared pools are fine. At high volumes, consider a dedicated IP ($24.95 per month per IP on AWS’s standard plan, per the SES pricing page, checked 27 October 2026). For 100 brands, give each of the highest-volume few their own IP and pool the long tail. 5. IP warming. New dedicated IPs need a gradual ramp. AWS’s standard dedicated IPs warm up automatically over 45 days, and AWS advises against large volume spikes after warm-up (SES dedicated IP warm-up, checked 27 October 2026). Don’t override the schedule because you’re impatient. 6. The implicit unsubscribe link requirement. Gmail and Yahoo’s 2024 sender requirements mandate one-click unsubscribe headers (List-Unsubscribe-Post: List-Unsubscribe=One-Click) for any sender doing more than 5,000 emails a day to their domains (Google’s sender guidelines, checked October 2026). Make sure your sending code or platform adds them. Without the header, your mail to Gmail can be filtered or rejected. 7. Sending across regions. SES sending quotas are per-region. If you start in us-east-1 and migrate to eu-west-1 later, your reputation doesn’t follow. Pick a region on day one and stay there.

Long-term maintenance

The first two months of SES are setup theater. The rest is reputation management. Daily: keep an eye on the SES “Reputation dashboard.” Bounce rate trending up means a list-quality problem; complaint rate trending up means you’re sending content people don’t want. Both are fixable, but only if you notice. Set a CloudWatch alarm on bounce and complaint rates well below the levels at which AWS reviews accounts (5% bounces, 0.1% complaints). Weekly: review the bounce/complaint webhooks for patterns. A spike in bounces after a specific newsletter usually means a corporate domain blocked you. A spike in complaints usually means a specific email’s subject line came across as spammy or you imported a list segment that didn’t actually opt in. Monthly: prune subscribers who haven’t opened in 90 days. AWS advises monitoring engagement and no longer sending to recipients who don’t open or click (SES sending review FAQs). This is counterintuitive — you’re paying for the email, why would sending to a quiet address hurt? — but mailbox providers do pay attention to how recipients engage. Quarterly: rotate your IAM credentials. Even if nothing has gone wrong, do this anyway. AWS makes it easy (create new credentials, deploy, deactivate the old set, delete after 30 days), and it gets you in the habit of treating sending credentials with the same care as customer data. Annually: review your SES sending quota against actual volume. If you’ve grown a lot and you’re still on your original sending quota, you may hit it at peak send times. You can request a quota increase in the console.

When SES is the wrong choice

If you’re sending modest volumes, the time you’ll spend on setup, monitoring, and bounce handling may be worth more than the cost difference. Use Resend or Postmark. Come back when you scale. If your team has zero AWS experience and zero appetite to gain it, the implementation is the iceberg’s tip. Operating SES correctly takes ongoing attention. If nobody on the team finds CloudWatch dashboards reasonable, pick a vendor whose abstraction matches your team’s skills. If you need a polished UI for non-technical staff to manage lists, write campaigns, and view stats, SES will frustrate everyone involved. It’s a sending engine, not a product. For everyone else: SES is the most boring infrastructure decision you can make for a newsletter business, and that’s the highest compliment infrastructure can earn.

Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.