SES is the cheapest way to move mail and the most work to build on. MCPmailer runs on SES, so this page is about the layer between.
Transactional email APIs · Amazon SES claims checked July 2026
Amazon SES is raw email infrastructure at commodity prices: send and receive, configuration sets, dedicated IP pools, and event streams into SNS. Almost every provider on this page, us included, is built on something like it.
If you have platform engineers, real volume, and time, SES directly will always be cheaper per message than any layer above it, and at scale that gap is worth building for. If your data cannot leave your own AWS account, it is the only honest answer.
We run on SES, so this comparison is unusually concrete: you are deciding whether to build the part between SES and a working agent. Receipt rules into S3 and SNS, a queue consumer, MIME parsing, thread linkage, per-tenant configuration sets, tripwires far below the thresholds that get accounts suspended, a suppression list enforced pre-send, and MCP on top.
SES suspends at roughly 0.1% complaints or 5% bounces, account-wide. One careless sender on your account is everyone on your account. We run a configuration set per tenant, isolate senders into pools by trust tier, and auto-throttle at 2% bounces and pause at 4%, which is well below the line. That machinery is most of the value and none of the demo.
A new SES account starts in sandbox and can only mail verified addresses until you argue your way out, then you warm the sending domain yourself. Agent addresses here send on day one, on a pool that is already warm, with quotas that ramp as your record stays clean.
SES has no notion of a mailbox, a thread, unread state, search, an agent identity, a scoped key, a reply-first quota, or a dashboard. Each is a week you do not get back, and the last one is the week nobody budgets for.
Every row is a claim we could defend with their documentation open beside it. Where they are ahead, the row says so.
If you go this way, these are the parts that bite, in the order they bite. We publish them because a customer who builds it and comes back knows exactly what they are buying.
Receiving is the easy half
Receipt rule to S3 plus SNS, a queue consumer, and a MIME parser. Two weeks, and it mostly works.
Threading is worse than it looks
In-Reply-To and References, clients that rewrite both, subject-based fallbacks, and mail with neither.
Reputation is the real project
Per-tenant metrics, suppression enforced before send, bounce and complaint tripwires, velocity limits, and someone on call when they fire.
Then the boring surfaces
Search, retention, per-agent keys, an oversight UI, and an MCP server you keep current with the spec.
The send path is an afternoon and receiving is a fortnight. The bounce and complaint tripwires, per-tenant isolation, threading edge cases, and the operational habit of keeping a sending reputation clean are the multi-month part, and you only appreciate them the first week they nearly cost you the account.
Yes, in both directions, with the application, MCP server, and queues on Cloudflare. We would rather say so than pretend the wire is proprietary.
Per message, always. Once you price the engineering time and the risk of an account-wide suspension, the crossover is much further out than it first looks.
Dedicated IPs are available as an add-on on higher plans. Bring-your-own-account is an enterprise conversation.
Keep your transactional sender for the mail your product sends. This is for the addresses your agents converse from, which is a different job with different failure modes.
The free tier is 3,000 emails a month across three agent inboxes, no card, with receiving, threading, and search included. Enough to watch a real conversation happen before you decide.
More Transactional email APIs