Compare · Email infrastructure
KumoMTA vs Amazon SES
This is a self-hosted-versus-cloud decision, not a like-for-like one. Amazon SES is a pay-as-you-go cloud service at about $0.10 per 1,000 emails with no servers to run — the cheapest, simplest option at low to mid volume. KumoMTA is an open-source MTA you host yourself, where you own the IPs, the reputation, and the throttling, with no per-message fee but real operational work. Pick SES for a fast, cheap start with minimal ops; pick a self-hosted KumoMTA when you need to own your reputation, escape per-recipient pricing at scale, or keep data in a specific country. MCSNET runs KumoMTA managed from Toronto, which gives the self-hosted control without the servers becoming your problem.
- SES pricing is ~$0.10 per 1,000 emails, billed per recipient, no monthly fee — cheapest at low to mid volume.
- KumoMTA is free (Apache 2.0), self-hosted, with no per-message fee; its cost is the server plus the operations.
- Reputation: SES uses AWS-managed shared pools or rented dedicated IPs ($24.95/IP/mo); with KumoMTA you own your IPs outright.
- Deliverability help: SES gives you none when mail lands in spam; a managed KumoMTA includes a human.
- Residency: KumoMTA runs where you put it — MCSNET hosts it in Toronto under PIPEDA, away from AWS’s US-centric posture.
Who should read this comparison?
If you are choosing between renting AWS’s sending infrastructure and running your own, this page is for you. The honest framing matters because the two are not direct substitutes: SES is a metered cloud service, KumoMTA is software you operate. The right answer turns less on features than on volume, control, and who you want responsible when deliverability slips.
Three readers get the most from it. The first is a startup or SaaS sending transactional mail who wants the cheapest credible option with no servers — SES is built for them. The second is a scaling sender watching per-recipient charges add up and wondering whether owning the stack would cost less. The third is an organisation with a residency or control requirement that a US-based cloud service cannot satisfy on its terms. The further down that list you are, the stronger the self-hosted case becomes.
One caution before the detail: do not let a comparison like this talk you into complexity you do not need. The most common mistake in this decision is reaching for a self-hosted MTA out of a wish to feel in control, when the actual sending volume would run happily and cheaply on SES for years. Self-hosting earns its keep when a real constraint — cost at scale, reputation ownership, residency, or content control — forces the question. If none of those bite yet, the cloud service is the disciplined choice, and you can revisit this page when one of them does.
What each one actually is
Amazon SES is AWS’s cloud email-sending service, opened to the public in 2011. You send through an API or SMTP, AWS runs the infrastructure, and you pay per email — about $0.10 per 1,000, charged per recipient, with no monthly minimum. Shared IP pools come free with AWS-managed reputation; dedicated IPs are rentable at a flat monthly rate. It integrates deeply with the rest of AWS — IAM, CloudWatch, SNS, Lambda, S3 — which is a real advantage if you already live there. What it is not is a complete platform: there is no campaign builder, no suppression-list UI, and crucially no deliverability team when your mail starts landing in spam.
Two SES details catch new senders out. The first is that billing is per recipient, not per message — one email to a hundred people is a hundred billable sends, which changes the maths for any one-to-many program. The second is that every new account starts in a sandbox that can only send to verified addresses; you request production access and wait one to three business days for AWS to grant it. Neither is a flaw, but both belong in the plan before you commit.
KumoMTA is an open-source mail transfer agent under Apache 2.0, written in Rust with Lua scripting, built by veterans who previously designed commercial MTAs. You install it on your own servers, configure throttling and routing, and own the sending IPs and their reputation end to end. There is no per-message fee — the cost is the hardware and the operational effort. It is designed for high-volume, multi-tenant sending and modern observability, but it expects an operator who is comfortable with DevOps practice, or a host who provides one.
The operational effort is the honest catch, and it is worth naming. A self-hosted MTA is not “set it and forget it.” Someone provisions the server, configures the engine, publishes and aligns authentication records, warms the IPs over weeks, then watches bounce and complaint signals and adjusts per-ISP throttling as mailbox providers react. That work is continuous, not a one-time setup. It is the same work SES partly absorbs through its shared-pool reputation management — and the reason the self-hosted decision is really a decision about who does that work, you or a host, rather than whether it gets done at all.
What does the side-by-side look like?
The table sets the metered-cloud model against the self-hosted one. Wins land on both sides, because the better choice depends entirely on your volume and your need for control.
| Factor | KumoMTA (self-hosted) | Amazon SES (cloud) |
|---|---|---|
| Pricing model | Fixed server cost, no per-email fee | ~$0.10/1,000, per recipient |
| Cost at low volume | Server overhead dominates | Often near-free |
| Cost at very high volume | Marginal cost ~ zero | Per-recipient adds up |
| Ops burden | You run it (or a host does) | None — AWS runs it |
| IP reputation | You own it fully | Shared pool or rented dedicated IP |
| Control (throttle/route/content) | Total, Lua-scriptable | Within AWS policy + limits |
| Deliverability help | Yours, or your host’s | None from SES |
| Data residency | Wherever you host (e.g. Toronto) | AWS region, US-centric posture |
| Time to first send | Server + warm-up | Fast after sandbox exit |
| Lock-in | None — your software, your IPs | AWS account + ecosystem |
Prices and limits are perishable: confirm against the live AWS SES pricing page and your own server costs — verify price as of date.
Where Amazon SES is the better choice
A page selling self-hosting would skip this. It should not, because SES is the right pick for a large share of senders, and the reasons are concrete.
At low to mid volume it is the cheapest credible option in the market — sending 100,000 emails costs roughly ten dollars, and there are no servers to patch, scale, or monitor. The base rate has held at $0.10 per 1,000 since 2011, so it is predictable. If you already run on AWS, the IAM, CloudWatch, SNS, and Lambda integration removes real plumbing. For a team without deliverability or DevOps depth, SES turns email into a line item instead of a project, and that simplicity has genuine value.
The honest version: if your volume is modest, your team is small, and you are already in the AWS ecosystem, SES is hard to beat and a self-hosted MTA is over-engineering. Multiple independent cost breakdowns reach the same conclusion — below roughly half a million emails a month, the engineering hours of self-hosting usually outweigh the per-email savings.
Where a self-hosted KumoMTA pulls ahead
The case for KumoMTA strengthens as three pressures grow: volume, control, and residency.
On volume, SES bills per recipient, so a one-to-many send multiplies. A million recipients is about a hundred dollars before add-ons; ten million is a thousand-plus, every month, forever. A self-hosted KumoMTA on a fixed-cost server has a marginal cost close to zero per additional message, so above some crossover the economics invert. Where that crossover sits depends on your hardware and send pattern, which is exactly why it should be modelled, not assumed.
On control, you own the IPs and their reputation outright rather than sharing AWS-managed pools or renting dedicated addresses. Lua scripting gives per-recipient routing and dynamic throttling that a metered API does not expose. There is no AWS content policy, no sending limit set by someone else, and no risk of an account action switching your platform off.
On residency, KumoMTA runs wherever you put it. For a Canadian organisation that needs data in-country and away from US legal reach, that is decisive — and it is the gap SES cannot close, because SES is AWS.
Lock-in, exit, and who controls the off switch
There is a quieter difference that only surfaces when something goes wrong. On SES your ability to send sits inside an AWS account, governed by AWS terms, sending limits, and content policy. That is fine until it is not: a flagged account, a policy change, or a billing dispute can throttle or pause sending, and the appeal process is AWS’s, not yours. The shared-IP model adds a second dependency — your deliverability is affected by other senders in the same pool, whose behaviour you do not control. AWS manages that pool’s reputation well, but it is still a reputation you rent rather than own.
A self-hosted KumoMTA inverts that relationship. The software is yours under an open licence, the IPs are yours, and there is no licence server or account that a third party can switch off. If you decide to move hosts, you take your configuration and your warmed IPs with you. That portability is worth little on a calm day and a great deal on a bad one, and it is the kind of risk that rarely shows up in a feature comparison until it is the only thing that matters. SES does offer Bring Your Own IP for senders who want to keep their address space, but the entry point is steep — a 256-address minimum — which puts true IP ownership on AWS out of reach for most.
What does the cost actually look like at scale?
The headline rate hides the shape of the curve. SES is linear: double the recipients, roughly double the bill, indefinitely. A fixed-cost MTA is flat: the server costs the same whether it sends two million or twenty million in a month, until you add a node. The illustration below sketches the crossover — the numbers are placeholders to show the shape, not a quote.
# SES: linear, per recipient (~$0.10 / 1,000) — verify on AWS pricing page 1M /mo -> ~$100 + IPs/VDM/data transfer 5M /mo -> ~$500 + add-ons 20M /mo -> ~$2,000 + add-ons # scales forever, every month # Self-hosted KumoMTA: flat server cost, no per-message fee 1M /mo -> server $ # overhead dominates at low volume 5M /mo -> server $ 20M /mo -> server $ # marginal cost ~ 0 -> this is where it wins
Figures are illustrative placeholders for the cost shape, not a quote — model your own volume and verify current SES rates.
Where MCSNET fits
The usual objection to self-hosting is the one SES exploits: who wants to run mail servers? That objection is what MCSNET removes. It hosts KumoMTA as a managed dedicated server in Toronto — installation, configuration, IP warming, reverse DNS and SPF/DKIM/DMARC alignment, and ongoing deliverability monitoring all handled. You get the no-servers-to-run feeling that pulls people toward SES, but you keep what self-hosting gives: your own IP reputation, no per-recipient meter, full control of throttling and routing, and data in Canada under PIPEDA rather than in a US-governed cloud. And when mail lands in spam, there is a human who already knows your setup — the exact thing SES tells you, plainly, it does not provide. The managed build is on the PowerMTA server hosting page, with KumoMTA offered on the same basis.
Framed against SES directly, the managed-KumoMTA pitch is narrow and honest. It does not beat SES on price at low volume — nothing does — and it does not pretend to. What it offers is the thing SES structurally cannot: an engine you own rather than rent, a reputation tied to your IPs alone, a per-message cost that stops climbing as you grow, data that stays in Canada, and a named engineer instead of a documentation page when deliverability slips. For a sender who has outgrown the cloud-relay model or who carries a residency requirement, that combination is the point. For one who has not, SES remains the right answer, and an honest comparison says so rather than arguing past it.
Which should you pick?
Cheap, low-ops start
Modest volume, a small team, and you want email to be a line item, not a project. SES’s per-email price and zero-ops model win clearly here.
Already deep in AWS
Your stack lives on AWS and you want IAM, CloudWatch, SNS, and Lambda integration without extra plumbing. SES is the path of least resistance.
Own your reputation at scale
High volume where per-recipient pricing stings, and you want to own your IPs and reputation outright with no metered ceiling. Self-hosting inverts the economics.
Control + Canadian residency
You need full control of routing and content, or data kept in Canada under PIPEDA, plus a human on deliverability. Managed KumoMTA in Toronto fits.
A practical way to decide: plot your next-two-years volume against your tolerance for operations. If the volume stays modest or the team has no appetite to own infrastructure, SES is the rational choice and self-hosting is a distraction. If volume is climbing past a few million a month, or ownership and residency are real requirements, the self-hosted side wins — and hosting it managed removes the only serious objection to it. The worst outcome is choosing on brand familiarity rather than on your own numbers, so run the volume-and-residency test first and let the result, not the marketing, settle it.
Common questions
Is KumoMTA cheaper than Amazon SES?
It depends on volume. SES at about $0.10 per 1,000 recipients with no servers is unbeatable at low to mid volume. A self-hosted KumoMTA has a fixed server cost and no per-message fee, so its effective cost per email falls as volume rises. Very high-volume senders often pay less self-hosted; smaller senders usually pay less on SES.
Why self-host KumoMTA instead of using SES?
Ownership, control, and residency. You own your sending IPs and reputation rather than sharing AWS pools or renting dedicated IPs; you control throttling, routing, and content without AWS policy or suspension risk; and you choose where the servers sit, which matters for Canadian residency. The trade is running the infrastructure, unless someone runs it for you.
Does Amazon SES help with deliverability?
Not directly. SES is infrastructure, not a managed service. AWS manages shared-pool reputation, but when your mail lands in spam there is no SES deliverability team to call. A managed KumoMTA includes that human help.
How fast can I start sending on each?
SES is fast once you exit the sandbox — new accounts are restricted and you request production access, granted in one to three business days. A self-hosted KumoMTA needs a server, configuration, and IP warm-up over several weeks, the same warm-up SES dedicated IPs also require.
Can MCSNET run KumoMTA so I get SES-like convenience?
Yes. MCSNET hosts KumoMTA managed in Toronto — installation, configuration, IP warm-up, authentication, and deliverability monitoring included — so you get the no-servers convenience of SES while owning your reputation, avoiding per-recipient fees, and keeping data in Canada.
Related cloud-versus-self-hosted match-ups: PowerMTA vs SendGrid · KumoMTA vs SendGrid · PowerMTA vs Mailgun.
Go to the managed product: PowerMTA / KumoMTA server hosting · glossary: IP warming.