Use SES directly when you will build the rest; use a layer when you will not.
Amazon SES is a sending engine with a per-thousand price and no product around it. Everything a team ends up needing, from a searchable message log to a suppression list to delivery webhooks, is yours to build, host and keep running. A service on top of SES sells that layer. Choose SES when you will build the layer anyway and it will earn its keep; choose the layer when your engineers have something better to do than run an email pipeline.
What Amazon SES gives you.
SES is the sending layer. You get an HTTPS API and an SMTP interface, each of which hands a message to Amazon’s infrastructure for delivery. Pricing is per volume: the SES pricing page lists $0.10 per 1,000 outbound emails à la carte, $0.16 per 1,000 on the Essentials plan, and $0.12 per gigabyte of attachment data, with $200 in AWS Free Tier credits for new accounts over their first six months. There is no monthly plan to outgrow and no included allowance to compare against.
A new account starts in a sandbox, where you can send only to addresses you have verified and only in small volumes. Sending to the public means requesting production access: a form describing your use case and how you will handle bounces and complaints, which AWS reviews and can decline.
Delivery, bounce and complaint events are published to SNS destinations that you configure, and SES keeps an account-level suppression list for hard bounces and complaints. Both are real features; both are raw material rather than finished tools.
What you build yourself.
The gap between “SES sends the email” and “our product sends email” is a list of things that feel small individually and take a quarter together:
- A message log you can search. SES does not store your sent mail. Support asks “did the receipt for order 4471 go out?” and the answer has to come from your own database of every send and every event.
- Webhooks. SNS delivers events to a topic; turning them into signed, retried webhooks your app can subscribe to is a queue, a worker and a signing scheme you write and run.
- Templates. SES has a template API, but the editor, versioning and a preview that matches what a mail client renders are yours.
- Suppression across products. The SES list covers hard bounces and complaints for one account. An unsubscribe from a marketing campaign, an address a support agent removed by hand, or a list shared between two products needs your own table and your own check before every send.
- Domain onboarding. SPF, DKIM and DMARC records have to be generated, shown to the customer, checked and re-checked. SES verifies the domain; the guided setup is yours.
- Bounce and complaint handling, retries and idempotency. Every one of these is a policy you decide and code you maintain, and the mistakes (a double-sent invoice, a complaint that kept sending) are visible to customers.
What “a service on top of SES” means.
Many email APIs are widely reported to run on SES, and Resend is the one most often cited, but resend.com does not confirm it; treat the claim as reported, not established. The point stands regardless of who runs on what: a service on top of a sending engine is charging you for the layer described above, packaged as an API, a dashboard and a set of SDKs, with the engine’s deliverability underneath. You are not paying a markup on transport so much as paying for the product you would otherwise build.
That also sets the limits of the arrangement. The layer cannot give you more control than the engine allows, and you inherit the layer’s choices about what is exposed. If you need raw access to every SES option, use SES.
The cost comparison, honestly.
Per email, SES is cheaper by a wide margin: 50,000 messages at $0.10 per 1,000 is $5, before attachments. A $15 to $20 plan buys the same volume with the product around it. The crossover is not in the per-email price; it is in engineering time. A week of one engineer building the log, the event pipeline and the suppression checks costs more than years of the difference between $5 and $15 a month, and the maintenance never ends.
So the arithmetic is: multiply your volume by the per-thousand rate, compare it with the plan price, and then add what you will spend building and running the missing layer. For teams under a few million emails a month the second term dominates.
When each is the right choice.
Use SES directly when you already operate on AWS, you send at a volume where the per-email difference is real money, you need options a layer does not expose, or you have a platform team that will own the pipeline as a product.
Use a service on top when the mail is a means rather than the product, when one shared suppression list across transactional and marketing mail matters, when you want webhooks and a searchable log on day one, or when nobody wants to be on call for an email pipeline.
The same send, with and without the layer.
Both calls deliver one email. The difference is what surrounds the call: with SES, the events, the log and the suppression check are yours to wire up; with a layer, they are already there.
import { SESv2Client, SendEmailCommand } from "@aws-sdk/client-sesv2";
const ses = new SESv2Client({ region: "eu-west-1" });
await ses.send(
new SendEmailCommand({
FromEmailAddress: "receipts@acme.com",
Destination: { ToAddresses: ["customer@example.com"] },
Content: {
Simple: {
Subject: { Data: "Your receipt" },
Body: { Html: { Data: "<p>Thanks for your order.</p>" } },
},
},
// Delivery, bounce and complaint events go to an SNS topic you
// create and subscribe to yourself; suppression is per account.
}),
);
import { Notix } from "notix-js";
const notix = new Notix(process.env.NOTIX_API_KEY);
const { data, error } = await notix.emails.send({
from: "receipts@acme.com",
to: "customer@example.com",
subject: "Your receipt",
html: "<p>Thanks for your order.</p>",
});
// Suppression, delivery webhooks, the message log and the
// domain checks are already in place around this call.
How Notix handles it.
Notix is the layer, built as one product rather than a set of parts. Every send through the transactional email API or the SMTP relay lands in a searchable log, publishes signed webhooks for email, contact and domain events, and is checked against one suppression list shared by transactional and marketing mail. Domain onboarding walks a customer through SPF, DKIM and DMARC and re-checks them. Templates, a deliverability pre-check API and an OTP API sit in the same account.
The free plan gives 5,000 emails a month and 200 a day with no card; Pro is $15 a month for 50,000 emails. If you are weighing SES against this specifically, the Amazon SES alternative page puts the two side by side with SES’s own numbers and the date they were read.
Questions people ask before choosing.
Is Resend built on Amazon SES?
What is the Amazon SES sandbox, and how do I leave it?
Is Amazon SES cheaper than an email API?
Can I use SES for transactional email and a service for marketing?
Keep reading.
Amazon SES alternative
SES plus the dashboard, suppression, webhooks, templates and domain onboarding you would otherwise build yourself.
ProductTransactional email API
OTPs, receipts and alerts with idempotency keys, a deliverability pre-check and a shared suppression list.
LearnCheck an email's deliverability before you send it
What a pre-send deliverability check looks at, the verdict and score it returns, and the four findings that block a send.
Use casesOTP email
Send one-time codes by email or SMS with two API calls, with expiry, length and risk scoring handled for you.
NotixDocs
The quickstart: verify a domain, copy an API key, send the first email.
Read the docs before you decide.
The quickstart shows the API, the SMTP relay and the webhooks in one sitting, so you can see exactly what the layer contains.