PowerMTA vs KumoMTA

This is not old versus new — it is a licence decision wearing a technical costume

What is the real difference between them?

It comes down to three things: how you pay, how you configure, and how mature the shaping is. PowerMTA is commercial and configured through VirtualMTA pools and policy files refined over a long production history; you bind sending streams to identities and tune per-destination behaviour through a model the vendor has hardened for years. KumoMTA is free under Apache 2.0 and configured as policy-as-code — the rules that decide how mail is shaped and routed are Lua you write and version, not entries in a static file.

That difference in configuration is the one operators feel daily. A static-file model is predictable and easy to reason about; a policy-as-code model is more expressive, letting you make routing and shaping decisions per message based on whatever logic you write. Neither is simply better. A team that wants its sending behaviour in code, reviewed and versioned like the rest of its stack, leans toward KumoMTA; a team that wants a vendor-hardened model with support behind it leans toward PowerMTA.

The clearest way to see the gap is a few lines of Lua

In KumoMTA, separating a marketing stream from a transactional stream — the isolation that keeps a campaign complaint from poisoning your password resets — is a decision made in policy at the moment a message arrives. The snippet below shows the shape of that logic; in PowerMTA the same separation is expressed by binding the streams to different VirtualMTAs in configuration instead.

-- KumoMTA: shaping and routing are policy, not a static file
-- (illustrative — the point is that this is code you version)

kumo.on('smtp_server_message_received', function(msg)
  local stream = msg:get_meta('stream') or 'default'

  -- isolate marketing from transactional on separate queues
  if stream == 'marketing' then
    msg:set_meta('queue', 'marketing.yourdomain.com')
  else
    msg:set_meta('queue', 'tx.yourdomain.com')
  end
end)

The same outcome, two routes to it. If expressing that as reviewable code appeals to your team, KumoMTA fits the way you already work. If you would rather declare it once in a vendor-supported configuration and move on, PowerMTA fits better. The deliverability result of the isolation is identical — what differs is the hand you use to reach it.

Which one is right for you?

Two questions settle it for most senders: do you need a vendor support contract with an SLA, and are you sending at the extreme top of the volume range where mature edge-case shaping matters? If both answers are no, the open-source engine removes a cost without removing a capability you use.

We run both, so the recommendation can be honest

Because we operate PowerMTA and KumoMTA as managed infrastructure, we have no reason to talk you into the more expensive one. A sender in the low-millions who only needs outbound gets KumoMTA and keeps the licence money; a sender deep in the enterprise range who needs a vendor SLA gets PowerMTA. The advice follows your volume and your requirements, and it does not move with our margin because the foundation underneath is the same.

That foundation is the part you cannot download: dedicated IPs whose reputation we manage and warm, and EU-resident infrastructure under an Austrian entity, so the sending leg raises no cross-border transfer question for your compliance review. The engine is a choice between two good options; the dedicated, sovereign, operated base it runs on is what is genuinely hard to assemble alone — and it is identical whichever of the two you choose. For the full picture across all six engines, the MTA comparison hub sets PowerMTA and KumoMTA next to Postfix, Exim, Halon and MailerQ. If you want the architecture internals, real production benchmarks and an interactive TCO calculator beneath this decision, the deep technical comparison is the companion piece.