Compare · Email infrastructure

PowerMTA vs KumoMTA

Researched 2026-06-22 · perishable specs (price, throughput, release notes) verify with the vendor at time of purchase

Who should read this comparison?

If you already send enough mail to outgrow a tuned Postfix box — roughly half a million messages a day and climbing — and you are choosing the engine your sending platform will run on for years, this page is for you. Below that volume the honest answer is usually neither: Postfix handles most workloads, and reaching for a high-performance MTA early is over-engineering. The PowerMTA-versus-KumoMTA question becomes real when per-ISP throttling, IP pool management, multi-tenant queuing, and real-time deliverability signals start to matter more than raw simplicity.

Two readers in particular get value here. The first runs an ESP or agency platform and needs multi-tenant isolation with predictable support. The second is a large in-house sender weighing a recurring licence against an open-source stack they would operate themselves. Both are choosing infrastructure that is hard to swap later, so the decision deserves more than a feature grid.

It is worth being blunt about the floor. A great many teams shopping for PowerMTA or KumoMTA do not need either yet. Postfix, properly tuned, carries hundreds of thousands of messages a day, and the volume at which its queue management and per-ISP throttling start to strain is usually past a million a day, not below it. If your real number is 50,000 sends a week, the honest recommendation is to fix authentication and warm-up on a simpler stack first and revisit this page when growth forces the question. Buying a high-performance MTA to feel prepared is a common and expensive form of premature optimisation.

What each one actually is

PowerMTA has been the default answer for high-volume sending for about twenty years. It began at Port25, passed to SparkPost, and now sits under Bird. It runs on Linux and Windows, is configured through a directive file with more than 200 parameters, and ships with deliverability behaviour — bounce classification, per-ISP throttling, IP pool rotation — that works well without much invention. Nearly every major ESP has either used it or employs people who know it cold. Its architecture reflects the era it was born in: bare-metal servers, vertical scaling first, each instance configured and managed on its own.

KumoMTA is younger and built on different assumptions. It is open-source under Apache 2.0, written from scratch in Rust, and uses Lua as a config-as-code layer rather than a static file. It went public in 2023, created by Wez Furlong — who spent nearly a decade as Chief Architect at Message Systems designing the Momentum engine — and a group of email veterans now organised as KumoCorp. It is Linux-only and cloud-native, with native traffic shaping, per-tenant queuing, a feedback-loop processor, and built-in Prometheus and Grafana metrics. Messages persist to disk rather than living in RAM, which protects against crash loss and makes disk I/O part of the performance picture.

What does the side-by-side look like?

The table maps the factors that actually swing the decision. Wins land on both sides, because neither is the right answer for everyone.

Throughput and price are perishable: verify against current vendor docs and a live quote — verify price as of date.

Where PowerMTA is the safer pick

A one-sided page would skip this, so here it is plainly. PowerMTA still wins in real situations, and the reasons are not nostalgia.

The honest summary: PowerMTA is the lower-risk choice when predictability outranks cost, when your team already knows it, or when you need Windows. The price you pay for that is the licence and an architecture rooted in the bare-metal era.

Where KumoMTA pulls ahead

KumoMTA’s case rests on cost, performance, and control. The licence is free, which removes a recurring line item that can reach well into five figures a year. The Rust async engine posts higher throughput numbers, and the Lua layer turns configuration into real programmability — per-recipient logic, dynamic throttle adjustments, and routing decisions that would need external scripting elsewhere. Native traffic shaping ships with sensible per-ISP defaults, so a new operator does not start from a blank throttle table. Metrics are built in rather than bolted on, and there is no licence server to phone home or to switch your platform off remotely.

The catch is maturity and the learning curve. The ecosystem is younger, so there are fewer pre-existing answers, and the Lua configuration model is an upfront investment for a team without Lua experience. That trade favours organisations comfortable with DevOps practice and willing to own more of the stack.

The multi-tenant lens, for ESPs and agencies

If you are building a platform that sends on behalf of many customers, the comparison narrows to one question: how cleanly can the engine isolate tenants? Both handle it, but from different angles. PowerMTA has expressed multi-tenant sending through virtual MTAs and pool assignment for two decades, and the patterns are documented to the point of being folklore in the ESP world — when something breaks at 2 a.m., someone has written about it. KumoMTA approaches the same problem with per-tenant queues and Lua policy, which is more flexible: a tenant’s throttle, IP pool, and routing can be computed from live data rather than fixed in a file. The flexibility cuts both ways, because a tenant-isolation bug in a Lua policy is your bug to find, where PowerMTA’s equivalent is a known quantity with a known fix.

For an agency just starting out, PowerMTA’s well-worn path lowers the odds of an embarrassing cross-tenant leak. For a platform with engineering depth that expects to customise heavily, KumoMTA’s programmable isolation is the more expressive tool. Neither choice is wrong; they price risk and flexibility differently, and your tolerance for each should drive the call more than any throughput number.

How much faster is KumoMTA really?

The honest answer is “faster on paper, with caveats.” PowerMTA’s 1-to-3-million-per-hour figure is a benchmark proven across thousands of deployments; you know what to expect and how to tune for it. KumoMTA’s 4-to-6-million-per-hour guidance reflects a modern async design and Rust’s performance, with a further gain added in Spring 2025. But throughput depends on message size, recipient-domain mix, connection limits, and hardware, and KumoMTA’s disk-persistence model makes storage I/O a factor PowerMTA’s RAM-first design does not share in the same way. Treat both numbers as ceilings on good hardware, not promises for your exact workload.

The difference in configuration philosophy is easy to see. PowerMTA declares behaviour in a directive file; KumoMTA expresses it as Lua that runs at each lifecycle event:

# PowerMTA — declarative directive (static config file)
<domain gmail.com>
max-msg-per-connection 20
max-smtp-out 40
</domain>
# KumoMTA — config-as-code: a Lua hook evaluated at runtime
kumo.on(‘smtp_client_rewrite_delivery_status’, function(resp, domain)
if domain == ‘gmail.com’ then
return kumo.make_throttle(‘gmail’, ‘40/s’)  — dynamic, per-signal
end
end)

Illustrative syntax — consult current PowerMTA and KumoMTA documentation for exact directives and hook names.

Cost and licensing: the line that often decides

For many teams the budget settles it. KumoMTA is free under Apache 2.0, with optional paid support — no licence file, no annual renewal, no remote validation that could disable your platform. PowerMTA is licensed annually and the price scales with volume and instance count. Public figures vary so widely between sources that quoting one would mislead you; the right move is a current quote from Bird, weighed against the engineering time KumoMTA’s setup and Lua learning will cost. The comparison is not “free versus expensive” but “no licence, more in-house operations” versus “licence fee, more turnkey behaviour.”

Where MCSNET fits

Here is the part the marketing of either project will not tell you: most of the pain in running an MTA is operations, not licensing. Warm-up, authentication, per-ISP tuning, monitoring, and incident response decide deliverability far more than the badge on the engine. MCSNET hosts both PowerMTA and KumoMTA as managed dedicated servers in Toronto — licensing or installation, configuration, IP warming, reverse DNS and SPF/DKIM/DMARC alignment, and ongoing monitoring all handled. That changes the question. Instead of “which MTA can my team operate,” it becomes “which licensing model and config philosophy suits us,” with the operational burden lifted either way. The managed build is set out on the PowerMTA server hosting page, and KumoMTA is available on the same managed basis.

In practice the managed path looks the same regardless of engine. The server is provisioned in Toronto with reverse DNS set on the sending IPs, SPF, DKIM, and DMARC published and aligned, and the MTA configured to your volume and tenant model — directive file for PowerMTA, Lua policy for KumoMTA. New IPs are then warmed in stages over several weeks rather than opened at full volume, because a cold IP sending hard is the fastest route to the spam folder. From there the work is ongoing: reading bounce and complaint signals, adjusting per-ISP throttles, and watching reputation so a dip is caught before a campaign suffers. That is the same labour whichever engine sits underneath, which is precisely why hosting it managed makes the PowerMTA-versus-KumoMTA question a cleaner one — you are choosing a philosophy, not signing up to run a sending platform by hand.

Which should you pick?

If you genuinely cannot decide, that is a signal the engine is not your real constraint — operations are. In that case host either one managed and revisit the choice once you have production data of your own, rather than betting on a benchmark from someone else’s hardware. A useful rule of thumb: if the deciding factor on your shortlist is a recurring budget line, KumoMTA’s zero-licence model answers it; if it is the cost of an outage nobody on the team knows how to debug, PowerMTA’s two decades of documented answers earn their fee. Most teams already know which of those two fears is louder, and that instinct is a better guide than any throughput chart.

Common questions

Is KumoMTA a real replacement for PowerMTA?

For most high-volume senders, yes. It was built by the architect behind Momentum and covers PowerMTA’s core jobs: per-ISP throttling, IP pool management, bounce and feedback-loop handling, and high throughput. The gaps are ecosystem age and the Lua learning curve, not missing capability.

Which is faster, PowerMTA or KumoMTA?

On paper KumoMTA. PowerMTA delivers roughly 1 to 3 million messages per hour on a well-configured server; KumoMTA’s guidance is about 4 to 6 million per hour per node, with a further gain in its Spring 2025 release. Real throughput depends on message size, recipient mix, and tuning.

How much does PowerMTA cost versus KumoMTA?

KumoMTA is free under Apache 2.0, with optional paid support. PowerMTA is commercial, licensed annually, and the price scales with volume and instance count. Request a current quote from Bird rather than budgeting from a public estimate.

Does KumoMTA run on Windows?

No. KumoMTA is Linux-only and cloud-native by design. PowerMTA runs on both Linux and Windows, which matters if your operations are tied to a Windows environment.

Can MCSNET host PowerMTA and KumoMTA for me?

Yes. MCSNET runs both as managed dedicated servers in Toronto — licensing or installation, configuration, IP warm-up, authentication, and deliverability monitoring included.