# KumoMTA is a mail transfer agent built for sending, not for receiving

> KumoMTA is an Apache-2.0 Rust message transfer agent for high-volume outbound email, positioned as an open-source alternative to commercial on-premise MTAs such as Momentum, PowerMTA and Halon, with a policy engine written in Lua, DKIM signing and a webhook-shaped event system. It suits experienced email operations teams, and the documentation is explicit that it is not a tool for a small site that wants to send a few thousand newsletters.

**KumoCorp/kumomta** — The first Open-Source  high-performance MTA developed from the ground-up for high-volume email sending environments.

- Repository: https://github.com/KumoCorp/kumomta
- Website: https://kumomta.com
- Stars: 561 · Forks: 118
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/kumocorp-kumomta

## An outbound MTA, compared against the commercial on-premise ones

The positioning is direct in the readme. KumoMTA is an open-source Message Transfer Agent designed for high-performance outbound email functionality, similar to commercial enterprise MTAs such as Momentum, PowerMTA and Halon. Those three names define the design target precisely, because they are the products sold to organisations that run their own mail infrastructure for a reason, usually deliverability at volume, sometimes regulatory or data residency requirements. The project states that it was founded by a group of email industry veterans with decades of experience building and managing high-performance on-premise MTAs, and that it is supported by a community of some of the largest senders in the world. So the expectation being set is a serious infrastructure component written by people who have operated the thing it replaces, not a weekend project that talks SMTP.

## Policy and decisions are written in Lua, not in Rust

The most distinctive structural decision is that the operational logic is not in the compiled language. The repository root holds a simple_policy.lua file and a sink.lua file, and the Makefile has a test-lua target that runs a run-lua-tests crate, which tells you that the Lua layer is a tested surface rather than a scripting afterthought. The reasoning is a familiar one in mail infrastructure. Scheduling, throttling, bouncing, suppression and routing are the parts of an MTA that change most often and differ most between operators, and putting them in an interpreted language means a delivery engineer can change them without a Rust build cycle. The Rust side does the things that need to be fast and correct, and the Lua side expresses the rules. The cost is that you now have two languages and two deployment surfaces to reason about, and the Lua code has to be treated as production code.

## The workspace is a set of small crates, each with one job

The Cargo workspace lists around sixty members, and reading the names tells you what the system does. There is a mailexchanger crate and a spool crate for the queue, a tailer and a timeq for scheduling, a throttle crate for rate control, a bounce-classify crate and a validate-bounces crate, plus a kumo-dmarc crate and a mta-sts crate for the modern sender-side authentication and policy standards, and a kumo-spf crate for the SPF side. There is a dir-probe and a tls-probe, a domain-map and a cidr-map for the routing tables, a kumo-template crate for the message templating that the topics list under email-template, and a kumo-prometheus crate for metrics. A proxy-server, a kumo-api-client and a kcli crate sit alongside, which is the shape of a service with a control API rather than a library. The release profile turns on opt-level 3 with debug information left in so that backtraces are meaningful, a small choice that tells you the authors expect this to run in production and crash sometimes.

## DKIM keys are shipped as examples, and the queue lives on disk

Two implementation details in the file listing tell you how the system is operated. The first is that the repository includes example-private-dkim-key.pem and example-public-dkim-key.pem at the top level, which are the example keys, and their presence tells you the signing keys are expected to be replaced with your own before you send anything. The second is the spool crate, which is the on-disk queue, together with a spool-util binary that the Makefile builds as a separate target, so operators can inspect and manipulate the queue outside the daemon. The crate list also includes a kumo-counter-series and a mod-counter-series for metrics, a mailparsing crate, an rfc5321 crate, and a mpsc crate, which points to a design where the hot path is a bounded channel between stages rather than shared state. A developer's guide is included as DEVELOPERS.md, and a SECURITY.md sits at the root.

## The Makefile shows which binaries actually ship

The build file is the clearest documentation of the deployment shape, because it names the executables one by one. The default build target compiles kumod, which is the daemon, then tsa-daemon, then kcli, then validate-shaping, proxy-server, spool-util, tailer, traffic-gen, toml2jsonc, tls-probe and fault-inject-preload.

```bash
build:
	cargo build $(BUILD_OPTS) -p kumod
	cargo build $(BUILD_OPTS) -p tsa-daemon
	cargo build $(BUILD_OPTS) -p kcli
```

Several of those are tools rather than services, and each one tells you something about the operating model. spool-util is for working with the queue, tailer is for following it, traffic-gen is for putting load on the system, tls-probe for checking what a remote endpoint negotiates, validate-shaping for checking a policy before you deploy it, and fault-inject-preload for testing failure handling. The Makefile also picks up environment variables from an optional .make-env file, and the comment on that suggests setting ROCKSDB_LIB_DIR on Ubuntu to speed up the build of the rocksdb crate, which confirms that a key-value store sits under the queue. There is a docs/update-openapi.sh script in the test target, so the HTTP API is documented as generated output rather than by hand.

## Docker examples cover single node, Swarm and a smart sink

The examples directory holds three Docker setups, and the naming tells you the deployment story. There is a single-node-docker example, a docker-swarm example, and a smart-sink-docker example. The single node case is the entry point, the Swarm case covers running a scaled deployment across a cluster, and the smart sink case is the interesting one for an MTA, because a sink is the component that actually delivers the message onward. The repository also has a docker directory, a Dockerfile at the root and a set of assets including a ci directory with scripts for building builder images and emitting a builder Dockerfile. There is a get-deps.sh script for fetching dependencies, a rust-toolchain.toml pinning the toolchain, and both selene.toml and stylua.toml for the Lua layer, which confirms that the Lua code is linted and formatted as first class source. A run-lua-tests crate exists to execute it.

## Where KumoMTA is the wrong choice

The first wrong case is a small site sending transactional mail, because a full message transfer agent with a spool, a policy engine and a set of operational binaries is a lot of surface for a job that a hosted API handles in an afternoon. The second is a team that wants to receive and manage mail, since this is an outbound system and the readme is explicit about high-performance outbound email functionality, so it is the wrong half of a mail platform. The third is a team without operations experience, because the project says outright that it is for people accustomed to high-performance sending environments and familiar with DevOps practices, and that expectation is a warning rather than a boast. The fourth is a project that cannot run a persistent daemon, since the queueing model implies a long-lived process with on-disk state, which does not fit a serverless function. The fifth is an organisation that needs a commercial support contract or a roadmap commitment, because the readme points paid support at the vendor site and says issues are for features and bugs only with help requests closed, which tells you the open source repository is a community channel rather than a support desk.

## Conclusion

Email operations teams that run their own sending infrastructure, that already understand deliverability and that want to own the queueing and policy layer rather than rent it, are the people KumoMTA is for, and the Lua policy engine plus the event system are the parts that make it an operations tool rather than a sending library. It is the wrong choice for a small site sending occasional transactional mail, because the project describes itself as being for experienced email operations professionals accustomed to high-performance sending environments and familiar with DevOps practices, and that is a fair description of who it is built for. Check three things before you commit: that you can run a queueing daemon in your own environment rather than hand the whole job to a provider, that the Lua policy layer fits how your team wants to express scheduling, throttling and suppression, and how the DKIM signing keys are managed, since the repository ships example public and private key files that are for testing rather than production. The licence is Apache-2.0, the last push was on 2026-10-19, and the project publishes date-based tags rather than numbered releases.

## FAQ

### What is KumoMTA and who is it for?

It is an open-source Message Transfer Agent in Rust, designed for high-performance outbound email functionality, similar to the commercial enterprise MTAs Momentum, PowerMTA and Halon. The documentation says it is for experienced email operations professionals who are accustomed to high-performance sending environments and familiar with DevOps practices.

### Why does KumoMTA use Lua for part of its logic?

The repository ships a simple_policy.lua and a sink.lua at the root, and the Makefile has a test-lua target that runs a run-lua-tests crate, so the Lua layer is a tested part of the system rather than an afterthought. It keeps the operational rules, such as scheduling and shaping, separate from the compiled core.

### Which binaries does KumoMTA build?

The build target compiles kumod, the daemon, plus tsa-daemon, kcli, validate-shaping, proxy-server, spool-util, tailer, traffic-gen, toml2jsonc, tls-probe and fault-inject-preload. The tool binaries cover queue inspection, load generation, TLS probing and policy validation.

### How is DKIM signing configured in KumoMTA?

The repository includes example-public-dkim-key.pem and example-private-dkim-key.pem at the top level, which are the example keys, and the kumo-dmarc crate implements DMARC handling on the sending side. The example keys are for testing rather than production use.

### How do I get help with KumoMTA?

The readme points to a FAQ and a documentation site for the user guide, a Discord for real-time discussion with a #devel channel for contributors, and the developers guide in DEVELOPERS.md. Issues are for features and bugs only, help requests posted there are closed, and paid support is offered separately.

## Sources

- [KumoCorp/kumomta on GitHub](https://github.com/KumoCorp/kumomta)
- [License: Apache-2.0](https://github.com/KumoCorp/kumomta/blob/main/LICENSE)
- [Project website](https://kumomta.com)
- [README](https://github.com/KumoCorp/kumomta/blob/main/README.md)
- [Releases](https://github.com/KumoCorp/kumomta/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kumocorp-kumomta