The mail transfer agent professionals run — operated for you.

Managed KumoMTA is a service where we deploy and operate KumoMTA — the open-source, Rust-based mail transfer agent built for high-volume sending — on dedicated infrastructure on your behalf. It is for senders who have understood that deliverability is an infrastructure problem rather than a software one: teams above roughly 500,000 emails a month, often migrating off a shared SaaS that suspended them or a self-hosted setup that outgrew the people maintaining it. You get the engine professional ESPs run, the per-ISP shaping and per-tenant isolation it provides, and a team that operates it — without learning Lua, watching queues, or staffing a mail-operations function.

Because it is the right tool for outbound sending at scale, and the market validated it publicly. The common confusion is treating all MTAs as interchangeable, when receiving MTAs (Postfix, Exim) and bulk-sending MTAs (KumoMTA, PowerMTA) are structurally different — a receiving MTA routes to a handful of internal destinations, a bulk-sending MTA routes to tens of thousands of external ones, each with its own throttling and reputation. KumoMTA was built by the team behind PowerMTA, in Rust, under the Apache 2 license. When Postmark rebuilt its sending layer it moved the entire platform onto KumoMTA and published measurably faster queue times to every major provider. We run KumoMTA as the primary engine and support PowerMTA for migrations, because the right answer depends on your volume and your team.

No — you keep the control that dedicated infrastructure gives you and shed the operational burden of running it. You retain your own IPs and reputation, visibility through logs and delivery events, and the ability to request shaping or policy changes. What you hand over is the part that consumes engineering time without producing product: the daily monitoring, the per-ISP tuning, the bounce classification, the IP warming, the Lua policy maintenance. The software license is the smallest line in a self-hosted operation's real cost; the people, monitoring, and feedback-loop work dominate it, and that operational layer is exactly what managed absorbs.

The clearest public benchmark is Postmark's migration. After moving from PowerMTA to KumoMTA, Postmark documented average queue time — the time from accepting a message to completing the SMTP handoff — dropping across every major provider: Gmail to about 1.2 seconds from 2, Yahoo to 3.2 from 4.6, Microsoft to 2.8 from 4.8, and Apple to 6.3 from 8, while bounce rates held steady and the reputation built over sixteen years was preserved. Those are Postmark's numbers from their own production, not ours, but they reflect the engine you would be running. Real-world results depend on your IPs, content, and lists, which is why the warming and shaping work matters as much as the software.

PowerMTA requires a valid license file that is checked periodically against the vendor's licensing server. If that validation fails — an expired license, a connectivity problem reaching the server — the MTA stops accepting new messages. For mission-critical sending, that introduces an operational dependency on an external vendor's infrastructure that has nothing to do with your own uptime. KumoMTA, being open-source under Apache 2, has no license server to phone home and no validation that can halt your sending. For senders who want to own their failure modes, removing that dependency is a concrete reason to prefer it.

KumoMTA treats the tenant as a first-class part of its queuing architecture rather than an afterthought bolted onto an IP. Each tenant's traffic is queued and shaped independently, so one sender's reputation problem does not bleed into another's — the noisy-neighbor failure that shared pools cannot prevent. This is also the technical foundation for white-label sending: a reseller is a genuinely isolated tenant at the queue level, not a label on a shared pool. If you operate a platform that sends on behalf of your own customers, that isolation is the difference between white-label as architecture and white-label as marketing.

Below roughly 500,000 emails a month, a well-configured Postfix — often via a packaged stack — handles the job without the per-ISP shaping a bulk-sending MTA provides, and managed KumoMTA would be over-engineering. The volume where queue management and per-ISP throttling start to matter is the 500K-to-5M-a-day band; under it, simpler is better. The other honest case is a team with genuine in-house capacity that enjoys operating infrastructure and can carry the Lua configuration and the monitoring themselves — for them, self-hosting KumoMTA directly is a reasonable path, and we will say so rather than sell them a service they do not need.