KumoMTA & Migration
The right MTA is the one that fits, not the one with the best pitch.
MTA selection is choosing the mail transfer agent that fits your volume, budget, team and goals — PowerMTA, KumoMTA, Postfix, Halon, MailerQ or another — before you commit infrastructure and reputation to it. Most senders over-engineer this decision; the right answer is usually simpler than the marketing suggests, and occasionally the opposite of what a vendor would tell you.
MTA selection is choosing the mail transfer agent that fits your volume, budget, team and goals — PowerMTA, KumoMTA, Postfix, Halon, MailerQ or another — before committing infrastructure and reputation to it. The single biggest determinant is volume: below roughly ten million messages a month a tuned Postfix usually suffices, while the high-volume engines earn their complexity only above that. KumoMTA is the first thing to evaluate before paying for a commercial licence, and the honest first question is often not which MTA, but whether you need a self-hosted one at all instead of an ESP.
In short
- → Volume is the single biggest determinant: below roughly 10 million messages a month, a tuned Postfix usually suffices; the high-volume engines earn their complexity only above that.
- → KumoMTA — free under Apache 2.0, modern Rust, configured as Lua — is the first thing to evaluate before paying for a commercial licence like PowerMTA at around 8,000 US dollars a year.
- → The honest first question is not which MTA but whether you need a self-hosted one at all; for many senders an ESP like Amazon SES or SendGrid is genuinely enough.
- → The best engine for a team that cannot operate it is the wrong engine — team skill and support model matter as much as raw throughput.
- → Reputation lives on your IPs and domains, not the software, so the choice is reversible through a careful migration rather than permanent lock-in.
Choosing a mail transfer agent feels like a high-stakes technical decision, and it is, but not in the way most comparisons frame it. The feature matrices that pit one engine against another tend to obscure the only question that matters: what actually fits your volume, your budget, your team and the way you want to operate. An engine can be objectively excellent and still be the wrong choice for you, because the best MTA for a team that cannot run it, or cannot justify its cost, is no MTA at all.
This guide is independent in a specific sense: we set up and operate two of these engines and resell none of them, so the recommendation that follows is shaped by fit rather than by a license margin. The honest landscape in 2026 narrows quickly once the conversation moves from comparing features to comparing operational fit, and it narrows in a direction that surprises people \u2014 usually toward something simpler and cheaper than they expected to need.
Start by not over-engineering
The most common mistake in MTA selection is reaching for an enterprise engine before the volume justifies it. There is a strong pull toward the powerful option \u2014 it feels safer, more serious, more future-proof \u2014 and for most senders it is simply wasted complexity and cost. The practitioners who do this for a living are blunt about it: the overwhelming majority of senders are served completely by Postfix, the free default on nearly every Linux system, and the volume at which Postfix’s limitations actually start to bite sits somewhere around ten million messages a month, which is far beyond what most businesses ever reach.
So the first question is not which high-volume engine, but whether you need one at all. Buying PowerMTA’s license, or taking on KumoMTA’s operational learning curve, to send volumes a tuned Postfix would handle without complaint is paying for power you will never use. The engines below earn their complexity at genuine scale; beneath that scale, the right answer is usually the boring one. We would rather tell you that up front than sell you an estate you did not need.
Do you even need a self-hosted MTA, or is an ESP enough?
Before choosing among these engines, there is a prior fork that decides whether you should be looking at them at all: do you want to own your sending infrastructure or rent it? Renting means a managed service — Amazon SES, SendGrid, a full ESP — where someone else runs the MTA and you pay per message for the convenience of never touching it. Owning means a self-hosted engine on your own IPs, where you hold the reputation and the control and carry the operational weight. Every engine on this page is an owning choice.
Renting is the right answer more often than infrastructure people like to admit. If your volume is modest, if per-message pricing is not yet painful, and if you would rather your team build product than operate mail servers, a managed service is simply more sensible, and we will say so. Owning earns its place when per-message pricing starts to hurt at your volume, when you need control a managed service will not give you, or when owning the reputation outright is itself the goal — a strategic asset rather than a rented one. The mistake is choosing an engine because self-hosting sounds more serious, when renting would have served you better and cheaper. Settle the own-versus-rent question honestly first; the choice of engine only matters once the answer is own.
# Count messages actually accepted for delivery over the last 30 days
# (Postfix mail log — adjust the path for your current MTA)
$ journalctl -u postfix --since "30 days ago" | grep -c "status=sent"
7421043
# ~7.4M / month sits under the ~10M Postfix-vs-high-volume line.
# A tuned Postfix is likely the right answer; KumoMTA only if real growth is coming.
$ echo $(( 7421043 / 30 )) "per day average"
247368 per day averageWhat factors actually decide which MTA to choose?
When volume does justify a serious engine, the choice turns on a handful of factors that have nothing to do with feature checklists. These are the ones that decide whether an engine fits, and the order they matter in shifts with your situation.
| Factor | Why it decides the choice |
|---|---|
| Volume | The single biggest determinant. Below roughly ten million a month, a tuned Postfix usually suffices; the high-volume engines earn their complexity only above that. |
| Budget and license model | Free open source, an annual commercial license, or per-message ESP pricing are three different economics. Free software still costs operational time; per-message pricing punishes growth. |
| Team skill | A static config file, configuration as code in Lua, or a full scripting language each demand a different kind of engineer. The best engine for a team that cannot operate it is the wrong engine. |
| Cloud-native needs | If you run containers, Kubernetes and a Prometheus/Grafana stack, an engine built for that integrates cleanly; a traditional one needs bridging work. |
| Support model | A commercial license can come with a support contract and an SLA; open source comes with a community and whoever you pay to operate it. Neither is wrong, but they are different bets. |
| Marketing features | Some engines bundle list management and campaign tooling; others are pure infrastructure and assume your application layer handles that. Buying bundled features you will not use is its own cost. |
The engines, honestly
Here is the production landscape as it actually stands in 2026: the licence model, the volume where each engine fits, and what each is genuinely good at rather than what its marketing claims. Sendmail and Exim are included for completeness, though neither is usually the right pick for a new high-volume build.
| Engine | License | Volume fit | Genuinely good at |
|---|---|---|---|
| Postfix | Free (open source) | Up to ~10M / month | The default on most Linux systems and the right answer for the large majority of senders. Security-focused and reliable; marketing-scale per-recipient throttling needs custom configuration work that newer engines do natively. |
| KumoMTA | Free (Apache-2.0) | ~500K–5M / day | A modern Rust engine by the architect of Momentum, configured as code in Lua, cloud-native, with native throttling and traffic shaping. The first thing to evaluate before paying for a commercial license. |
| PowerMTA | Commercial (from ~$8K/yr) | High-volume ESP | Two decades of proven IP-pool management, per-ISP throttling and rich logging. The roadmap has stalled since the engine was absorbed into Bird, but the installed base is enormous. |
| Halon | Commercial | ESP / security-focused | Deeply programmable mail flow through its own scripting language, with security and filtering built into the engine. Strong where complex, changing policy and multi-tenant control matter most. |
| MailerQ | Commercial (C++) | Large ESP infrastructure | A queue-driven architecture built around external message queues, designed for maximum throughput and real-time control over delivery behaviour at very large scale. |
| GreenArrow | Commercial | High-volume, cloud or on-prem | A solid MTA core with optional marketing features bundled alongside it, available both as a managed cloud product and self-hosted. |
| Exim / Sendmail | Free (open source) | General-purpose / legacy | Exim is flexible with a powerful configuration language; Sendmail is historically important but rarely chosen for new builds. Most high-volume senders graduate away from both. |
When should you choose Postfix or KumoMTA?
Postfix is the workhorse of the internet and the right default for almost everyone. It is secure, stable, free, and bundled into nearly every Linux distribution and self-hosting stack, and it handles the great majority of sending needs without anyone thinking hard about it. Its limits show at marketing scale, where per-recipient throttling and per-provider traffic shaping require custom configuration work that purpose-built engines do natively. Reaching those limits is a milestone most senders never hit.
KumoMTA is the modern open-source option for the senders who do. Built in Rust by the architect behind Momentum, configured as code in Lua, and designed cloud-native from the start, it brings the high-volume capabilities of a commercial engine \u2014 native throttling, traffic shaping, per-tenant control \u2014 at zero software cost. The standing advice across the industry now is direct: for anyone weighing a commercial license, evaluate KumoMTA first, because it provides much of the same capability without the annual fee. The trade is operational, not financial: you need the skill to run a configuration-as-code engine, and it ships no web interface by design. Both gaps are closeable; neither is a reason to default back to paying for a license out of habit.
When is a commercial engine like PowerMTA worth it?
A commercial license still buys real things \u2014 a vendor relationship, support with an SLA, and in some cases capabilities that are genuinely hard to replicate. The question is whether those things justify the price for your situation, and the answer differs sharply by engine.
PowerMTA remains the industry standard by installed base, with two decades of proven IP-pool management, per-ISP throttling and logging behind it. Its weakness in 2026 is direction rather than capability: the roadmap stalled after the engine was folded into Bird, so a fresh PowerMTA license increasingly competes with a free KumoMTA that does much of the same job. Halon takes a different angle, offering a deeply programmable engine with its own scripting language and security and filtering built in \u2014 the strong choice where complex, changing policy and multi-tenant control are the central requirement. MailerQ is built around external message queues for maximum throughput and real-time delivery control, aimed at the largest ESP infrastructures where queue-driven architecture is the point. GreenArrow pairs a capable MTA core with optional marketing features, which is attractive if you want sending and campaign tooling from one vendor and a deterrent if you would rather your application layer owned that. None of these is a bad engine. Each is the right engine for a specific shape of problem, and the wrong one for the others.
When more than one engine makes sense
Most senders should run exactly one engine; a second is operational surface that needs a reason. But for some large operations, more than one is the right design. A platform might run KumoMTA for its bulk marketing streams and keep a separate, tightly controlled path for high-value transactional mail, so a marketing problem can never touch a password reset. A business mid-migration runs two engines by definition for a while, one draining as the other fills. And a few operators deliberately split by provider or by region, matching each engine to what it is best at.
The case against a multi-engine setup is real and usually wins: every additional engine is another thing to configure, monitor, patch and understand, and the complexity compounds rather than adds. So the bar is high. We design a multi-engine estate when the isolation or the specialisation genuinely earns its keep, and we talk teams out of it when it is complexity for its own sake. The default remains one engine, run well; more than one is a deliberate choice for a specific problem, not a sign of sophistication.
How we would actually decide
Stripped of nuance, the decision tree is short, and we would walk it roughly in this order. If your volume is below the point where Postfix struggles \u2014 around ten million a month \u2014 use Postfix and stop; the rest of this page is for someone else. If you are building high volume from scratch with no existing commitment, evaluate KumoMTA first, because free and modern is a strong default and the operational gaps are ones a good team closes. If you already hold a PowerMTA license and your team knows the engine, a fresh PowerMTA estate is defensible \u2014 you are building on real assets and expertise.
From there it gets specific. If your defining need is deeply programmable policy, filtering and security, Halon is built for exactly that. If it is raw, queue-driven throughput at the largest scale, MailerQ is the specialist. If you want an MTA and marketing features from a single vendor, GreenArrow bundles them. The point of the order is that the simpler, cheaper options come first and you only move down the list when a concrete requirement pushes you there \u2014 not because a more expensive engine feels more substantial.
How reversible is an MTA choice — are you locked in?
No MTA choice is permanent, but they are not equally reversible, and the difference is worth weighing. Reputation, the asset that actually matters, lives on your IPs and domains rather than the software, so it travels with you between engines when a migration is handled well — that part is not locked in at all. What varies is the configuration. A proprietary engine’s settings are specific to it, so leaving means re-expressing everything in the next engine’s terms; an open, configuration-as-code engine at least leaves you with readable logic you own outright.
The practical takeaway is to weight the decision toward the things that are expensive to undo and relax about the things that are not. Picking the wrong engine is recoverable through a migration that costs weeks, not years. Letting your reputation decay on any engine is far harder to walk back. So choose carefully, but do not treat the choice as irreversible and freeze; the larger risk for most senders is staying on a poor fit for years because switching felt more daunting than it actually is.
Why trust a recommendation from a team that resells none of them?
Most MTA advice comes from someone with a stake in the answer \u2014 a vendor selling a license, a host selling a bundle, a consultancy that only deploys one engine. That advice is not worthless, but it is shaped by the recommender’s catalogue as much as by your needs. Our position is deliberately different: we operate PowerMTA and KumoMTA and resell neither, and when Postfix, Halon, an ESP or doing nothing at all is the better fit, that is what we will tell you.
That independence is the whole value of asking us rather than a vendor. It means the recommendation can be “you do not need any of this” without costing us anything, and it means when we do suggest building an estate, it is because the volume and the requirements genuinely call for one. Advice you can trust on a decision this consequential has to come from someone whose income does not depend on which way it goes.
The decision you are really making
Choosing an MTA is not really choosing software; it is choosing a multi-year home for your sending reputation and a shape for your operational life. The engine you pick decides what your team spends time on, what your infrastructure costs, and how much control you hold over the asset \u2014 your reputation \u2014 that determines whether your mail arrives at all. That is why the decision deserves more thought than a feature comparison and less drama than the marketing around it. Get the fit right, on volume and budget and the people who will run it, and the engine becomes the part of the stack you stop thinking about. Get it wrong and you spend years working around a choice that a single honest conversation could have settled at the start.
If there is one thing to take from all of this, it is to match the engine to your reality rather than to an aspiration. The volume you actually send, the budget you actually have, and the people who will actually operate it settle the question more reliably than any feature list. Start from those three, resist the pull toward more engine than you need, and the choice tends to make itself. And if you would rather not make it alone, that is exactly the conversation we are set up to have — with no stake in which way it goes, and no reason to steer you toward anything but the fit.
FAQ
Selection questions
Can we change our minds later, or is this permanent?
It is reversible, but not cheaply, which is why it is worth getting right. Switching engines means a migration — translating configuration, preserving reputation, cutting over carefully — and reputation lives on your IPs and domains rather than the software, so it travels with you if the move is handled well. The cost of a change is real but bounded; the cost of staying on the wrong engine for years because switching felt daunting is usually larger.
Is open source a riskier choice than a commercial engine?
Not inherently, and in 2026 the calculus has shifted. A commercial license historically bought you a vendor and an SLA, which is real value — but a commercial product whose roadmap has stalled offers less of that than its price implies, while a free engine with an active community and modern architecture can be the safer long-term bet. The risk in open source is operational, not existential: you need someone to run it well. That someone can be your team or ours.
Do we even need one of these, or is an ESP enough?
For many senders an ESP is genuinely enough, and we will say so. A self-hosted MTA makes sense when your volume makes per-message ESP pricing painful, when you want to own your IPs and reputation outright, or when you need control an ESP will not give you. Below that, the engineering and operational cost of running your own engine is rarely worth it. The honest first question is not which MTA, but whether you need one at all.
Where do Amazon SES and SendGrid fit in this?
They are a different category — managed cloud sending services rather than self-hosted engines you operate. They trade control and per-unit economics for not having to run infrastructure, which is the right trade for plenty of senders. The MTAs on this page are for teams that have decided they want to own the sending layer; SES and the like are for teams that have decided they do not. Both are legitimate, and the choice between them comes before the choice of engine.
We are not sure what our volume will be. How do we choose?
Design for the volume you can actually forecast, not the one you hope for, and choose something you can grow into without a rebuild. KumoMTA and the commercial engines scale a long way, so starting there is defensible if real high volume is genuinely coming soon; starting on Postfix and migrating later is defensible if it is not. What you want to avoid is buying enterprise complexity for volume that never arrives, or painting yourself into an engine you will outgrow in a quarter.
What is the smallest viable setup that still does it properly?
A single well-configured node — Postfix for most, KumoMTA if real volume is coming — on a clean IP with correct reverse DNS, full authentication, and basic monitoring. Done properly does not mean expensive or complex; it means the foundations are right. Far more sending problems come from a small setup done carelessly than from choosing a too-small engine.
Why trust your recommendation if you build these yourselves?
Because we resell none of them. We set up and operate PowerMTA and KumoMTA, and we will recommend Postfix, Halon or an ESP when one of those is the better fit — there is no license margin pulling us toward a particular answer. The recommendation is shaped by your situation rather than our catalogue, which is the only basis on which advice like this is worth anything.
Start with the audit.
Twenty-five points across authentication, reputation, infrastructure and compliance — a written assessment, no charge and no obligation. It tells both of us exactly what we are working with.