DEV Community: Shreyash

Amazon SES Review: The Brutal Truth for Next.js Developers (2026)

Shreyash — Thu, 26 Mar 2026 15:44:29 +0000

📖 This is a condensed version. Read the full Amazon SES review with code examples and setup guide on DevDecide.

Most "best email provider" articles are written by SEO agencies chasing affiliate commissions. This one isn't.

We integrated Amazon SES into a real Next.js app — configured DKIM/SPF/DMARC, sent transactional emails, handled bounces via SNS webhooks, and intentionally broke things to see what happens. Here's the honest breakdown.

Why Even Consider Amazon SES?

The pricing speaks for itself:

Provider	100,000 emails/month
SendGrid	~$89.95
Resend	~$35.00
Amazon SES	$10.00

At scale (500k emails/month), SendGrid costs ~$249. SES? $50.

But AWS makes you earn every penny of those savings.

The Good: Code Experience is Excellent ✅

The AWS SDK v3 is modular, lean, and async-native — perfect for Next.js Server Actions.

npm install @aws-sdk/client-ses

import { SESClient, SendEmailCommand } from "@aws-sdk/client-ses";

const sesClient = new SESClient({ region: "us-east-1" });

export async function sendWelcomeEmail(userEmail) {
  const command = new SendEmailCommand({
    Source: "hello@your-saas.io",
    Destination: { ToAddresses: [userEmail] },
    Message: {
      Subject: { Data: "Welcome aboard!" },
      Body: { Text: { Data: "We are thrilled to have you." } }
    }
  });
  return await sesClient.send(command);
}

Clean, promise-based, minimal boilerplate. Rating: 4.5/5

The Ugly: Sandbox + Bounce Handling ⚠️

The Sandbox Trap

Every new SES account starts in a sandbox where you can only send to manually verified addresses (200 emails/day max). Getting production access requires submitting a detailed support ticket — and waiting 24–72 hours. Don't leave this for your launch night.

Bounces Will Destroy Your Account

Bounce rate > 5% → account review
Bounce rate > 10% → permanent ban

SES doesn't track this automatically. You must wire up an SNS topic → webhook → database blacklist pipeline yourself. This is non-trivial infrastructure.

Who Should Use Amazon SES?

✅ Use it if you:

Are comfortable with DNS records (DKIM, SPF, DMARC)
Can build and maintain bounce-handling webhooks
Want to aggressively control infrastructure costs at scale

❌ Avoid it if you:

Want plug-and-play email with zero DevOps
Need a visual dashboard, analytics, or drag-and-drop templates
Can't afford time for a multi-day setup process

Our Final Rating

Category	Score
Developer Experience	4.5 / 5
Deliverability	5 / 5
Pricing	5 / 5
Setup Complexity	3 / 5
Overall	4.8 / 5

Amazon SES is raw infrastructure at wholesale prices. If you're willing to do the engineering work, nothing beats it for transactional email at scale.

👉 Get the full guide with IAM setup, SNS bounce handling, and production-ready code on DevDecide.

Amazon SES Setup: The Things Nobody Tells You (Bounce Handling, DKIM, IAM)

Shreyash — Wed, 25 Mar 2026 18:18:00 +0000

📖 Full guide with all code snippets and DNS records: Amazon SES Setup — The Complete Guide

Every Amazon SES tutorial on Google shows outdated screenshots and zero mention of what happens when your bounce rate spikes and AWS silently kills your account.

This post covers the parts that actually bite you in production.

Why SES? The Math Is Simple

Provider	100,000 emails/month
SendGrid	~$90
Amazon SES	~$10

That's not a rounding error. One order of magnitude cheaper. For a bootstrapped SaaS sending transactional emails, that compounds fast.

The trade-off: AWS does not hold your hand. Misconfigure it and your emails land in spam — or your account gets permanently revoked.

Step 1: Understand the SES Sandbox

Every new AWS account starts sandboxed. Hard limits apply:

Max 200 emails per 24 hours
Max 1 email per second
You can only send to pre-verified email addresses

To escape the Sandbox, open a support case under Service Limit Increase → SES Sending Limits.

⚠️ Don't submit this ticket yet. Build your bounce handling infrastructure first (Step 3). AWS will ask how you handle bounces — you need to already have an answer.

Step 2: Verified Identity + DKIM

Go to SES Console → Verified Identities → Create Identity → Domain.

AWS generates 3 CNAME records for DKIM. Add them to your DNS:

Name:  token1._domainkey.yourdomain.com
Type:  CNAME
Value: token1.dkim.amazonses.com

Also add SPF and DMARC records. All three working together is what gives your domain a clean sender reputation from day one. Without DMARC, even a correctly DKIM-signed email can get flagged.

Step 3: Configuration Sets — The Most Skipped Step

This is where most developers fail. Here are the limits AWS enforces:

Metric	Probation	Suspension
Bounce Rate	5%	10%
Complaint Rate	0.08%	0.1%

When you hit 10% bounces, SES suspends you instantly with no warning. Reactivating takes a manual support ticket and days of waiting.

Configuration Sets are the fix. They route bounce and complaint events to an SNS topic → your webhook → your database.

Setup in 5 steps:

SES → Configuration Sets → Create → name it production-transactional
Add destination → choose SNS
Check Hard Bounces and Complaints
Create SNS topic ses-bounces-topic
Add an HTTPS subscription pointing to your webhook URL

Every email you send must include ConfigurationSetName in the API call. If you omit it, bounces are not tracked at all.

Step 4: Sending Email (Node.js SDK v3)

import { SESClient, SendEmailCommand } from "@aws-sdk/client-ses";

const sesClient = new SESClient({ region: "us-east-1" });

export async function sendTransactionalEmail(toAddress, subject, htmlBody) {
  const params = {
    Source: "hello@yourdomain.com",
    Destination: { ToAddresses: [toAddress] },
    Message: {
      Subject: { Data: subject, Charset: "UTF-8" },
      Body: { Html: { Data: htmlBody, Charset: "UTF-8" } },
    },
    ConfigurationSetName: "production-transactional", // Never omit this
  };

  const command = new SendEmailCommand(params);
  const response = await sesClient.send(command);
  return response.MessageId;
}

Same parameters map directly to Boto3 (Python), PHP, Ruby, or any official AWS SDK.

Step 5: Handle the Bounce Webhook

When SNS fires your webhook, it sends a SubscriptionConfirmation POST first. You must auto-confirm it or real events never arrive.

export async function POST(request) {
  const snsMessage = JSON.parse(await request.text());

  // Confirm subscription on first contact
  if (snsMessage.Type === 'SubscriptionConfirmation') {
    await fetch(snsMessage.SubscribeURL);
    return Response.json({ status: 'confirmed' });
  }

  if (snsMessage.Type === 'Notification') {
    const sesEvent = JSON.parse(snsMessage.Message);
    if (sesEvent.notificationType === 'Bounce') {
      const affected = sesEvent.bounce.bouncedRecipients.map(r => r.emailAddress);
      // Blacklist these in your DB — never email them again
    }
  }
}

Then guard every send:

if (!user?.emailDeliverable) return; // Skip blacklisted addresses

This single check keeps your bounce rate clean at scale.

The IAM Policy (Least Privilege)

Give your app credentials only what they need:

{
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ses:SendEmail", "ses:SendRawEmail"],
    "Resource": "*"
  }]
}

No identity management. No billing access. If credentials leak, blast radius is contained.

4 Mistakes to Avoid

Omitting ConfigurationSetName — AWS won't throw an error, but bounce tracking is dead
Verifying the wrong domain — mail.yourdomain.com ≠ yourdomain.com in SES
Not confirming the SNS subscription — bounce notifications never arrive
Mismatched AWS regions — your SESClient region must match where your identity was created

When SES Is NOT the Right Choice

Under 10,000 emails/month? Use Resend or Postmark — the DX is smoother and cost difference is negligible
No backend experience on your team? The SNS + IAM setup will cost more in debugging hours than you save
Need open rates, click tracking, A/B tests? SES gives you raw events. You build the dashboards yourself.

Come to SES when the invoices start to hurt.

The Bottom Line

SES's reputation for being painful is earned — but the engineering discipline it demands is exactly what keeps your infrastructure cheap and stable at scale.

$10 per 100,000 sends vs $90 elsewhere. Do the setup right once, and you never think about it again.

Want the full walkthrough with every DNS record, the complete webhook code, and the exact console steps?

👉 Amazon SES Setup: The Complete Guide — DevDecide

Amazon SES vs SendGrid: An Honest Comparison for SaaS Developers (2026)

Shreyash — Tue, 24 Mar 2026 18:43:00 +0000

If you search for Amazon SES vs SendGrid, you'll get pages of generic listicles written by SEO agencies. Writers who have never deployed a server, authenticated a JWT, or dealt with a CORS error — writing reviews designed entirely to capture affiliate commissions.

This comparison is different. It's based on actual SDK integration, real pricing math, and findings cross-referenced with engineers on Hacker News and Reddit.

Originally published on my blog → devdecide.com

Quick Verdict

Amazon SES wins on raw cost and AWS-native integration. SendGrid wins on out-of-the-box developer experience, managed deliverability, and marketing tooling. Neither platform is universally better — and that's the honest answer no listicle will give you.

What Are These Tools, Actually?

Amazon SES is bare-bones cloud email infrastructure from AWS. It gives you a reliable, pay-as-you-go sending engine — and absolutely nothing else. No dashboard. No visual editor. No bounce management UI. No automation workflows. Every feature beyond raw sending is something your engineering team has to build.

SendGrid (now owned by Twilio) is a full-featured email platform for both transactional and marketing emails. It ships with a template editor, automation workflows, advanced analytics, deliverability management, and a guided onboarding flow that gets teams sending in under an hour. The trade-off is cost — and at scale, that trade-off bites hard.

Pricing: Where the Decision Gets Clear Fast

Amazon SES charges $0.10 per 1,000 emails.

Volume	Amazon SES	SendGrid
100,000 emails/mo	~$10	~$89.95
500,000 emails/mo	~$53	~$249.95
1,000,000 emails/mo	~$107.70	~$399.95

SES is roughly 4–8x cheaper at volume. But the sticker price isn't the full story.

Hidden SES costs to watch:

Outgoing data transfer: $0.12/GB
Virtual Deliverability Manager: can add up to 70% on top of base cost
SNS notification charges

These typically add 10–15% on top of the base rate.

The honest math: If you're sending 500,000+ emails/month and have the engineering bandwidth to operate AWS infrastructure, SES saves serious money. Under 100,000 emails/month, SendGrid's operational simplicity may be cheaper once you factor in engineering hours.

Developer Experience: The Real Gap

On SendGrid, a backend developer can be sending authenticated transactional emails in under 30 minutes.

On Amazon SES, a first-time setup involves:

Creating and configuring an AWS account
IAM roles and permission policies
Domain verification and DKIM record setup
Configuration Set creation (critical — more on this below)
SNS topic + webhook endpoint for bounce/complaint handling
CloudWatch dashboards for monitoring

None of these steps are impossible. But they represent hours of infrastructure work before a single email gets sent.

API Comparison: Side by Side

Sending with Amazon SES (AWS SDK v3)

import { SESv2Client, SendEmailCommand } from "@aws-sdk/client-sesv2";

const client = new SESv2Client({ region: "us-east-1" });

const command = new SendEmailCommand({
  FromEmailAddress: "noreply@yourdomain.com",
  Destination: { ToAddresses: ["user@example.com"] },
  Content: {
    Simple: {
      Subject: { Data: "Your order has shipped", Charset: "UTF-8" },
      Body: {
        Html: { Data: "<p>Your order <b>#12345</b> is on its way.</p>", Charset: "UTF-8" },
        Text: { Data: "Your order #12345 is on its way.", Charset: "UTF-8" },
      },
    },
  },
  ConfigurationSetName: "your-config-set", // ⚠️ Never omit this
});

const response = await client.send(command);
console.log("Message ID:", response.MessageId);

Critical: Always pass ConfigurationSetName. Without it, bounces go untracked and AWS can suspend your sending account without warning.

Sending with SendGrid (Node.js SDK)

import sgMail from "@sendgrid/mail";

sgMail.setApiKey(process.env.SENDGRID_API_KEY);

await sgMail.send({
  to: "user@example.com",
  from: "noreply@yourdomain.com",
  subject: "Your order has shipped",
  text: "Your order #12345 is on its way.",
  html: "<p>Your order <b>#12345</b> is on its way.</p>",
});

Setup time delta: SendGrid reaches first successful send in ~15 minutes. Amazon SES requires IAM config, domain verification, DKIM setup, and Configuration Set creation — expect 1–3 hours minimum for a production-ready integration.

Rate Limits

Amazon SES

Limit	Sandbox	Production
Sending rate	1 email/sec	14 emails/sec
Daily quota	200 emails/day	50,000 emails/day

New SES accounts start in sandbox mode — you can only send to verified addresses. Production access requires a manual limit increase request (24–48 hour approval).

Handling throttling with exponential backoff:

const client = new SESv2Client({
  region: "us-east-1",
  maxAttempts: 5, // AWS SDK v3 handles ThrottlingException retries automatically
});

async function sendWithRateLimit(emails, ratePerSecond = 14) {
  const delay = 1000 / ratePerSecond;
  for (const email of emails) {
    await client.send(new SendEmailCommand(email));
    await new Promise((res) => setTimeout(res, delay));
  }
}

SendGrid

All paid plans enforce 600 requests/minute. The optimization most developers miss: batch up to 1,000 recipients per API call using personalizations.

const personalizations = users.map((user) => ({
  to: [{ email: user.email }],
  dynamicTemplateData: {
    first_name: user.firstName,
    order_id: user.orderId,
  },
}));

await sgMail.send({
  from: "noreply@yourdomain.com",
  templateId: "d-xxxxxxxxxxxxxxxxxxxx",
  personalizations, // Up to 1,000 recipients per request
});

Batching 1,000 recipients per request reduces API calls by 1,000x and keeps you well within the rate limit ceiling.

Deliverability Benchmarks

Platform	Avg Inbox Rate	Gmail	Outlook
SES (dedicated IP)	95–98%	96–99%	94–97%
SES (shared IP)	88–94%	89–95%	86–92%
SendGrid (dedicated IP, Pro)	95–98%	95–98%	93–97%
SendGrid (shared IP, Essentials)	85–93%	87–94%	84–91%

At peak configuration, both platforms deliver equivalent inbox rates. The difference is the operational cost of reaching that peak — SendGrid handles it for you, SES requires you to build it.

Authentication Setup That Actually Moves the Needle

SPF:   v=spf1 include:amazonses.com ~all          (SES)
       v=spf1 include:sendgrid.net ~all             (SendGrid)

DKIM:  2048-bit key recommended (both support it)
       Rotate every 6–12 months for high-volume senders

DMARC: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com
       Start with p=none → graduate to p=quarantine after 30 days of clean reports

Skipping DMARC costs roughly 3–8% inbox placement at major providers in 2026. It is no longer optional for serious senders.

AWS Will Suspend You at These Thresholds

Metric	Warning	Suspension
Bounce rate	5%	10%
Complaint rate	0.08%	0.10%

SendGrid surfaces these in a dashboard automatically. SES requires you to wire up CloudWatch alarms yourself:

// AWS CDK — bounce rate alarm
const bounceRateAlarm = new cloudwatch.Alarm(this, "SESBounceRateAlarm", {
  metric: new cloudwatch.Metric({
    namespace: "AWS/SES",
    metricName: "Reputation.BounceRate",
    statistic: "Average",
    period: cdk.Duration.hours(1),
  }),
  threshold: 0.05, // Alert at 5% — before the 10% suspension threshold
  evaluationPeriods: 1,
  comparisonOperator:
    cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
});

Bounce Handling: The Biggest Operational Difference

SendGrid handles this for you. Bounce happens → SendGrid catches it, logs it, suppresses the address, surfaces it in analytics. Zero engineering work.

Amazon SES requires you to build this:

Set up an SNS topic
Create a Configuration Set pointing to that SNS topic
Build and host a webhook endpoint that processes bounce events
Suppress bad addresses in your own database

If that SNS webhook goes down when SES fires a bounce event, SNS retries for up to 23 days — but your bounce rate keeps climbing during that window. That webhook deserves the same uptime monitoring as your production API.

Who Should Use Each?

Choose Amazon SES if:

You're already inside the AWS ecosystem (EC2, Lambda, RDS)
You're sending 500,000+ emails/month where the cost delta is significant
You have dedicated backend ownership to build bounce/complaint infrastructure
Email is a pure utility — receipts, alerts, verification codes — with no marketing component

Choose SendGrid if:

You need to ship fast without building email infrastructure from scratch
You need both transactional email and marketing campaigns in one platform
You're frontend-heavy or non-technical and don't own backend infrastructure
You're sending under 500,000 emails/month where the convenience premium is worth it

The Verdict

Amazon SES is the right choice when cost is the primary constraint and your engineering team has the bandwidth to build and operate email infrastructure inside AWS. At scale, the pricing difference is not marginal — it is substantial.

SendGrid is the right choice when speed of implementation, managed deliverability, and built-in analytics matter more than squeezing every cent out of sending cost. For most early-stage SaaS products, that trade-off is worth it.

Full comparison with additional benchmarks originally published on my blog → [https://www.devdecide.com/comparisons/amazon-ses-vs-sendgrid]

Pricing figures sourced from official AWS and SendGrid documentation. Last updated: March 2026.