KumoMTA servers, tuned and operated by people who run mail.

What is KumoMTA, and why are senders moving to it?

KumoMTA is a mail transfer agent built for organisations that send a lot of email and want to own how it goes out. The core is written in Rust, which gives it the throughput and memory behaviour you want from a queue that never sleeps, and the policy layer is Lua, so the rules that decide how mail is shaped and signed are scripts you can read and version. It is released under the Apache 2.0 license, which is the part that changes the economics: there is no per-message charge and no per-server license to renew.

The reason senders move to it usually comes down to two pressures. The first is cost: platforms that bill per message become painful at volume, and a license tied to throughput grows with the very thing you are trying to scale. The second is control. Large senders, email service providers, and platforms that send on behalf of their own customers want to decide how traffic is split, how aggressively it ramps, and what happens on a bounce — and they want that logic in their own repository rather than in a vendor's dashboard. KumoMTA gives them that, which is why teams leaving PowerMTA or the discontinued Momentum tend to evaluate it first.

What it does not do is earn your reputation for you. A fast MTA gives you the controls to manage authentication, pools, and pacing; the standing with mailbox providers still has to be built over weeks of clean sending. That is the work we do alongside the hosting, and it is the part most sites quietly leave out.

The architecture is worth understanding because it shapes what the host can do. The Rust core handles the queue, the connection pools, and the spool with predictable memory use, so throughput stays flat under load instead of degrading the way garbage-collected MTAs can. Around that core sits the Lua layer, where you write the rules: which pool a message belongs to, how a given destination is paced, how DKIM signing is applied, and what happens when an event fires. Because the policy is ordinary code, you can test it, review it, and roll it back like any other part of your platform.

The ecosystem around it has matured quickly. Recent releases added richer MIME handling and tighter controls for templating and parsing, and the project ships first-class hooks for webhooks, AMQP, and Kafka alongside native Prometheus metrics for Grafana. Large senders such as established ESPs have already migrated production traffic to it, which is the kind of proof that matters more than any benchmark: real volume, sent every day, on hardware the sender controls.

How does KumoMTA compare to PowerMTA and Momentum?

All three move large volumes from a single host, so raw speed rarely decides between them. The difference is the operating model. KumoMTA is open source and scripted in Lua, with no license cost and source you can inspect. PowerMTA is commercial software from Bird, formerly Port25, with the VirtualMTA model many teams already know, a support contract, and a license fee that scales with sending. Momentum, once the high end of this category, is effectively end-of-life, which is why so many migrations are moving away from it now.

If you want a vendor to call and a contract to point at, PowerMTA is a reasonable home and we host it too. If you want to own the configuration, drop the per-message economics, and treat your sending policy as code, KumoMTA is usually the better long-term seat — provided you have the operational capacity to run it, or hand that part to us. For a team leaving Momentum, the practical question is rarely whether to move but which of the two to land on, and that comes back to control versus contract.

The cost comparison is worth doing honestly, because it is rarely as one-sided as either camp claims. KumoMTA removes the license and per-message line entirely, but it adds the cost of operating the host, whether that is your engineers' time or our fee for running it. PowerMTA folds operations into a supported product but charges for the license and scales that charge with your sending. For a high-volume sender with the skills to operate it, KumoMTA almost always wins on total cost over a few years; for a smaller team that values a vendor relationship, the maths can land the other way. We will run those numbers with you on your real volume rather than quote a slogan.

Migrating to KumoMTA without downtime

Most senders coming to KumoMTA are already sending somewhere — on PowerMTA, on an aging Momentum install, or on a managed platform they have outgrown — so the migration has to happen with production traffic still flowing. We run the old and new systems in parallel rather than cutting over in one nervous evening. The new host is built, authenticated, and warmed while the existing platform keeps carrying your live volume, which means the new IPs earn their reputation before they take real traffic.

The pieces that travel with you are the ones that protect deliverability: your sending domains, your DKIM keys, and your suppression and bounce history, so you do not re-mail an address you had already learned to leave alone. As the new pools warm, we shift volume across in steps you can watch in the dashboards, holding back the moment a provider signals it wants a slower ramp. Only once the new reputation holds at full volume do we retire the old platform. A migration done this way is uneventful by design, which is exactly what you want from the system that carries your revenue mail. We schedule the cutover around your sending calendar, never in the middle of a major campaign, and keep the old host available to roll back to for a grace period after the switch, so there is always a known-good path behind you.