Compare · Email infrastructure

KumoMTA vs MailerQ

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

Who should read this comparison?

If you send at high volume and want a modern engine — not a legacy commercial one or plain Postfix — these two are natural finalists, and the choice is about openness and how you want to operate. Both are fast, both integrate with message queues, and both are independent of Bird; they differ in whether you drive the engine with code and open metrics or with a commercial console and a vendor.

Two readers benefit most. The first is an infrastructure-as-code team that wants a free, open engine, configures through Lua kept in version control, and observes through Prometheus and Grafana — that is KumoMTA. The second wants a maintained commercial product with operations visible in a built-in web console, RabbitMQ-native architecture, and a vendor to call — that is MailerQ. Both should remember the constant from every MTA comparison: neither warms your IPs automatically, so the deliverability plan is yours or your provider’s regardless.

A useful way to decide is to look at how your team already works. If you ship infrastructure as code, keep configuration in git, and run your own metrics stack, KumoMTA slots into that world with no friction and no license — its Lua config and Prometheus output are the same shape as everything else you operate. If your operators would rather open a console and see the queues, act on a stuck campaign, and lean on a vendor when something breaks, MailerQ hands them that on day one rather than asking them to build it. The engines are close enough in raw capability that this question — code-and-metrics culture versus console-and-vendor culture — usually settles the choice faster than any benchmark, because it is really a question about how your organization prefers to run software.

Two modern engines, two operator models

What makes this comparison interesting is that both engines are modern and queue-capable, so the usual old-versus-new framing does not apply; the real split is openness and operator model. KumoMTA’s model is code and open metrics. You configure it in Lua, keep that configuration in git, test and deploy it like any other code, and observe the engine through Prometheus metrics and Grafana dashboards you control. It is free under Apache 2.0 and built in Rust by veterans of the commercial MTA world, and it integrates natively with Kafka and AMQP for queue-oriented pipelines.

MailerQ’s model is console and vendor. It is commercial, written in C++, and built around RabbitMQ, and its signature is a real-time web Management Console where queues, bounces, feedback loops, and per-IP or per-campaign analytics are visible and actionable in the browser, backed by Copernica’s support. Both fit a stack built on message queues — MailerQ natively on RabbitMQ, KumoMTA through its Kafka and AMQP integrations — so the dividing line is not architecture but whether you want an open, code-driven engine with metrics you assemble or a commercial one with a console and support included.

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. It is engine-only and code-driven — no bundled console — which keeps it lean and composable, with observability through dashboards you run. Its cost is the DevOps and Lua expertise to operate it; its appeal is a free, modern, fully open engine with no license and no lock-in.

MailerQ is a commercial high-performance on-prem MTA from Copernica, the Dutch marketing-software company, written in C++ and built around RabbitMQ for queuing. Its signature is a real-time web Management Console giving operators visibility into queues, delivery attempts, results, and error logs, with analytics per MTA, IP, customer, and campaign, plus a REST API. It classifies bounces, processes feedback loops, modifies messages by response pattern, supports throttle-schedule IP warm-up, and covers DKIM, SPF, DMARC, and TLS — and was the first MTA to support ARC. It is independent, actively developed, and backed by vendor support.

What does the side-by-side look like?

The table sets the free open engine against the commercial console-driven one. Wins land on both sides; the openness and operator-model rows are the ones to weigh first.

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

Where MailerQ has the edge

Where KumoMTA pulls ahead

KumoMTA’s case is free, open, and code-driven, with control and no lock-in. There is no license: the Apache 2.0 engine is yours to run, modify, and keep running regardless of any vendor’s fortunes, which is the strongest answer to commitment worries that even an independent commercial vendor cannot fully match. It is built in Rust for cloud-native, horizontally-scaled deployment, with Lua configuration you version, test, and deploy through CI like any other code, and native Prometheus, Grafana, and Kafka integration that an infrastructure-as-code team finds natural. Its pedigree is the same commercial-MTA lineage that built the engines it succeeds, so deliverability expertise is in the design. For a team that wants openness, config-as-code, open metrics, and zero license cost, KumoMTA is the more flexible and future-proof foundation — and managed hosting supplies the operator experience and support that are otherwise MailerQ’s advantage.

The portability that openness buys is worth naming, because it outlasts any single decision. With KumoMTA, your configuration is plain Lua and your observability is standard Prometheus and Grafana — artefacts that are not tied to one vendor’s console and that your team can carry, audit, and rebuild anywhere. If you change hosting, bring operations in-house, or hand the system to a different team in three years, nothing is locked behind a proprietary interface. A commercial console is convenient precisely because it is integrated, but that integration is also a dependency: the views, the workflow, and the operational knowledge live in the vendor’s product. For an organization that wants its infrastructure to remain fully its own, the open, code-and-metrics model is not just cheaper today but less entangling tomorrow.

Open metrics or a built-in console?

This is the question that most cleanly separates the two, because it is about how you see and steer the engine. KumoMTA exposes open metrics: Prometheus scrapes its counters, Grafana renders them, and you build the views and alerts your team needs — powerful and portable for an observability-mature shop, but assembly required. MailerQ includes the console: queues, bounces, and feedback loops are visible and actionable in the browser the moment it is running, no dashboard-building needed, at the cost of being the vendor’s interface rather than your own stack.

Neither is better in the abstract: open metrics favour teams who want their own observability stack and portability, while a built-in console favours teams who want operations ready on day one.

# KumoMTA — open, code-driven, metrics you run
config   Lua in git · Apache 2.0, free · Rust
observe  Prometheus scrape -> Grafana dashboards (yours)
# MailerQ — commercial, console-driven (Copernica)
inject   RabbitMQ / AMQP · REST API · C++
observe  real-time web Management Console (built in) · ARC
# both: queue-capable · Bird-independent · IP warm-up = human policy

Where MCSNET fits

MCSNET runs the open side: it hosts KumoMTA as a managed dedicated server in Toronto, with installation, Lua configuration, IP warming, authentication, and deliverability monitoring — including Grafana dashboards — handled. That supplies the operator experience and support that are MailerQ’s main advantage, while keeping a free, open engine with no license and no lock-in, and your own IP reputation with data in Canada under PIPEDA. The honest framing is that MailerQ answers the operator-experience question with a console and a vendor you buy, while managed KumoMTA answers it with open metrics and people who run the engine for you — both beat operating a bare engine unaided, and both are independent of Bird. MailerQ is Copernica’s own product, so MCSNET does not run it; what MCSNET offers is the open counterpart, made as turnkey as a commercial console through managed operations. 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 whether you want an open, code-driven engine with metrics you assemble or a commercial one with a console and vendor included — and weigh free-and-open against bought-and-supported. Both are modern, queue-capable, and clear of Bird, so the tie-breaker is openness and operator model. Hosting KumoMTA managed gives the open choice a console-like operator experience without the license, which closes most of the practical gap.

Common questions

What is the difference between KumoMTA and MailerQ?

Both are modern, high-performance MTAs independent of Bird, differing in openness and operation. KumoMTA is free and open-source under Apache 2.0, written in Rust with Lua config-as-code, and exposes open metrics via Prometheus and Grafana. MailerQ, from Copernica, is commercial, written in C++, built around RabbitMQ, and ships a real-time web Management Console plus vendor support. KumoMTA is open and code-driven; MailerQ is commercial and console-driven.

Is KumoMTA cheaper than MailerQ?

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. MailerQ is commercially licensed, and that cost buys a console, vendor support, and a maintained product. The comparison is free-and-self-run, or free-and-managed, versus paid-and-supported — staffing is the larger line item either way.

Do KumoMTA and MailerQ both work with message queues?

Yes. MailerQ is RabbitMQ-native — messages flow through AMQP queues and results return to result queues. KumoMTA integrates natively with Kafka and AMQP for queue-oriented pipelines. A stack built on message queues suits either; the divergence is open code-and-metrics versus a commercial console, not whether they fit a queue architecture.

Does KumoMTA have a management console like MailerQ?

Not a built-in visual console in the same way. KumoMTA is operated through Lua and observed through Prometheus metrics and Grafana dashboards you run, which suits infrastructure-as-code teams but means assembling the views. MailerQ ships a real-time web Management Console out of the box. If you want a console included, that favours MailerQ; if you prefer open metrics and code, KumoMTA fits better.

Can MCSNET run KumoMTA so I get MailerQ-like operations?

Largely. MCSNET hosts KumoMTA managed in Toronto — installation, Lua configuration, IP warm-up, authentication, and monitoring with Grafana dashboards included — supplying the operator experience and support that are part of MailerQ’s appeal, while keeping a free, open engine and your own IPs in Canada under PIPEDA. MCSNET does not run MailerQ, which is Copernica’s own product.