Compare · Email infrastructure

KumoMTA vs Halon

Researched 2026-06-22 · perishable specs (licensing, versions) verify with each project at time of decision

Who should read this comparison?

If you want a modern, scriptable MTA — not PowerMTA’s static config — these two are the leading options, and the choice is about openness and scope. Both let you program mail logic as code and both are independent of Bird; they part ways on whether you want a free open outbound engine or a commercial platform that also covers inbound and security.

Two readers benefit most. The first wants a free, open engine for high-volume outbound, is happy to script policy in Lua and bring its own inbound, security, and front-end, and would rather avoid licenses and lock-in — that is KumoMTA. The second runs mail infrastructure as a product — an ISP, a hosting provider, a multi-tenant platform — and wants inbound security and outbound delivery programmable together, with vendor support behind it; that is Halon. The dividing question is how much of the stack you need from one place, and whether you want it open and free or commercial and complete.

A clarifying way to place yourself is to ask what problem actually pushed you past a static-config engine. If the answer is “I need programmable outbound — smarter routing, dynamic throttling, policy I can version and test” — then KumoMTA gives you exactly that programmability for free, and nothing more is required. If the answer is broader — “I run mail for many customers, I need inbound filtering and outbound delivery governed by the same rules, security woven into the flow” — then you are describing a platform problem, and Halon was built for that shape. The mistake in either direction is expensive: paying for Halon’s platform breadth when you only needed scriptable outbound, or choosing KumoMTA and then discovering you have to build the inbound-security and multi-tenant layers Halon would have included. Naming the real driver keeps you from both.

Two scriptable engines: open versus commercial, engine versus platform

What sets this comparison apart from the PowerMTA matchups is that both of these are already programmable, so the config-versus-code debate is settled — the real distinctions are openness and scope. On openness, KumoMTA is free and open-source under Apache 2.0, with Lua scripting and open metrics; Halon is commercial, with HSL scripting and a licensed platform. That shapes cost, lock-in, and who may modify the system: KumoMTA’s Lua and Prometheus output are portable and unowned, while HSL scripts are Halon-specific and stickier.

On scope, KumoMTA is an outbound engine. It scripts delivery policy in Lua and sends at high volume, leaving inbound filtering, security, and multi-tenancy to surrounding systems you provide. Halon is a composable platform: HSL programs the full mail flow across every SMTP phase, and the product bundles inbound security through Protect, classification through Classify, and analytics, with multi-tenant policy expressed as code. So both let you write mail logic rather than configure it, but KumoMTA writes the logic of an open outbound engine, while Halon writes the logic of a commercial platform that spans inbound, outbound, and security together.

What each one actually is

KumoMTA is an open-source outbound sending engine under Apache 2.0, written in Rust with Lua scripting, founded in 2023 by veterans who built the commercial MTAs, including Momentum’s original architect. It delivers millions of messages an hour, scales horizontally with Docker and Kubernetes, and integrates natively with Prometheus, Grafana, Kafka, and AMQP. Its Lua scripting expresses delivery policy as code, and it is engine-only and outbound-only — no inbound filtering, security modules, or bundled multi-tenancy. Its cost is the DevOps and Lua expertise to run it; its appeal is a free, modern, scriptable engine with no license and no lock-in.

Halon is a commercial programmable email-infrastructure platform from an independent Swedish vendor. Its core is a high-performance MTA, but its signature is HSL, a domain-specific language that programs mail flows as code across every SMTP phase, with real-time policy adaptation and per-message API calls. It is composable and modular — Halon Engage for outbound, Halon Protect for inbound security, Halon Classify for classification — plus a policy engine, security filters, and analytics, with multi-tenant control and a web interface for deliverability operations. It is container-native, aimed at ESPs, ISPs, hosting providers, and security-forward, multi-tenant operations, and backed by vendor support.

What does the side-by-side look like?

The table sets the open outbound engine against the commercial composable platform. Wins land on both sides; the openness and scope rows are the ones to weigh first.

Licensing and versions are perishable — verify current terms with each project; verify price as of date.

Where Halon has the edge

Where KumoMTA pulls ahead

KumoMTA’s case is free, open, and scriptable, with no license and no lock-in. It gives you the programmability that distinguishes both of these from static-config engines — Lua scripting of delivery policy — without a commercial license, so the cost is servers and expertise rather than a per-year fee. It is built in Rust for cloud-native, horizontally-scaled deployment, with native Prometheus and Grafana observability and the same commercial-MTA pedigree behind its design. Crucially, its openness means no lock-in: Lua scripts and Prometheus metrics are portable and unowned, where HSL scripts are Halon-specific. For a team whose need is high-volume outbound with programmable policy — and which either does not need inbound security and multi-tenancy or already has them — KumoMTA delivers the scriptable modern engine for free, and managed hosting supplies the support that is otherwise Halon’s advantage. You pay for breadth only if you use it, and many senders do not need Halon’s full platform.

The openness also changes the risk profile in a way worth weighing against even an independent commercial vendor. Halon is independent and neutral, which is genuinely reassuring, but it is still one company whose pricing, roadmap, and survival you do not control, and its HSL scripts are an investment that lives inside its product. KumoMTA’s openness removes that dependency entirely: the engine is Apache 2.0, the Lua is portable, and the system keeps running and remains modifiable regardless of any vendor’s decisions. For a sender whose outbound infrastructure must remain fully its own — auditable, portable, and free of license renewals — that durability is a structural advantage that a commercial platform, however good its vendor, cannot match. It is the same trade openness always offers: you give up a bundled, supported product for an asset you own outright, and for the outbound half that many senders need, the asset is enough.

Lua or HSL, and how far does the scripting reach?

This is the question that most clarifies the choice, because both are scriptable and it is easy to treat the scripting as equivalent. It is not, in reach. KumoMTA’s Lua scripts the policy of an outbound engine: how mail is queued, shaped, routed, and delivered, expressed as code you keep in version control. That is real programmability, and for outbound it is enough. Halon’s HSL reaches further, programming the full mail flow across every SMTP phase — connection, recipient, data, queue — on both inbound and outbound, so filtering, security checks, and per-tenant rules live in the same scripted system. The practical question is how far your logic needs to reach: if it stops at outbound delivery, Lua covers it for free; if it extends into inbound and security, HSL spans that ground and Lua does not.

So the scripting parallel is genuine but partial: it tells you both reject static config, not that they cover the same ground.

# KumoMTA — Lua, open, outbound engine policy
kumo.on(‘smtp_server_message_received’, function(msg) … end)
license  Apache 2.0, free · Prometheus/Grafana · outbound only
# Halon — HSL, commercial, full platform (in + out)
if ($recipientdomain == “gmail.com”) { Rate(“g”, 100, 60); }
scope    inbound security + outbound + multi-tenant · vendor support

Where MCSNET fits

MCSNET runs KumoMTA managed, which gives you the open, scriptable engine with support — the programmability both of these share, without the commercial license or the lock-in. It hosts KumoMTA as a managed dedicated server in Toronto, with installation, Lua configuration, IP warming, authentication, and deliverability monitoring handled, so you get a modern scriptable outbound engine run for you, with your own IP reputation and data in Canada under PIPEDA. The honest boundary is scope: KumoMTA and MCSNET cover the outbound, sending side, not Halon’s inbound security or multi-tenant platform breadth. If your need is a full inbound-plus-outbound, security-forward, multi-tenant platform, that is genuinely Halon’s domain, and MCSNET does not try to replace it. If your need is programmable outbound — high-volume sending with policy as code, run for you and free of license — managed KumoMTA is the open counterpart, with the support that is otherwise a commercial platform’s advantage. The managed build is on the PowerMTA server hosting page, with KumoMTA offered on the same basis.

Which should you pick?

A practical test: decide how far your mail logic must reach and whether you want it open and free or commercial and complete. Programmable outbound, free and open, points to KumoMTA; a full inbound-plus-outbound, security-forward, multi-tenant platform points to Halon. Both reject static config, so the tie-breaker is scope and licensing, not whether you can script. Hosting KumoMTA managed gives the open choice a supported operator experience without the license — closing the gap wherever your needs stop at outbound.

Common questions

What is the difference between KumoMTA and Halon?

Both are modern and scriptable — unlike PowerMTA’s static config — but differ on two axes. KumoMTA is free and open under Apache 2.0: a Rust outbound engine scripted in Lua, with open metrics and no license. Halon is a commercial, composable platform programmed in HSL across inbound and outbound, with built-in security and multi-tenant control. KumoMTA scripts an open outbound engine; Halon scripts a commercial inbound-plus-outbound platform.

Is KumoMTA’s Lua the same as Halon’s HSL?

They play a similar role — mail logic as code rather than static config — but their reach differs. KumoMTA’s Lua scripts the policy of an outbound engine. Halon’s HSL programs the full mail flow across every SMTP phase, including inbound filtering, security, and per-tenant rules. If you only need programmable outbound, Lua covers it for free; if you need programmable inbound and security too, HSL spans more, at a commercial price.

Is KumoMTA cheaper than Halon?

On software, clearly — KumoMTA is free under Apache 2.0, so you pay only for servers and engineers, with no license and no lock-in. Halon is commercially licensed, and that cost buys a composable platform, inbound security, multi-tenant tooling, and vendor support. The comparison is free-and-outbound-only versus paid-and-full-platform, so it depends on whether you need the breadth Halon bundles.

Does KumoMTA handle inbound and security like Halon?

No. KumoMTA is outbound only — it sends; it does not filter inbound mail or bundle security modules. Halon’s platform includes inbound security (Protect) and classification (Classify) alongside outbound delivery, with multi-tenant policy as code. If your need is a full inbound-plus-outbound, security-forward, multi-tenant platform, that is Halon; KumoMTA covers the outbound, sending half.

Can MCSNET run KumoMTA so I get a scriptable engine without the license?

Yes. MCSNET hosts KumoMTA managed in Toronto — installation, Lua configuration, IP warm-up, authentication, and monitoring included — giving you an open, scriptable outbound engine with support and no license, and your own IPs in Canada under PIPEDA. What it does not provide is Halon’s inbound security and multi-tenant platform breadth; MCSNET runs the open outbound engine, not a commercial inbound platform.