Skip to content
Customer portal
OS Domains
Get a quote
MTA head-to-head

KumoMTA vs Halon

KumoMTA and Halon are both programmable mail transfer agents — engines where shaping, routing and filtering are written as code rather than set in static configuration — which makes them a closer match than most MTA pairings. The split is licence and scope. KumoMTA is open source, written in Rust with policy in Lua, and focused on high-volume outbound, with no licence fee. Halon is a commercial Swedish engine programmed through HSL, its own scripting language, and reaches across the whole mail flow, including inbound filtering and security, which is why ESPs and security-conscious operators use it. For programmable outbound alone, KumoMTA usually covers it without paying; Halon earns its licence when you also want programmable inbound filtering, its security heritage, or vendor support behind a mature platform.

Two engines that treat mail flow as code — open-source Lua against commercial HSL, outbound focus against full-flow control. The split is licence and scope, not whether you can program them.

In short

  • Both are programmable MTAs — logic as code, not static config — so this compares philosophy-sharing engines rather than opposites.
  • The split is licence and scope: KumoMTA is open source (Apache 2.0) and outbound-focused; Halon is commercial and spans the whole mail flow, inbound filtering included.
  • The scripting differs: KumoMTA uses Lua; Halon uses HSL, its own purpose-built scripting language.
  • Halon’s heritage includes email security and content filtering, which is why it appeals to ESPs and security-conscious operators beyond pure sending.
  • The honest default: for programmable outbound, KumoMTA covers it with no licence; reach for Halon when full-flow programmability, inbound filtering or vendor support is the requirement.
Talk to an engineer See all six engines
A rare pairing: two engines that agree

Most MTA comparisons are opposites. This one is a family argument.

Put Postfix next to PowerMTA and you are comparing a general-purpose default with a commercial heavyweight — different tools for different jobs. KumoMTA and Halon are not like that. Both share the same conviction: that an MTA should be programmable, that shaping and routing and filtering belong in code you write and version rather than in static files you edit. They arrive at that conviction through different languages — Lua for KumoMTA, HSL for Halon — but the philosophy is the same.

That shared ground is what makes the comparison interesting, because it strips the decision down to two real variables. One is the licence: KumoMTA is open source and free, Halon is commercial. The other is scope. KumoMTA concentrates its programmability on outbound sending and does that one thing thoroughly. Halon reaches across the entire mail flow — outbound, yes, but also inbound filtering and email security, which is a large part of why it has a following among ESPs and security teams.

So the question is not which engine is more programmable. It is whether you need that programmability across the whole flow with a vendor behind it, or focused on outbound without an invoice. We run KumoMTA and advise on Halon, so what follows weighs those two variables honestly rather than talking up the one with a price tag.

Language and reach

What is the real difference between them?

Start with the languages, because they reveal the rest. KumoMTA expresses policy in Lua, a small, widely known scripting language, which lowers the barrier for a team that already writes code and wants its sending logic to look like the rest of its stack. Halon uses HSL, a language built specifically for mail processing, which is purpose-fit for the job and one more thing to learn. Neither choice is better in the abstract; one optimises for familiarity, the other for a language shaped around the domain.

The reach is the larger difference. KumoMTA is an outbound engine: its programmability is aimed at how mail leaves and how that sending protects reputation. Halon programs the full flow, so the same scripting that shapes outbound can inspect, filter and route inbound mail and enforce security policy. If your need is sending, that breadth is weight you do not use; if your need spans filtering and security as well as sending, it is the reason to choose Halon and accept the licence.

The scope each one covers

One engine programs sending; the other programs the whole flow

The clearest way to picture the difference is by what each engine touches. KumoMTA owns the outbound path and makes it programmable end to end. Halon spans inbound filtering and security as well as outbound, with one scripting model across all of it. The diagram marks where each one’s programmability applies.

KumoMTA — outbound, programmable in Lua your app Lua policy inbox one direction · sending only Halon — full flow, programmable in HSL inbound filtering security / content outbound sending routing one HSL model across the entire flow
Side by side

KumoMTA and Halon on the dimensions that decide

KumoMTA Halon
Licence & cost Open source (Apache 2.0), free Commercial
Origin Veterans of the high-volume MTA world Halon Security, Sweden
Scripting Lua policy HSL (Halon Scripting Language)
Scope Outbound sending Full mail flow: outbound + inbound filtering/security
Programmability Shaping and routing as Lua Logic at every stage of the flow via HSL
Support Community plus commercial options Vendor support
Volume sweet spot 500K–5M/day and scaling 10M+/day, ESP-grade
Choose it when Programmable outbound, no licence Programmable full flow plus vendor support

KumoMTA is enough when

Your need is programmable outbound sending and nothing beyond it. You want shaping and routing as versioned Lua, you are sending in the high hundreds of thousands to low millions a day, and you would rather not carry a licence for reach you will not use. KumoMTA gives you the programmable model without the invoice, and it scales upward as your volume grows.

It also pairs naturally with the rest of an open-source stack — see how it sits against the commercial heavyweight in PowerMTA vs KumoMTA.

Halon earns its licence when

Your programmability has to span the full mail flow, not just sending. You want to inspect and filter inbound mail, enforce security and content policy, and route across the whole path with one scripting model — and you want a vendor behind a platform that ESPs have run at scale. For those needs, HSL across the entire flow is what the licence buys, and it buys something a sending-only engine does not offer.

That breadth, plus vendor support, is the honest case for paying — when the breadth is something you will actually use.

The one-line rule

Both let you program your mail. Choose KumoMTA when the job is outbound and you want no licence; choose Halon when the job spans inbound filtering and security and you want a vendor behind it.

Where OS Domains fits

We run the open-source one and tell you when you need the other

KumoMTA is part of our managed infrastructure, and for most senders who want programmable outbound it is the engine we put underneath them — no licence, modern policy, room to scale. When the requirement reaches past sending into inbound filtering or security, we say so and point toward Halon, because pretending an outbound engine covers the full flow would not serve you. The recommendation follows the shape of your need, not the size of an invoice.

Underneath either engine sits the constant we add: dedicated IPs whose reputation we warm and manage, and EU-resident infrastructure under an Austrian entity, so the sending leg raises no cross-border transfer question in your compliance review. The programmable engine is a choice between two good models; the dedicated, sovereign, operated base is the part that is hard to build alone. For the whole field, the MTA comparison hub places KumoMTA and Halon among all six.

The practical questions

KumoMTA vs Halon: what senders ask

KumoMTA and Halon are both programmable — what really separates them?

Licence and scope. Both treat mail behaviour as code rather than static configuration, which makes them genuinely similar in philosophy. KumoMTA is open source and focused on high-volume outbound, scripted in Lua, with no licence fee. Halon is commercial, scripted in its own HSL, and spans the whole mail flow — including inbound filtering and security, not only sending. So the question is not which is more programmable but whether you need programmability across the entire flow with vendor support, or programmable outbound on its own without a licence.

Is Halon worth the licence over free KumoMTA?

It depends on whether you use what the licence covers. Halon’s value is breadth and support: programmable control over inbound filtering and security as well as outbound, plus a vendor behind a platform that ESPs have run at scale for years. If you need that breadth, the licence buys something real. If your need is programmable outbound sending alone, KumoMTA reaches the same place in Lua at no licence cost, and paying for Halon would buy reach you will not exercise.

What is HSL?

HSL is the Halon Scripting Language, the purpose-built language Halon uses to let operators write logic that runs at each stage of the mail flow — routing decisions, content inspection, filtering, shaping. It is what makes Halon a programmable engine rather than a configured one, in the same spirit that Lua makes KumoMTA programmable. The two languages differ, but the idea is shared: behaviour you write and version rather than declare in static files.

Can KumoMTA do inbound filtering the way Halon does?

No — and that is the cleanest line between them. KumoMTA is built for outbound sending and concentrates its programmability there. Halon spans the full mail flow, including inbound filtering and email-security use cases, which is a large part of why operators choose it. If your requirement includes programmable inbound handling or content security, that is Halon’s territory; if it is purely about sending well at volume, KumoMTA covers it.

Which one scales higher?

Both handle very high volume, so this is rarely a throughput question. Halon is positioned at the ESP-grade, tens-of-millions-a-day tier with vendor support to match; KumoMTA comfortably covers the 500K–5M band and scales upward. The decision between them at the top of the range turns on scope and support — full-flow programmability and a vendor contract versus open-source outbound control — rather than on a hard ceiling either one hits first.

Do you run both?

We run KumoMTA as managed infrastructure and advise on Halon where its broader scope is the right fit — typically when programmable inbound filtering or its security heritage is part of the requirement. The recommendation follows what you actually need across the mail flow, on dedicated EU-resident infrastructure either way, so we are not steering you toward the commercial engine when the open-source one covers your case.

Outbound, or the whole flow?

Tell us what you need to program.

If it is outbound sending, KumoMTA likely covers it with no licence. If it spans inbound filtering and security, we will weigh Halon honestly — on dedicated EU infrastructure either way.

Talk to an engineer Compare all six engines
Phone +43 1 205 11 80 Mon–Fri · 9–18 CET
Email [email protected] Avg response 4h business
Office Fleischmarkt 1, 1010 Wien By appointment