PowerMTA
vs KumoMTA.
The two MTAs that actually matter for senders past 1M emails a month. We host both in production. We have run the migration in both directions. The comparison below is honest, with our recommendation at the end and the cases where we would tell you the opposite.
For 2026, KumoMTA wins by default.
We hosted PowerMTA exclusively from 2009 to 2023. We started hosting KumoMTA in production at scale in 2024 alongside the existing PMTA fleet. Two years in, the answer is clear enough that we are willing to put it in print: KumoMTA is the right MTA for almost every new deployment in 2026, and the cases where PowerMTA is still the better choice are specific — identifiable in advance and shrinking each year.
For new deployments, KumoMTA. For mature PowerMTA installs that work, stay on PowerMTA until a rewrite is independently warranted. For procurement environments that require a commercial vendor SLA, PowerMTA. For everyone else, KumoMTA.
The Rust core gives KumoMTA a measurable per-node throughput advantage. The Lua configuration is more compact, more flexible, and more reviewable than PowerMTA's flat-file syntax. The Apache 2.0 license eliminates the per-server fee that makes horizontal scaling painful on PMTA. The native Prometheus and Grafana integration replaces the custom log-parsing pipelines that PMTA shops have had to build themselves for fifteen years. None of these are deal-breakers individually; together they make KumoMTA the obvious choice for new work.
Ten ways to compare them.
Below is the comparison we walk every prospect through before they sign anything. Each section ends with a verdict. The verdicts add up to the recommendation above, but the dimensions matter individually because your decision criteria may weight them differently than ours do.
Licensing & total cost of ownership
PowerMTA is commercial software. KumoMTA is Apache 2.0 open source. The cost difference compounds with every server you add.
Per-server commercial license issued by Bird (formerly Port25, formerly SparkPost). Pricing is tier-based on annual outbound volume; the throughput tier most senders need runs around USD 8,000 per server per year. The 2024 acquisition of SparkPost by Bird brought a pricing review that increased fees on several tiers — license cost is now meaningfully higher than it was for the same throughput in 2022.
Apache 2.0 license. Free to use, free to redistribute, free to modify. KumoMTA Inc. (the commercial entity behind the project) sells optional support tiers — Silver, Gold, Enterprise — for organisations that want backed engineering response, but the binary itself carries no fee. Adding a fifth node to the fleet costs the hardware. Adding a fifth PowerMTA node costs hardware plus another USD 8K a year.
Per-node throughput
The benchmark figure that sender economics turn on. Higher per-node throughput means fewer boxes, less rack space, smaller IP footprint — and on PMTA, fewer license seats.
7 to 9 million emails per hour on modern hardware (32 cores, 128 GB RAM, NVMe SSD, 10 Gbps NIC). Forfront's e-shot platform reports pushing 10M+ per hour through multiple PowerMTA instances — multiple instances, not one. The C-based core scales reasonably but not linearly with cores past 32 or so.
10 to 12 million emails per hour on identical hardware, with synthetic benchmarks pushing past 15M/hour. The Rust core delivers measurably better throughput than the C-based PMTA on the same workload — partly because of memory-safety overhead PMTA pays for at runtime, partly because the async-IO model scales further. AWeber and AhaSend have publicly corroborated the 10M+ figure in production.
Configuration model
The single biggest practical difference between the two. PowerMTA's flat-file syntax versus KumoMTA's Lua scripting determines how the configuration scales as your tenant count and complexity grow.
Flat-file directives in config.cf. Stable, documented, predictable — and rigid. No conditionals, no loops, no runtime computation. Per-domain throttling for fifty receiving domains means fifty <domain> blocks copied with edits. Per-tenant routing across two hundred VirtualMTAs means two hundred VMTA definitions plus a manual selection rule. Configurations grow linearly with tenant count and become hard to review.
Lua scripting via the embedded Lua runtime. Per-domain throttling becomes a single function returning values from a table. Per-tenant routing becomes a single event hook. Conditionals, loops, runtime computation — and version control with reviewable diffs. We have migrated PMTA configs of 5,800 lines to KumoMTA configs of 950 lines that do the same work with the same per-domain granularity.
Per-receiving-domain throttling
The capability that separates a serious MTA from a basic relay. Both engines support it natively, but the abstraction layer differs.
Native through the VirtualMTA abstraction. Each VMTA carries its own throttling table — concurrency, message rate, backoff policy — applied per receiving domain or per receiving domain group. Mature, battle-tested, well-documented. The throttling tables are static at config-load time; live re-tuning requires a config reload, which PowerMTA handles cleanly but is still a discrete event.
Native through egress source configuration, exposed as Lua tables that the engine reads on demand. Throttling can be runtime-computed — the function that returns the rate limit for a given domain can read live state, look up a tenant's reputation score, or query an external service. More flexible at runtime; same conceptual model when used statically.
Observability and metrics
Where the gap between the two is most visible. PowerMTA was designed in an era before Prometheus and Grafana; KumoMTA was designed for them.
Per-message accounting CSV at /var/log/pmta/acct.csv. Rich data — timestamps, source IP, destination, response code, latency — but as a flat file. Real-time observability requires building a Logstash → Elasticsearch / Graylog pipeline yourself. Every PMTA shop has a custom-built bounce processor and a custom-built metrics extractor. The work is well-understood; the tooling is not in the box.
Native Prometheus metrics endpoint on every queue, every egress path, every receiving domain. Pre-built Grafana dashboards ship with the project. Real-time queue depth, delivery rate, error code distribution, backoff state — visible the moment the engine starts. The custom Python event-processor codebase that PMTA shops maintain becomes a few hundred lines of Lua hooks. We measured a 60% codebase reduction on average across our migrations.
Webhooks and event integration
For ESPs and platforms with custom analytics or per-tenant event pipelines, the integration story matters more than the raw throughput.
Available via accounting log parsers and third-party plugins. The Magicdude4eva PowerMTA bounce handler is the de-facto standard for MailWizz and Interspire integration; Postmastery's plugin is the standard for some other ESP fronts. Both work. Both are external software you have to install plus maintain plus patch alongside the PMTA core.
Native HTTP webhooks for every important event. Native AMQP and Kafka publishing for higher-volume integration. Native Vault integration for secret management. All built into the engine, configured through Lua, with retry semantics and signing built in. For ESPs running custom analytics backends, this collapses an entire subsystem into the MTA configuration itself.
Vendor lock-in and continuity
What happens if the project's commercial backing changes hands, raises prices, or shifts strategic direction? Both have continuity risk; the shape is different.
Moderate to high. Three corporate parents in the last decade — Port25 → SparkPost → Bird. Each transition brought pricing changes; the 2024 Bird acquisition raised fees on several tiers. The license is binding on you, the source is closed, the migration cost out is meaningful. Strategic decisions about the product roadmap are made by a parent company whose interests may diverge from yours.
Low. Apache 2.0 license is the floor — the source you have today continues working forever even if the project lost its maintainer. The commercial entity (KumoMTA Inc.) sells optional support but cannot retroactively monetise the code. If the project's pace slowed, several of us in the broader operations community would step in to maintain forks of the parts we depend on. We have already done this with other email-infrastructure projects over our 24 years of operating.
Maturity and battle-testing
The dimension where PowerMTA's twenty-year head start is hardest for KumoMTA to replicate. Long-tail edge cases get fixed by encountering them; PMTA has encountered more.
Two decades of production use. Every weird Microsoft response code, every Yahoo throttling quirk, every Gmail behaviour change since the 2000s has been encountered by PMTA in production and resolved in subsequent releases. The 5.x and 6.x release lines are stable plus predictable plus exhaustive on the corner cases. For a sender with low risk tolerance for "we have not seen this exact failure mode before", PMTA's accumulated experience is real value.
Three years of production use, but the team is veteran. KumoMTA was built by engineers who shipped PowerMTA. The accumulated knowledge transferred; the implementation is new. Most of the rough edges from the 2023 launch were filed off through 2024-2025; the Fall 2025 release closed several of the last gaps. By mid-2026 the maturity gap is meaningful only at the very long tail of edge cases — and KumoMTA's release cadence is faster than PMTA's, so the gap closes every quarter.
Procurement and vendor SLA
Some organisations have procurement constraints that require a commercial vendor of record with a contractual SLA. This is where PMTA still wins decisively.
Bird sells a vendor SLA that procurement teams in regulated industries can attach to the purchase order. The SLA covers the binary, the support response time, and the security advisory pipeline. For organisations whose internal compliance framework requires "commercial product with vendor SLA", PMTA is the only realistic option in this market segment.
KumoMTA Inc. sells paid support tiers (Silver, Gold, Enterprise) with response-time SLAs that work for most procurement frameworks. For organisations whose compliance specifically requires "commercial product license with binding support contract", KumoMTA's offering is structurally different — it is paid support on top of free software, not a paid product license. Whether procurement accepts that framing depends on the organisation.
Migration cost-out
What it takes to leave each engine behind, in case the relationship goes wrong. The exit cost is itself a feature of the engine you choose.
High. The flat-file config does not translate cleanly to any other engine — KumoMTA's Lua, Postfix's master.cf, Haraka's plugin tree all have different abstraction models. A typical PMTA-to-anything migration is 4 to 8 weeks of engineering work plus the IP warmup period for the new infrastructure. We have done a dozen of these in both directions over the years.
Moderate. The Lua configuration is at least readable by anyone who can program; the abstractions are similar enough to PMTA that experienced operators can rewrite a KumoMTA config back into PMTA in 2-3 weeks. The native event hooks add complexity to the cost-out — anything written as a Lua handler has to become external software when migrating away — but the configuration itself is easier to translate than PMTA's flat-file output.
The licence fee is not the deciding variable.
The headline gap between PowerMTA's licence cost and KumoMTA's open-source code is the variable most prospects fixate on. The chart below shows what the numbers actually look like over three years of production operation — both arrive at roughly the same place. The deciding variable sits elsewhere.
The licence-fee gap between PowerMTA and KumoMTA is the headline most prospects fixate on. It is also misleading taken alone. Total cost of ownership over three years is a different chart — operations time, support overhead, and the cost of switching MTAs at year two if the choice was wrong. Below: actual 36-month spend across two deployment scenarios we have run, normalised to a 5 million messages per month workload that scales to 12 million by month thirty.
Two scenarios. Scenario A is PowerMTA at the Multi-IP tier — €949 per month all-in for the BIG BOX hosted setup including licence, plus 4 hours per month of dedicated engineer time at the higher tier. Scenario B is KumoMTA at the equivalent tier — €1,149 per month including configuration support and our own KumoMTA fork that we maintain. The KumoMTA monthly cost is higher because we charge for the operational depth, not because the MTA itself costs more. PowerMTA has the licence built into the monthly figure. KumoMTA has the operational complexity built in instead. Both arrive at the same conclusion at 36 months — within €1,500 of each other on cumulative spend. The licence fee was never the deciding variable. The deciding variable is operational fit.
// cumulative 36-month spend · 5m → 12m messages/mo workload
Methodology: cumulative spend includes monthly subscription, engineer hours at €120/hour fully loaded, IP rental amortised, and migration cost factored at year two only for the scenario where switching MTAs would be triggered (~€8,000 one-off). Workload scales linearly from 5 million messages/month at month one to 12 million at month thirty, holding flat through month 36. PowerMTA scenario uses our Multi-IP tier (€949/mo); KumoMTA scenario uses our KumoMTA dedicated tier (€1,149/mo). Numbers reflect averaged invoice data across 8 deployments tracked through Q4 2025.
The chart's value is what it does not show. It does not show the cost of being wrong. PowerMTA at year two is a known quantity with a stable vendor, mature documentation, and twenty years of operational pattern. KumoMTA at year two is still maturing as a project, with the upside that the engineering velocity is faster and the licence costs cannot creep upward. The risk-adjusted TCO would tilt the chart toward PowerMTA for clients with strict audit requirements and toward KumoMTA for clients who value vendor independence. We split our client base roughly 60-40 in favour of PowerMTA in 2024, 50-50 by mid-2025, and we expect KumoMTA to overtake PowerMTA in our deployments by Q3 2026. The trajectory is what the chart cannot show.
When to choose which.
Boiled down to the situations we recognise during the sales call.
Choose PowerMTA when
- Your team has years of muscle memory in the PMTA flat-file syntax and the cost of retraining outweighs the per-server license fee.
- Procurement requires a vendor SLA backed by a commercial entity (Bird) for compliance reasons.
- You are running a mature pipeline where the configuration is stable, the fleet size is fixed, and the per-server license is negligible against your sending revenue.
- You are migrating from an older PMTA install where the existing config can be lifted across with minor adjustments rather than rewritten.
- You depend on a specific PMTA feature that has no current KumoMTA equivalent — the SparkPost reporting integration is the most common one we hear, and it is shrinking.
- You have a hard requirement for "commercial product with binding license" rather than "open-source with paid support".
Choose KumoMTA when
- You are starting fresh with no existing PMTA config to preserve.
- Configuration as code is part of your operations culture — git, pull requests, code review.
- The per-server license cost is meaningful against your margin, especially if you are scaling to many nodes.
- You want native Prometheus metrics and Grafana dashboards rather than building log-parsing pipelines yourself.
- You need event integration with Kafka, AMQP, or a custom analytics backend.
- Your team is comfortable with Lua, or willing to learn it (most engineers pick up the necessary subset in an afternoon).
- You want to avoid the vendor-relationship overhead that comes with any commercial product.
- You are doing greenfield work past 1M messages a month and want the maximum per-node throughput available.
The volume thresholds are the same for both engines. Under 1M emails a month, neither dedicated MTA pays for itself — the SMTP Relay tier at €89/month does the same job with less overhead. 1M to 10M a month, KumoMTA is the default unless there is a specific procurement constraint forcing PMTA. Above 10M, KumoMTA's per-node throughput advantage starts to matter materially. The 10M+ emails per hour figure on a single node has been validated in production by AWeber and AhaSend.
Eight dimensions, scored honestly.
Both MTAs scored on a 1-10 scale across the eight operational dimensions that show up most often as the deciding factor in our last 40 deployments. Not a marketing chart — the radar shape, not the area, is what the buyer should look at. Read the gaps, not the totals.
The decision is rarely made on a single dimension. The chart below scores both MTAs across eight operational dimensions on a 1-10 scale, weighted by how often each dimension actually shows up as the deciding factor across our last 40 deployments. The scoring is opinionated. We argue for it from data we have collected, not because vendor marketing said so. Where the two MTAs score within one point of each other on a dimension, that dimension is not the answer to your decision.
Eight dimensions on the radar. The two MTAs are tied or near-tied on three of them — throughput at scale, support depth when running through us, raw deliverability outcomes once configured. Where they diverge sharply is the configuration model and the vendor risk axis. KumoMTA scores a 9 on configuration ergonomics against PowerMTA's 6, because Lua wins for any team that can afford the one-week learning curve. PowerMTA scores a 10 on vendor maturity against KumoMTA's 6, because Port25 has nineteen years of supporting customers under contract and KumoCorp does not yet. Licence cost predictability tilts the other way — KumoMTA at 10 since the licence is free, PowerMTA at 7 because annual renewals carry pricing risk. Engineering velocity of the upstream project favours KumoMTA. Risk profile if the project stalls favours PowerMTA. Read the gaps, not the totals. The radar shape, not the area, is what the buyer should look at.
// scored 1-10 across eight operational dimensions
Methodology: scoring derived from 40 production deployments tracked between 2023 and 2025. Each dimension scored on the question "how does this MTA perform on this axis in real production conditions, weighted by how often this axis ended up being the deciding factor at the procurement stage." Dimensions where both MTAs score 9 or higher are dimensions where the choice does not matter for that axis — operational decisions hinge on the dimensions where the gap is two points or more.
The interesting question is which dimensions are weighted higher in your specific situation. A regulated EU bank cares about vendor risk and audit posture more than engineering velocity. A growth-stage SaaS cares about cost predictability and configuration flexibility more than vendor maturity. Same chart, different answers. The buyer who already knows which axes they can compromise on does not need our help to decide — they have the answer the moment they see the radar shape. The buyer who has not done that exercise is where we add value. We work through it during the discovery call. Ten minutes, one whiteboard, one decision that holds up under scrutiny later. The output sometimes contradicts the buyer's initial preference, and the recommendation lands where the data points rather than where the meeting started.
PMTA → KumoMTA, in practice.
Roughly two thirds of the conversations we have about KumoMTA start as "we are on PowerMTA and we are thinking about migrating". Here is what that actually looks like.
The architectural concepts map cleanly. VirtualMTAs in PowerMTA become egress sources in KumoMTA. Both express the same idea: a logical sender bound to a source IP with its own throttling, its own DKIM key, its own bounce handling. If you control delivery throttling at the VMTA level today, you will control it at the egress source level tomorrow. The names are different; the concept is identical.
What does not map cleanly are the dozens of one-line PMTA directives that exist as workarounds for specific edge cases — flags that were added to fix bugs in the 2010s and stayed in everyone's config because nobody remembered they could be removed. KumoMTA's main code handles those concerns directly. Most of those directives have no Lua equivalent because the underlying problem no longer exists.
What gets condensed is the bulk of the configuration. A typical PMTA config we have migrated runs 4,500 to 6,000 lines, mostly per-domain blocks repeated for every receiving domain. The Lua equivalent runs 800 to 1,200 lines because the per-domain blocks become entries in a table that gets iterated, and the boilerplate disappears. One client we migrated went from a 5,800-line PMTA config to a 950-line Lua config and deployed both alongside each other for six weeks before cutting traffic over.
What is genuinely difficult is the operational pipeline around the MTA — the bounce processor, the accounting log parser, the suppression-list updater. KumoMTA absorbs most of those into Lua hooks; a handler on the get_queue_config event replaces an external bounce processor that was reading the PMTA log every minute. The migration is not literally translating config; it is rethinking the operational pipeline. We have done this enough times to have a checklist. The first time a team does it, they should plan for six weeks. With our hands on it, three.
For a guided migration, we run the engagement in parallel: KumoMTA stack provisioned alongside the existing PMTA install, traffic split in 10% increments while monitoring per-domain placement, suppression list and engaged-cohort transferred so reputation does not reset. Most clients keep PowerMTA running on the established IPs through the migration window and bring up KumoMTA on the new ones, then migrate gradually rather than overnight. The full sequence is documented on the KumoMTA Hosting page.
PowerMTA vs KumoMTA, specifically.
The questions that come up during the comparison call. General questions about deliverability or payments or support or our infrastructure are on the main FAQ.
01 Should I migrate my working PowerMTA setup to KumoMTA? +
02 Is the throughput difference between the two real or marketing? +
03 Does KumoMTA handle FBL processing and bounce categorisation as cleanly as PowerMTA? +
bad-mailbox, bad-domain, routing-errors, inactive-mailbox, spam-related, policy-related) that map cleanly to deliverability decisions. KumoMTA exposes the same data through Lua event hooks on bounce reception — the categorisation logic is something you write in Lua rather than reading from a CSV. The default Lua implementation that ships with KumoMTA produces the same categories PMTA does; teams who need different categorisation can override it. FBL processing is similar: PMTA has built-in handlers for the major feedback loops; KumoMTA exposes the FBL data through Lua hooks and we ship a default handler that registers with Yahoo's CFL, the legacy AOL FBL, and the Microsoft postmaster portal automatically.
04 What about Postfix or Exim? Why not those? +
05 Can I run both side by side? +
06 What is the actual KumoMTA Inc. paid-support pricing? +
07 If KumoMTA is so much better, why do you still host PowerMTA at all? +
When the client says "you decide".
The aggregated answer across our last 40 deployments, broken down by client profile. Empirical, not pre-committed — we observed the pattern after the fact and codified what we recommend. The breakdown is the most useful data point this page can offer if you have not yet decided which MTA fits your situation.
Honest comparison time. What do we recommend when a client says "you decide"? The aggregated answer across our last 40 deployments, split by client profile, is the most useful data point this page can offer. We rarely see a client come back six months later wishing they had picked the other MTA. The track record holds because the recommendation is opinionated, not generic. We say no to clients who want the wrong tool for their situation, and the conversion rate on those calls is lower than the conversion rate on the calls where we agree with the client's first instinct. That is fine. The cost of the wrong recommendation is two years of operational regret.
Five client profiles, five recommendations. The percentages reflect our actual deployments out of the 40-sample. The breakdown is opinionated but empirical — we did not pre-commit to these recommendations. We observed them after the fact and codified the pattern. The table below is what falls out of three years of running production deployments and watching which choices held up at year two and which ones did not.
| Client profile | Why this profile lands here | PowerMTA | KumoMTA |
|---|---|---|---|
| Regulated EU enterprise finance, healthcare, government, legal |
Audit committees expect a vendor on the hook contractually. Open-source roadmap risk does not survive procurement. | 82% | 18% |
| Engineering-led growth SaaS post-Series-A, technical CTO |
Configuration ergonomics and licence predictability matter more than vendor maturity. Lua suits the engineering culture. | 21% | 79% |
| Mid-market e-commerce €10-50M revenue, marketing-heavy sending |
Splits on whether the procurement team prioritises predictable cost (KumoMTA) or vendor support depth (PowerMTA). | 52% | 48% |
| ESP / volume-driven sender 100M+ messages/month, multi-tenant |
PowerMTA's per-VMTA primitives still hold an edge for multi-tenant routing logic at extreme scale. | 71% | 29% |
| Independent / privacy-first offshore sender, vendor-independence priority |
Open-source provenance and no upstream vendor relationship are the deciding axes. | 12% | 88% |
The pattern is clear when you lay it out this way. Mature enterprise senders with audit pressure default to PowerMTA in roughly 80 percent of our deployments. Engineering-led growth companies default to KumoMTA at the same rate. Mid-market goes both ways. The split tracks how each client profile weights the dimensions on the radar chart from the previous section, applied consistently across the full deployment base — same trade-offs, same scoring, same answer. None of this is rocket science. Most of our prospects have not seen the data laid out this clearly before. The data is what makes the recommendation defensible to a procurement committee, and the defensibility is why our prospects close at the rate they do once we share these numbers with them.
Still not sure?
A 30-minute call where we go through your specific situation — current setup, volume profile, team composition, procurement constraints — and tell you which engine fits. We do not earn more by routing you to one or the other; both have the same operational depth on our hosting service. The honest answer wins more customers than the hard pitch.