KumoMTA Server Hosting

KumoMTA is the newest serious answer to an old question: how do you send a very large amount of email without paying a five-figure licence every year? It is open-source, built in Rust, and made by people who spent careers running the commercial MTAs it competes with. Hosting it well is not about the software cost — there is none — but about the expertise to configure it, warm it, and watch it. That is the part MCSNET runs as a managed service from Toronto, and this page covers exactly what that means, including the cases where KumoMTA is not the right call.

What is KumoMTA, and who builds it?

KumoMTA is an open-source message transfer agent designed from the start for high-volume outbound email — the same job as PowerMTA, Momentum or Halon, but released under the Apache 2.0 licence with its source on GitHub. It is maintained by KumoCorp and a community that includes some of the largest senders in the world. The project was started by email-infrastructure veterans who had built and operated large commercial MTA environments and decided to build the open-source tool they wished had existed.

Two technical choices define it. The core is written in Rust, which removes whole categories of memory bugs that plague long-running C-based servers and handles tens of thousands of simultaneous SMTP connections efficiently. The policy layer is Lua, so your sending rules are written as code rather than a static configuration file — traffic shaping, IP pool selection and bounce handling all live in scripts you can version and review. One more thing to be clear about: KumoMTA is a sending MTA only. It has no mailboxes, no webmail and no inbound handling. It replaces the engine that pushes your mail out, not your mail server.

It is also a live, maintained project rather than an experiment. Development is active on GitHub with hundreds of commits over the past year and regular seasonal releases, and the user base is not hobbyists — established platforms have migrated production sending to it, including AWeber, which moved off the long-running Momentum MTA as engineering support for the older platform declined. That matters for a hosting decision: you are not betting on abandonware, and the public commit history means we can see exactly when a bug that affects you is fixed, which is a transparency closed-source MTAs never offered.

Managed KumoMTA hosting: what we actually run for you

KumoMTA is aimed at experienced operations teams comfortable with DevOps practices. The managed service exists because most companies that should be using it do not want to become that team. Here is what we run:

• The server — a hardened, dedicated host in Toronto, sized to your volume.
• Installation and updates — KumoMTA from the official repository, kept current with the release cadence (the project ships regular seasonal releases).
• The Lua policy — your sending rules as code: per-ISP throttling, IP pool assignment, queue configuration, bounce classification and webhook hooks.
• IP pools and warming — addresses grouped into pools, mapped in policy, and warmed in stages so providers learn to trust them.
• Observability — Prometheus metrics, Grafana dashboards and the kcli tools, because KumoMTA ships no packaged UI on purpose.
• Deliverability operations — feedback loops, reverse DNS, blocklist watch, and the daily judgement calls that keep mail landing.

The flow looks like this:

Why pick KumoMTA over PowerMTA?

The honest answer is usually money, with a catch. PowerMTA’s licence starts around US$8,000 a year and climbs with volume; KumoMTA’s licence cost is zero, permanently, because it is open-source. For a sender doing a few million messages a day, that is a real line item erased from the budget every year. KumoMTA was also built by people who came out of the commercial MTA world, so the feature gap that used to justify the price — per-ISP throttling, IP pool management, bounce processing, traffic shaping — has largely closed.

The catch is that free software is not the same as free to operate. KumoMTA expects an operator who can write Lua and run a sending platform. PowerMTA still makes sense in two specific situations, and we will say so plainly: if your team has years of PowerMTA institutional knowledge, the operational risk of throwing that away can outweigh the licence savings; and if you need SLA-backed support from a large, established partner network, PowerMTA’s services ecosystem is more developed than KumoMTA’s younger one. For most senders neither of those applies, and the open-source path wins. For the ones where it does, we host PowerMTA too — see PowerMTA server hosting.

Put concrete numbers on it. A sender doing several million messages a day on PowerMTA might carry a licence somewhere in the low-to-mid five figures a year, on top of the server, the IPs and the management. Move the same workload to managed KumoMTA and the licence line goes to zero; what remains is the server, the IPs and our management — the same operational costs you would pay either way. Over a few years the licence savings alone usually fund the migration several times over, which is exactly why the migration traffic runs mostly in one direction. The point is not that KumoMTA is cheaper to ignore; it is that you stop paying for a licence whose value you were already struggling to justify.

KumoMTA vs PowerMTA vs Postfix — the honest fit

These three are points on a curve of cost and control, not direct rivals.

The most common path we see is Postfix outgrowing its range and moving to KumoMTA, and PowerMTA users moving to KumoMTA to escape the annual licence. Both are well-trodden. The reverse — KumoMTA back to PowerMTA — happens too, when a team decides the Lua flexibility is more than they want to maintain. We treat that as a real outcome, not a failure to hide.

Is KumoMTA actually free?

The licence is free, and that is not a trick — Apache-2 is an OSI-approved open-source licence, the source is on GitHub, and there is no per-message or per-server fee to anyone. What is not free is running it well. KumoMTA is explicitly built for experienced email-operations professionals; the documentation says as much. The cost simply moves from a predictable vendor invoice to the harder-to-buy expertise of configuration, warming and monitoring.

KumoCorp does offer paid commercial support contracts for teams that self-host, and there are authorized regional support providers. That is a sensible option if you have your own operators and just want a safety net. If you would rather not staff the role at all, that is what managed hosting is for.

What it takes to run KumoMTA well

The defining trait is configuration as code. Instead of editing a static file, you write Lua that decides how each message is handled — which IP pool it uses, how fast to send to each provider, what to do with a bounce. That is powerful and it is also a real skill. A small slice of a per-ISP shaping policy looks like this:

-- per-destination tuning: Gmail accepts mail differently than the default
kumo.on('get_queue_config', function(domain, tenant, campaign)
  if domain == 'gmail.com' or domain == 'googlemail.com' then
    return kumo.make_queue_config {
      max_deliveries_per_connection = 10,
      max_connection_rate = '5/minute',
    }
  end
  return kumo.make_queue_config {
    max_deliveries_per_connection = 20,
  }
end)

That single pattern — different rules per mailbox provider — is exactly what keeps you under each provider’s undocumented limits and out of temporary blocks. Multiply it across throttling, retry ladders, IP pool logic and bounce classification, and you have the work that the managed service takes off your plate. You keep full visibility of the policy; we keep it correct.

The Lua surface goes well beyond per-ISP limits. Retry ladders decide how long to keep trying a deferred message and when to give up, which directly affects both deliverability and queue health. IP pool logic routes different streams — marketing, transactional, per-client — down different addresses so one stream’s reputation does not drag another’s. Bounce classification reads provider responses and sorts hard failures from transient ones so your list hygiene stays accurate. And because the policy can call webhooks, AMQP, Kafka or a database directly, delivery and bounce events can flow straight into your own systems for suppression and billing. Each of those is a place to get it subtly wrong; keeping them right, release after release, is the ongoing part of the job.

The server you need for KumoMTA

KumoMTA’s footprint is modest because the bottleneck is almost never raw compute. A single well-specified node sustains volumes far beyond what most senders need; the limit is IP reputation and provider acceptance, not the CPU. A typical managed build:

A sizing readout for a typical high-volume deployment:

# mcsnet · kumomta sizing · toronto
target      4M messages / day   peak 300k / hour
server      16 cores · 64 GB · 2x NVMe (mirror)
network     10 Gbps · DDoS-filtered · clean /24 reputation
ip pool     12 IPs across 3 Lua pools · staged warming
verdict     headroom to spare — reputation is the ceiling, not the node

Notice the verdict again: at real volume the machine is barely working, and the whole game is reputation. KumoMTA’s single-node throughput means most senders never need a second box — they need clean IPs and a careful warming plan.

Warming IPs and managing reputation

A new IP starts with no trust, and sending hard from it is the fastest way to the spam folder. IP warming is the staged ramp that lets providers build confidence over days and weeks. With KumoMTA the warming plan lives in the same Lua policy that runs production, so the ramp, the IP pool assignments and the per-ISP limits are all one coherent system rather than bolted-on scripts. We start new pools small, lean early volume toward engaged recipients, enrol feedback loops, set correct reverse DNS, and watch the major blocklists daily. When Gmail or Outlook signals displeasure through deferrals, we slow that pool before it becomes a block. Because per-provider behaviour is undocumented and shifts, the schedule reacts to real feedback instead of following a fixed calendar.

Monitoring and observability without a built-in UI

KumoMTA’s lack of a packaged dashboard surprises people, but it is intentional — the project assumes you will plug it into your own observability stack, which is the right call for serious operators and a gap for everyone else. We close that gap. Prometheus scrapes the metrics KumoMTA exposes; Grafana turns them into dashboards for throughput, deferrals, bounces and queue depth; the kcli command-line tools give a live view of what is happening on the node right now. Webhooks push delivery and bounce events into your own systems for list hygiene and billing. The result is that you see more than a typical packaged UI would show, not less — it just takes someone to wire it up, which is part of the service.

Migrating from PowerMTA or Postfix to KumoMTA

The safe migration is gradual and reversible. We stand KumoMTA up next to your current platform and route a small slice of traffic — often five to ten percent on a canary subdomain — through it, comparing throughput, deferrals and bounce categorization against your existing numbers while your main domain reputation stays untouched. If the parity holds, traffic ramps over a couple of weeks with go/no-go checks at each step; if something regresses, rolling back is a DNS or load-balancer change. We keep the old platform in standby for a window after cutover, because the honest truth is that not every migration should finish: a minority of teams find the Lua flexibility is more maintenance than their licence savings justified, and reversing is a legitimate outcome we plan for rather than improvise. Billing follows the milestones, so an aborted migration does not bill for phases that never ran.

A typical ramp moves in deliberate steps rather than a single switch — a small canary share first, then a larger fraction once parity holds, then most of the traffic, then the remainder — spread across roughly two weeks with an explicit go or no-go decision at each step. The translation work is mechanical but careful: PowerMTA virtual-MTA blocks become KumoMTA pool definitions, bounce patterns become classifier rules, and retry ladders become per-ISP shaping. Getting that mapping right before the first canary message is what keeps the cutover boring, which is exactly what you want a migration to be.

What KumoMTA does not do, and what we handle around it

Being clear about the edges saves everyone a bad surprise. KumoMTA sends; it does not receive, store or serve mail, so it is not a replacement for your inbox infrastructure or a mailbox provider. It does not validate your list — a clean MTA sending to a dirty list still earns complaints and blocks, and no software fixes that. It does not ship a packaged dashboard, so without the observability work it can feel like a black box. And it assumes your DNS, SPF, DKIM and DMARC are correct; the MTA will happily send mail that fails authentication if you let it.

Around each of those edges, the managed service does the obvious thing. We pair KumoMTA with correct authentication and reverse DNS so your mail is signed and aligned. We wire the observability stack so the black box becomes a set of dashboards. We watch complaint and bounce rates and tell you when the problem is list quality rather than infrastructure, because pretending otherwise just burns reputation. What we do not do is promise that a better MTA rescues a bad sending programme — it does not, and anyone claiming so is overselling.

Why host KumoMTA in Canada with MCSNET?

Two reasons that hold up. First, data residency: KumoMTA runs on a server you control, and that server sits in Toronto, so your queues, logs and recipient data stay inside Canada under PIPEDA — outside the reach of the US CLOUD Act, which can compel a US-headquartered host to hand over data regardless of where the hardware physically lives. Canadian ownership and Canadian hosting close that gap. Second, operator depth: KumoMTA is built for experienced operators, and that is precisely what we are. You are not buying a licence and a manual; you are buying the people who write the Lua, warm the pools and read the deferrals — without an annual fee to a software vendor on top.

Who is this for, and who is it not?

It is for senders with real volume — established email platforms, agencies, and businesses where deliverability is tied to revenue — who want to escape MTA licence fees without giving up control, and who value Canadian data residency. It is also a strong fit for teams already eyeing KumoMTA who simply do not want to staff the operator role. It is not the right tool for someone sending a few thousand messages a month; for that, a standard relay or a small Postfix box is cheaper and entirely enough, and we would rather point you there. And if your team carries deep PowerMTA expertise or needs SLA-backed vendor support, we will say so and host PowerMTA for you instead. The open-source path is the right answer for most high-volume senders in 2026 — but “most” is not “all,” and we would rather get your specific case right than push one product.