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

KumoMTA vs MailerQ

KumoMTA and MailerQ are both high-volume mail transfer agents, but they organise around different ideas. KumoMTA is policy-centric: open source, written in Rust, with shaping and routing expressed as Lua policy you write and version. MailerQ is queue-centric: a commercial C++ engine from the Dutch company Copernica, built around RabbitMQ, where the message queue is a first-class part of the system you inspect and manipulate directly. KumoMTA carries no licence; MailerQ is commercial at a modest published price, roughly €1,500–3,500 a year. Because both are EU-rooted, the choice is not about sovereignty but about architecture — policy-as-code without a licence, or a queue-centric engine that slots into a RabbitMQ-based stack with vendor support.

Two high-volume engines built on different ideas — policy-as-code against a queue-centric design on RabbitMQ. Both are EU-rooted, so the choice is architecture, not sovereignty.

In short

  • The split is architectural: KumoMTA is policy-centric (logic as Lua); MailerQ is queue-centric (the RabbitMQ queue is the interface you manipulate).
  • KumoMTA is open source with no licence; MailerQ is commercial at a modest published band, roughly €1,500–3,500 a year — a softer cost fork than enterprise engines.
  • MailerQ, from the Dutch company Copernica, suits teams already running RabbitMQ who want the queue as the integration point.
  • Both are EU-rooted, so this is not a sovereignty decision — it is about which architecture fits your stack.
  • The honest default: for policy-as-code outbound without a licence, KumoMTA; for a queue-centric engine integrated with RabbitMQ and backed by a vendor, MailerQ.
Talk to an engineer See all six engines
Two ideas about where delivery lives

The difference here is a question of what sits at the centre

Most engine comparisons turn on licence or volume. This one turns on architecture, because KumoMTA and MailerQ answer a more basic question differently: what is the centre of your sending system? For KumoMTA, the centre is policy — the Lua you write to decide how each message is shaped and routed, with the queue tucked behind it as plumbing. For MailerQ, the centre is the queue itself: built on RabbitMQ, it makes the message queue a thing you address directly, inject into and inspect, so delivery is something you drive through the broker.

That difference sounds abstract until you map it onto a real stack. A team whose architecture is already message-driven, already running RabbitMQ, finds MailerQ slots in where they think — the queue is the seam they already work with. A team that wants its sending behaviour expressed as reviewable code, independent of any particular broker, finds KumoMTA fits the way they build. The engines are not arguing about quality; they are offering two different seams to integrate at.

One thing this comparison is not about is sovereignty. KumoMTA comes from the open-source MTA world and MailerQ from Copernica in the Netherlands, so both are European-rooted. That cut, which matters against a US-headquartered engine, is neutral here. What is left is a clean architecture decision — and a modest licence — which we can weigh honestly because we run KumoMTA and advise on MailerQ rather than selling either.

Policy at the centre, or the queue

What is the real difference between them?

KumoMTA’s model is policy-as-code. You write Lua that runs as messages flow, deciding shaping, routing and suppression, and you version that logic like any other part of your stack. The queue exists, but you interact with the engine through policy, not through the queue directly. This suits teams that want their sending rules legible and reviewable, decoupled from the surrounding infrastructure.

MailerQ inverts that emphasis. Its design is built on RabbitMQ, and the message queue is the primary interface: you place messages onto it, the engine works them off it, and you can inspect and manipulate that queue as a normal part of operating the system. For an architecture that is already broker-driven, this is a natural fit — delivery becomes another consumer and producer on a queue you already understand. The trade is that your sending is now coupled to that broker model, which is a strength if you want it and overhead if you do not.

Two architectures, drawn

Where each engine puts the centre of gravity

In KumoMTA, a message meets your Lua policy first, and the policy decides what happens. In MailerQ, the message lands on the RabbitMQ queue, and the queue is the surface you build around. The diagram contrasts the two seams.

KumoMTA — policy-centric message arrives Lua policy decides shaping · routing · suppression delivered (queue is behind the policy) MailerQ — queue-centric message placed on queue RabbitMQ queue inspect · manipulate · the interface workers deliver from the queue
Side by side

KumoMTA and MailerQ on the dimensions that decide

KumoMTA MailerQ
Licence & cost Open source (Apache 2.0), free Commercial (~€1,500–3,500/year)
Origin Veterans of the high-volume MTA world Copernica, Netherlands
Language Rust core, Lua policy C++
Architecture Policy-centric Queue-centric, built on RabbitMQ
Integration model Policy you write and version The RabbitMQ queue as the interface
Support Community plus commercial options Vendor support
Volume sweet spot 500K–5M/day and scaling 10M+/day
Choose it when Policy-as-code outbound, no licence A queue-centric, RabbitMQ-integrated stack

KumoMTA fits when

You want your sending behaviour as code — Lua policy you review and version — decoupled from any particular broker, and you would rather not carry a licence at all. Your architecture is not built around a message queue you want delivery to live inside, and your priority is clean, programmable outbound that scales. KumoMTA gives you that with no invoice and room to grow.

For how it weighs against the commercial heavyweight rather than the queue-centric option, see PowerMTA vs KumoMTA.

MailerQ fits when

Your stack is already broker-driven and RabbitMQ is part of how you build. You want the message queue to be the integration point for delivery, with the ability to inspect and manipulate it directly, and you want a vendor behind the engine. The modest licence is easy to justify when the queue-centric model matches your architecture, because the engine is then working the way you already think.

The cost gap is small here, so let architecture, not price, lead the decision.

The one-line rule

Let architecture decide, not cost. Choose KumoMTA for policy-as-code outbound with no licence; choose MailerQ when a RabbitMQ-centric stack makes the queue the natural place for delivery to live.

Where OS Domains fits

We match the engine to your architecture, not to a price list

Because we run KumoMTA as managed infrastructure and advise on MailerQ, we can give the answer that follows your stack rather than our margin. If your architecture is broker-driven and you want delivery on the queue, MailerQ may be the cleaner fit and we will say so; if you want policy-as-code outbound without a licence, KumoMTA is the call. Both are European-rooted, so neither earns a sovereignty bonus here — the decision is honest architecture, and we treat it that way.

What we add beneath either is the part that is hard to assemble alone: 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 engine and its architecture are a choice; the dedicated, sovereign, operated foundation is the constant. This completes the field — the MTA comparison hub sets all six engines, KumoMTA and MailerQ included, side by side.

The practical questions

KumoMTA vs MailerQ: what teams ask

What does "queue-centric versus policy-centric" actually mean?

They are two mental models for the same delivery job. MailerQ puts the message queue at the centre: built on RabbitMQ, it treats the queue as a first-class interface you inject into, inspect and manipulate directly, so delivery is something you drive through the broker. KumoMTA puts policy at the centre: the Lua logic you write decides how each message is shaped and routed, and the queue is an implementation detail behind that. Neither is more correct — they suit different ways of thinking about and integrating delivery.

Is MailerQ expensive compared with free KumoMTA?

Less than you might assume. MailerQ is licensed commercially in a published band of roughly €1,500 to €3,500 a year, which is modest next to enterprise engines quoted per server. So unlike a comparison with a top-tier commercial MTA, the cost gap here is small, and it is rarely the deciding factor. The real question is architecture: whether a queue-centric engine fits your stack better than policy-as-code, not whether you can afford the licence.

Why would I want a queue-centric MTA?

Because of what you already run. If RabbitMQ is part of your architecture and you want the message queue to be the integration point — injecting mail from your broker, inspecting and manipulating the queue directly, weaving delivery into a broader message-driven system — MailerQ fits that shape naturally. It is the most explicitly queue-driven of the engines, which is exactly its appeal to teams built around a broker.

Does the EU-sovereignty argument apply between these two?

No, and it is worth being clear about that. KumoMTA grew out of the open-source MTA world and MailerQ comes from Copernica, a Dutch company, so both are EU-rooted. The comparison between them is not about jurisdiction or data residency — it is about architecture and licence. Sovereignty becomes a differentiator when the alternative is a US-headquartered engine, not between two European-rooted ones.

Which one scales higher?

Both handle very high volume, so this is not a ceiling question. MailerQ is positioned at the 10-million-a-day commercial tier with RabbitMQ integration and vendor support; KumoMTA covers the 500K–5M band comfortably and scales upward. At the top of the range the decision is whether a queue-centric architecture with a vendor behind it serves you better than open-source policy-as-code, rather than which one runs out of capacity first.

Do you run both?

We run KumoMTA as managed infrastructure and advise on MailerQ where a queue-centric, RabbitMQ-based architecture is the right fit. The recommendation follows your stack — if you are already broker-driven, MailerQ may slot in cleanly; if you want policy-as-code outbound without a licence, KumoMTA is the call. The dedicated IPs and EU-resident infrastructure underneath stay the same, so the advice tracks fit rather than a sale.

Policy-as-code, or queue-centric?

Tell us how your stack is built.

If you want programmable outbound without a licence, KumoMTA likely fits. If you are RabbitMQ-driven and want the queue at the centre, we will weigh MailerQ — 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