Compare · Email infrastructure

KumoMTA vs Haraka

Researched 2026-06-22 · both are open-source; versions and capabilities verify against current project docs

Who should read this comparison?

If you are choosing a high-performance open-source MTA and have these two on the list, the key realization is that they are not really substitutes — they are specialists at opposite ends of the mail path. One is built to send at volume; the other is built to be a programmable SMTP server you bend to almost any task. Naming which job you have settles the choice quickly.

Two readers benefit most. The first runs high-volume outbound — marketing or transactional email where reaching the inbox at scale is the whole game — and needs the deliverability tooling that defines KumoMTA. The second needs a flexible SMTP server: an inbound filtering layer, a mail gateway in front of another system, an authenticated submission server, or custom SMTP logic written in JavaScript, all of which are Haraka’s strengths. If your sentence contains “send a million emails and land them,” look to KumoMTA; if it contains “accept, filter, route, or customize SMTP,” look to Haraka.

The reason this distinction is worth labouring is that both projects describe themselves as high-performance open-source MTAs, and that shared headline hides the divergence beneath. Performance is real on both sides — KumoMTA pushes millions of messages an hour, Haraka serves thousands of concurrent connections — so benchmarks will not tell you which to choose. What tells you is the shape of the problem. A specialized outbound engine and a general programmable SMTP server can both move enormous volumes of mail and still be the wrong tool for each other’s job, because the hard part of high-volume sending is deliverability, and the hard part of a flexible SMTP server is extensibility, and each project poured its effort into a different one of those.

Specialized sending engine versus flexible SMTP server

The distinction that organizes everything is specialization. KumoMTA is a sending engine. It exists to push high volumes of outbound mail and get it delivered, so its features are deliverability features: VirtualMTA-style IP pools, per-ISP traffic shaping and concurrency control, adaptive backoff, IP warm-up, and the bounce and feedback handling that protect sender reputation. It does one direction — outbound — and does it at ESP scale, which is why it sits in the same category as PowerMTA and Momentum rather than alongside general mail servers.

Haraka is a programmable SMTP server. Its defining feature is a plugin system: every SMTP transaction is a series of hooks — connect, helo, mail, rcpt, data, queue — and each can be extended with a few lines of asynchronous JavaScript. Behaviours that would demand a custom MTA elsewhere are typically a small file in Haraka, which is why it is so widely deployed as a filtering MTA in front of other servers, as an authenticated submission server, or as a gateway with bespoke routing. It has a competent built-in outbound engine, but its centre of gravity is flexibility and inbound processing, not specialized bulk deliverability. So the question is less “which is faster” — both are fast — than “do I need a specialized sender or a general, scriptable SMTP server.”

It helps to see why a sending engine and an SMTP server are genuinely different animals despite sharing the SMTP protocol. The hard problems of outbound bulk delivery are not about speaking SMTP; they are about everything around it — spreading reputation across IP pools, ramping new addresses gradually, slowing down for one mailbox provider while speeding up for another, reading bounce and feedback signals, and adjusting all of it in real time so that a million messages land rather than trip spam defences. KumoMTA is the accumulated answer to those problems. Haraka’s hard problem is the opposite: making the SMTP server itself infinitely malleable, so that any rule about who may connect, what is accepted, how a message is rewritten, and where it is routed can be expressed as code. Haraka is the accumulated answer to that. A tool optimized for one of these is not partway to the other; they are different destinations, and the overlap — both can technically move outbound mail — is the part that misleads people into treating them as interchangeable.

What each one actually is

KumoMTA is an open-source, outbound delivery engine written in Rust with Lua scripting, released under Apache 2.0 and built by veterans of the commercial MTA world. It is designed for high volume — millions of messages an hour per server — with traffic shaping, per-tenant queuing, IP-pool management, adaptive backoff, and native Prometheus and Grafana metrics. It is outbound only, aimed at ESPs and large senders who need fine deliverability control, and configured through Lua policy you version and test. It is, in short, a purpose-built engine for the sending half of email.

Haraka is an open-source SMTP server written in Node.js, released under the MIT license, created in 2011 by Matt Sergeant — formerly the SpamAssassin project leader — and maintained today by Matt Simerson. It is plugin-oriented and event-driven, handling thousands of concurrent connections and thousands of messages a second through Node’s asynchronous I/O. It is not a mail store, an LDA, or an IMAP server; it works alongside those, excelling as a high-performance inbound and filtering MTA, an MSA on the submission port with auth and DKIM plugins, or a gateway. Craigslist famously uses it to handle inbound and forward validated connections to Postfix, cutting hardware needs by roughly half.

What does the side-by-side look like?

The table sets the specialized sender against the flexible SMTP server. Wins land on both sides, and several rows reflect their different specializations rather than a head-to-head.

Capabilities evolve — verify current features against each project’s docs.

Where Haraka is the better choice

Where KumoMTA pulls ahead

KumoMTA’s case is outbound deliverability at scale, which is not Haraka’s specialty. When you are sending millions of messages and fighting for inbox placement at every major mailbox provider, the difference is the dedicated machinery: IP-pool management with automatic rotation, per-ISP traffic shaping and concurrency limits, adaptive backoff, and IP warm-up — the tools that decide whether bulk mail reaches the inbox or the spam folder. Haraka can send, but it does not bundle that deliverability toolkit; KumoMTA is built around nothing else. Add its Rust foundation for throughput and memory safety, Lua policy aimed squarely at sending behaviour, native Prometheus and Grafana observability, and a lineage of engineers who built the commercial sending engines, and for high-volume outbound it is the specialized, purpose-fit tool. If the job is “send at scale and land,” KumoMTA is built for exactly that, and Haraka is solving a different problem.

It is worth being concrete about what “specialized” buys at volume, because it is easy to underrate until placement slips. Picture sending across many domains and IPs at once: each major mailbox provider enforces its own connection limits, rate ceilings, and reputation thresholds, and a sender that ignores them gets throttled or blocked within minutes. A specialized engine watches those signals per destination and adjusts continuously — backing off where a provider is pushing back, advancing a warming IP only as fast as its reputation allows, and keeping streams isolated so one tenant’s complaints do not poison another’s. That feedback loop is the difference between a campaign that completes cleanly and one that stalls in deferrals, and it is precisely the layer a general SMTP server leaves to you to build. Bolting it onto Haraka by hand is possible, but it means re-implementing the thing KumoMTA already is — which is rarely a good trade when deliverability is the whole point of the exercise.

The language and architecture question

Beyond specialization, the stacks themselves differ in ways that matter to the team running them. Haraka is Node.js, so its plugins are JavaScript — a language nearly every team already has, with a vast ecosystem and a gentle on-ramp for adding custom SMTP logic. That ubiquity is a real advantage: the people who can extend Haraka are easy to find, and the plugin model makes experimentation quick. The trade is the one Node always carries — single-threaded event-loop concurrency that is excellent for I/O-bound work like SMTP, but a different performance and safety profile from a compiled, multi-threaded engine.

KumoMTA is Rust, which buys memory safety and high-concurrency throughput without a garbage collector, plus Lua as a fast, embeddable policy language. That foundation suits an engine whose job is to saturate outbound capacity reliably, and its observability and infrastructure-as-code fit a modern DevOps stack. The cost is a smaller pool of Rust-and-Lua expertise than JavaScript’s, and a learning curve for teams new to those tools. Neither choice is simply better; the JavaScript model favours broad accessibility and SMTP-level scripting, while the Rust model favours specialized, high-assurance outbound performance.

The hiring and maintenance angle deserves a mention, because it often decides things in practice. Haraka’s JavaScript means a far larger pool of engineers can read, write, and debug its plugins, and that lowers the long-term cost of owning a customized deployment — the person who maintains it next year does not need a rare skill set. KumoMTA’s Rust-and-Lua stack is more specialized, which is a strength in the engine’s correctness and a constraint in staffing: there are fewer people who can extend or troubleshoot it deeply, though running a stock configuration well demands less than modifying it. For a team weighing these, the honest question is not which language is superior in the abstract but which one their organization can sustain — and whether the job calls for the kind of deep customization that makes the language pool matter at all, or simply for an engine that sends reliably out of the box.

Inbound, outbound, or both?

This is the question that most often resolves the comparison, because the two tools answer it differently. KumoMTA is outbound only — it sends and does not receive, by design, because a specialized sending engine has no need to be a general mail server. Haraka does both, and its inbound and filtering strengths are arguably its best-known use: accepting connections at high concurrency, applying plugin-based filtering, and forwarding validated mail to a store or another MTA, exactly as Craigslist and Bounce.io do.

The useful consequence is that “versus” sometimes becomes “together”: Haraka handling inbound filtering and gateway work, KumoMTA handling high-volume outbound, each doing the job it was built for.

# Haraka — behaviour is JavaScript on SMTP hooks
exports.hook_rcpt = function (next, connection, params) {
  // custom recipient logic, then:
  next();
}
# KumoMTA — policy is Lua aimed at deliverability
kumo.make_egress_pool { name = ‘warm’, entries = pool_ips }
kumo.on(‘smtp_client_rewrite_delivery_status’, function(…) end)

Where MCSNET fits

MCSNET sits on the outbound half — KumoMTA’s side — and that is the honest scope. It hosts KumoMTA as a managed dedicated server in Toronto, with installation, Lua configuration, IP warming, authentication, and deliverability monitoring handled, so high-volume outbound sending arrives turnkey on owned IPs. For a sender whose problem is reaching the inbox at scale, that managed engine is the fit, and it removes the operational weight that running a deliverability engine otherwise carries. What MCSNET does not do is run Haraka’s inbound, filtering, or gateway roles — those are a different job, and an honest answer says so. If your architecture uses both, Haraka inbound and KumoMTA outbound, MCSNET handles the outbound engine while your Haraka layer does its own work; the two are complementary, and only the sending half is MCSNET’s to run. The managed build, with KumoMTA on the same basis as PowerMTA, is on the PowerMTA server hosting page.

The complementary architecture is worth drawing out, because it is often the most accurate reading of a real setup rather than a forced either-or. A company might run Haraka at its edge to accept inbound mail, apply JavaScript filtering, and route or forward it, while sending all of its outbound campaigns and transactional traffic through KumoMTA on owned, warmed IPs. In that picture the two are not competitors at all; they are the receiving and sending halves of one system, each chosen for what it does best. MCSNET’s role lands cleanly on the sending half — it runs the KumoMTA engine, warms and monitors the IPs, and keeps the data in Canada — and leaves the Haraka layer to the team that built it. That division is the honest one: a managed provider should run the part where its specialization compounds, which for outbound is reputation and deliverability, and stay out of the part that is the customer’s own SMTP logic. Read that way, choosing KumoMTA for sending does not rule out Haraka for everything else; it just puts the right tool on each side of the flow.

Which should you pick?

A practical test: decide whether your problem is outbound deliverability or general SMTP processing. High-volume sending that must land points to KumoMTA; inbound filtering, gateways, submission, or custom JavaScript SMTP logic points to Haraka. Because they specialize at opposite ends, the honest answer is sometimes both — and where it is outbound, hosting KumoMTA managed turns the specialized engine into something you can use without operating it yourself.

Common questions

What is the difference between KumoMTA and Haraka?

KumoMTA is a purpose-built outbound sending engine in Rust, designed for high-volume deliverability — traffic shaping, IP pools, per-ISP throttling, warm-up — and it is outbound only. Haraka is a flexible general-purpose SMTP server in Node.js whose defining feature is a JavaScript plugin system; it handles inbound and outbound and shines as a filtering MTA or gateway. Both are high-performance and open-source, but they specialize at opposite ends.

Can Haraka send bulk email like KumoMTA?

It can send outbound — it has a built-in delivery engine — but it is not specialized for high-volume bulk deliverability the way KumoMTA is. Haraka lacks the dedicated IP-pool management, per-ISP shaping, and warm-up tooling that are KumoMTA’s reason to exist. For serious outbound where inbox placement at scale matters, KumoMTA is the specialized tool.

Does KumoMTA handle inbound mail?

No. KumoMTA is outbound only — it sends, it does not receive. To accept, filter, or route inbound mail, that is Haraka’s territory. The two can be complementary: Haraka for inbound filtering and gateway duties, KumoMTA for high-volume outbound delivery.

Which is easier to customize?

Haraka, if you write JavaScript — its plugin system turns most custom behaviour into a small JS file hooked into an SMTP stage. KumoMTA is highly configurable through Lua policy, but its flexibility targets deliverability tuning rather than general SMTP behaviour. The right kind of flexibility depends on whether your need is sending policy or SMTP-level logic.

Can MCSNET run KumoMTA for my outbound sending?

Yes. MCSNET hosts KumoMTA managed in Toronto — installation, Lua configuration, IP warm-up, authentication, and monitoring included — covering the outbound, high-volume sending half. It does not run Haraka’s inbound/gateway role; for serious outbound deliverability with owned IPs and data in Canada under PIPEDA, the managed KumoMTA engine is the fit.