Managed KumoMTA
on your own infrastructure.

The Lua hook system is the central abstraction. KumoMTA fires named events at every important point in a message's lifecycle — when an HTTP submission arrives, when a queue is selected, when an SMTP delivery is attempted, when a bounce comes back. Your Lua script registers handlers for those events. The handler decides what happens. The configuration is the code; the code is the configuration.

The example below routes inbound messages to per-tenant queues based on an X-Tenant header — the kind of multi-tenant pattern that is standard for ESPs and platforms. In PowerMTA this would require a complicated VirtualMTA selection chain. In KumoMTA it is fifteen lines of Lua.

-- Read the X-Tenant header, set as message metadata, strip the header
-- before delivery so it does not leak to recipients.
kumo.on('http_message_generated', function(msg)
  local tenant = msg:get_first_named_header_value('x-tenant') or 'default'
  msg:set_meta('tenant', tenant)
  msg:remove_x_headers { 'x-tenant' }
end)

-- Route to the correct queue based on tenant. Each tenant gets its own
-- egress source (= IP), its own throttling, its own DKIM key.
kumo.on('get_queue_config', function(domain, tenant, campaign)
  if tenant == 'enterprise_a' then
    return kumo.make_queue_config { egress_source = 'pool_a' }
  elseif tenant == 'enterprise_b' then
    return kumo.make_queue_config { egress_source = 'pool_b' }
  end
  return kumo.make_queue_config { egress_source = 'pool_default' }
end)

Per-receiving-domain throttling is, similarly, a function instead of a thousand lines of static directives. The example below applies the same starting points we use for PowerMTA — Gmail at 120/min on a freshly warmed IP, Microsoft at 300/min, Yahoo at 100/min — but expresses them as a Lua table that is trivially extensible. Want to add a new mailbox provider? One line. Want to apply a per-tenant override on top of a per-domain default? Three lines.

local THROTTLES = {
  ['gmail.com']       = { rate = 120, conn = 15, backoff = 30 },
  ['outlook.com']     = { rate = 300, conn = 25, backoff = 60 },
  ['hotmail.com']     = { rate = 300, conn = 25, backoff = 60 },
  ['yahoo.com']       = { rate = 100, conn = 10, backoff = 30 },
  ['icloud.com']      = { rate = 200, conn = 20, backoff = 40 },
  ['proton.me']       = { rate = 60,  conn = 5,  backoff = 15 },
}

kumo.on('get_egress_path_config', function(domain, source, site)
  local t = THROTTLES[domain] or { rate = 200, conn = 15, backoff = 40 }
  return kumo.make_egress_path {
    enable_tls = 'OpportunisticInsecure',
    connection_limit = t.conn,
    max_message_rate = string.format('%d/min', t.rate),
    max_deliveries_per_connection = 100,
  }
end)

The observability layer in KumoMTA is native, not bolted on. The engine exposes Prometheus metrics on every queue, every egress path, every receiving domain — queue depth, delivery rate, error code distribution, backoff state. Pre-built Grafana dashboards ship with the project. We deploy them as part of every Sender-tier installation, plugged into the same Grafana fleet that runs our internal operations. You see your numbers in real time, not in a CSV that needs Logstash to make sense of.

The integration layer goes further than any commercial MTA we know of. KumoMTA emits webhooks for every important event (message accepted, delivered, bounced, complained), and it can push the same events to AMQP or Kafka or directly to a database with a Lua handler. For ESPs with a custom analytics backend, this collapses an entire bounce-processing and event-pipeline subsystem into a few hundred lines of Lua. The teams we have helped migrate from PMTA report cutting their custom Python event-processor codebase by about 60% on average — and ending up with a system that is more reliable than what they replaced.

From the service-delivery angle, the migration is mostly a translation exercise on the concepts your team already knows. VirtualMTAs in PowerMTA correspond to egress sources in KumoMTA. The skill is identical: bind a logical sender to a source IP, attach a throttling policy, attach a DKIM key, attach a bounce handler. We have run this translation often enough that the mapping is in our intake notes, and the first migration call usually closes with the customer's engineer saying some version of "okay, that is less mysterious than the migration guide made it sound." The PMTA-trained reflex of thinking in VMTAs transfers without rework.

What does not map cleanly are the dozens of one-line PMTA directives that accumulated as workarounds for specific edge cases — the delete-file-holders yes, the run-as-root, the half-dozen flags that were added to fix bugs in the 2010s and stayed in everyone's config because nobody remembered they could be removed. The KumoMTA core handles those concerns natively. Removing them is part of the engagement: we will audit your existing config against the list of bugs those flags worked around, confirm none of those bugs is still relevant, and drop the workaround flags from the migrated build with a written rationale per line so a future engineer can verify the call.

What changes in scale is the configuration footprint we end up maintaining for you. PMTA configs we have inherited average 4,500-6,000 lines and lean heavily on per-domain blocks repeated for every receiving destination. The Lua rewrite we hand back is consistently shorter — 800-1,200 lines for the same operational scope — because the per-domain blocks collapse into table entries and a single iterator. The smaller config is the visible deliverable, but the operational dividend is what matters: fewer lines means fewer review cycles when your team needs to change a throttling policy or onboard a new mailbox provider's quirks. A recent migration we ran took a 5,800-line PMTA install down to a 950-line Lua install; we ran them in parallel for six weeks and the team cut traffic over only once the dashboards agreed on every metric.

The harder parts are the bits that were in shell scripts around your PMTA install rather than in the config itself. Your custom bounce handler. Your accounting log parser. Your 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. We can usually do it in three.

The Lua language itself is rarely the obstacle. Engineers who have written any kind of programming language pick up Lua in an afternoon — the Programming in Lua book is freely available online, and the parts you need for KumoMTA configuration cover maybe the first 80 pages. The deeper KumoMTA-specific event model — hooks, configuration patterns, lifecycle handlers — is documented at docs.kumomta.com and we walk you through it as part of the migration engagement.

KumoMTA is the right choice when you are starting fresh with no existing PMTA config to preserve; when configuration as code is part of your operations culture; when the per-server licence cost is meaningful against your margin; when you want native Prometheus and Grafana rather than custom log-parsing pipelines; when your team is comfortable with — or willing to learn — Lua; when you need event integration with Kafka or AMQP or a custom analytics backend; or when you want to avoid the vendor-relationship overhead that comes with any commercial product. For most new deployments past 1M sends per month, KumoMTA is the default.

PowerMTA is still the right choice when you have a mature PMTA installation with years of tuning that lifts and shifts cleanly to managed hosting without rewriting; when procurement requires a vendor SLA backed by a commercial entity (Bird) for compliance reasons; when your team has deep PMTA muscle memory that would take six months to replicate in Lua; or when you need a specific PMTA feature (the SparkPost reporting integration, the proprietary submission-via-pickup mechanism at very high volume) that has no direct KumoMTA equivalent yet. The gap on that last point closes every release; we expect it to be effectively zero by the end of 2026.

The volume thresholds are the same as for PowerMTA. 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 procurement constraint. 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 the AWeber and AhaSend deployments.

If you want a side-by-side feature comparison covering 10 dimensions (licensing, throughput, configuration, throttling, observability, webhooks, IP routing, lock-in, sovereignty, best-fit volume), it is on the home page in the Choosing your MTA section.

KumoMTA is open source, which means a different risk profile than commercial MTAs. Not better. Not worse. Different. The four risks below are the ones we have seen show up across the client base in the last 24 months, and the ones the KumoMTA team would acknowledge but does not advertise. None are dealbreakers. All are things to plan around if you are evaluating the product against PowerMTA on equal terms.

1 — The enterprise support gap

The first risk is the enterprise support gap. PowerMTA at the Volume tier comes with a phone number to a Port25 engineer, four-hour SLAs on critical issues, and a track record of nineteen years of supporting paying customers in production. KumoMTA's commercial support comes from KumoCorp — the company that maintains the open-source project — and is a much younger operation. Response times are good, the team is technical, but the institutional knowledge of running every weird edge case at every weird customer scale that Port25 has accumulated is not yet there. For most senders this does not matter; the open-source code is well-engineered and the documentation is thorough. For a sender running 200 million messages per month with audit requirements that demand a vendor on the hook contractually, PowerMTA's support depth is a real factor in the buying decision.

2 — Lua skills as single point of knowledge

Second is the operational skills question. Lua is easy to learn, but it is one more thing your team needs to know. PowerMTA configs can be edited by anyone who can read a flat file. KumoMTA configs require someone who is comfortable with conditional logic, table iteration, and basic functional programming patterns — three skills that are not universal among email operators. Most teams pick this up in a week. Some teams have a senior who picks it up and a junior who never quite does, which creates a single point of knowledge in the organisation. We have one client whose entire KumoMTA pipeline depends on one engineer's understanding of Lua patterns, and we have flagged it as an operational risk to their leadership three times. They have not addressed it. The risk is real even when the technology choice was correct.

3 — Feature lag in niche operational areas

Third is feature lag in narrow areas. PowerMTA has nineteen years of accumulated features for niche operational needs — exotic bounce categorisation rules for legacy receivers, specific SMTP extensions used by enterprise inbox providers, throttling primitives for receivers that PMTA has had decades to characterise. KumoMTA covers 95 percent of what production deployments actually need. The remaining 5 percent matters for specific senders. We have one client running heavy Japanese market traffic where two PMTA features around DoCoMo deliverability heuristics had to be reimplemented in Lua. The reimplementation works but took three weeks of engineering time. If your sending profile has any unusual receiver concentration, audit the PMTA features you actually depend on before assuming they map to KumoMTA without effort.

4 — Open-source roadmap dependency

Fourth is the open-source roadmap dependency. KumoMTA is maintained by a small team at KumoCorp with funding that has been described publicly as adequate but not deep. If the project loses momentum, the operational continuity for senders in production becomes the community's responsibility. The code is open source under the Apache 2.0 licence. A sufficiently motivated user can fork and maintain it. In practice, the engineering depth required to maintain a high-throughput MTA is rare enough that most senders will not be able to do this themselves. We mitigate the risk in a specific way — by maintaining our own tested fork of the KumoMTA core, with patches we have tested in production but not yet upstreamed. If the upstream project stalls, our clients keep running on a known-good codebase while alternatives get evaluated. PowerMTA does not have this risk profile because Port25 has been a stable commercial entity for nineteen years and counting.