Choosing an approach

There are four ways to send application email.

Four ways to send application email. Pick the row that describes you, not the one with the most checkmarks.

Wraps is one of the fourth kind, so the other three are written the way their own users would write them. If you have no AWS account and no intention of getting one, the second row is your answer and the rest of this page is not for you.

Run Amazon SES yourself

You, the AWS console, and a week

What it is good at: Cheapest by an order of magnitude — $0.10 per 1,000 emails à la carte, $0.16 on the Essentials plan new accounts default to. You own the account, the domain reputation, and the data. No third party sits in the send path, and there is nothing to migrate, ever.
What it costs you: Sandboxed by default, and production access is an AWS approval that can be refused. You own bounce and complaint handling, and AWS pauses accounts that get it wrong. There is no dashboard, no templates, no event pipeline, no suppression UI and no message search until you build them.

Pick this if: Your sending is simple enough that one SendEmail call covers it, and you would rather own a hundred lines than a dependency.

Rent a sending API

Resend, Postmark, SendGrid, Mailgun

What it is good at: Working in minutes, with no AWS account at all. Resend's developer experience is excellent and deserves its reputation. Deliverability is somebody else's job, and when mail goes missing there is a support desk to ask.
What it costs you: Markup that compounds with volume. A shared IP reputation pool you neither see nor control. Short log retention. Your sending history lives with them and leaves with them, and you keep no infrastructure when you go.

Pick this if: You have no AWS account and no appetite for one. Everything below this row assumes you are willing to hold an AWS account; if you are not, this is your row.

Rent a marketing or notification platform

Customer.io, Klaviyo, Braze, Knock

What it is good at: Campaigns, segmentation and lifecycle automation that a non-engineer can operate without filing a ticket. A mature, well-understood category with people who already know how to run it.
What it costs you: Contact-based pricing, so you pay for contacts who never open anything. Entry pricing before a single send. The heaviest lock-in of the four, and sending is bundled in, so you cannot keep the platform and change the sender.

Pick this if: Someone who is not an engineer owns email day to day, and the contact-based bill is worth not having to build campaign tooling.

Put an open-source wrapper over your own SES

Wraps, OpenSend, useSend, MillionSend

What it is good at: You keep everything the first row gives you — your AWS account, your domain reputation, your data, AWS's prices — and stop hand-building the parts that are identical for everybody. A dashboard, domain verification, templates, webhooks and an event pipeline, with source you can read, audit and fork if the vendor disappears. Most of this category is free or close to it.
What it costs you: You need an AWS account and someone willing to hold it, and production access is still an AWS approval nobody in this category can grant. Past that, the category varies enormously in how far beyond the API it goes, which is the whole decision once you are here.

Pick this if: You want the account, the reputation and the data to be yours, and you want the tooling to be open source. This is the row Wraps is in.

Inside the fourth approach

Every wrapper ships a send API. The difference is what happens after it.

Since the middle of 2026 several open-source projects have put a Resend-shaped API over your own SES and given it away. Good — an API is table stakes, and it settles an argument: if that were the hard part, it would not keep being rebuilt for free.

The hard part is the account underneath. Amazon can put an account under review once its bounce rate passes 5% and can pause sending at 10%; for complaints the lines are 0.1% and 0.5%. Once you have picked this approach, these are the questions to put to whichever wrapper you choose, ours included. The answers were read out of each project's own documentation in September 2026.

Ask any wrapper	OpenSend, useSend, MillionSend	Wraps
Does it watch the rates AWS suspends accounts over?	No	Bounce and complaint rates drawn against AWS's review and pause lines, swept hourly, owners and admins notified
Does it govern bounces and complaints, or only report them?	Emits a webhook	SES account-level suppression wired on for bounces and complaints from the first send
Does it audit deliverability, or only verify the domain?	Domain verification	DKIM, SPF, DMARC, MX and TLS, BIMI and public blacklist checks
What does it want from your AWS account?	AWS credentials, in a container you run	An IAM role you create and can revoke. No stored keys
Can it get you SES production access?	No	No. Nobody in this category can — it is an AWS decision made from your own account. We detect the sandbox and explain it, and that is the end of what anyone can do

Read the last row twice. Nobody in this category can get you production access, and a wrapper that implies otherwise is selling something it does not have.

Where we lose

What Wraps does not do.

The same list we would give you on a call, in the same order.

You need an AWS account. There is no version of this that works without one.
We cannot grant SES production access, and some requests are refused.
We are not SOC 2 certified, and there is no BAA.
Contacts, templates, workflows and per-message send records live in our database. Sending and the event history live in yours.
The SDKs are TypeScript and Python. That is the list.

One more thing worth knowing rather than discovering: the CLI and the SDKs are free, open source, and usable with no account here at all. If what you want is the deploy and the tooling, take that and nothing else — plenty of people run Wraps exactly that way.

Deploy it and look at the card Compare specific vendors