Open source has no support line. We are the team you call.

How do you operate KumoMTA with no web console?

KumoMTA ships no web console, and that is a deliberate design choice rather than an oversight: the project exposes data and leaves the interface to operators, on the reasoning that every team wants something different. For a team arriving from PowerMTA’s built-in monitor, that is a real gap on day one — the queue view, the VirtualMTA status, the at-a-glance health they were used to is simply not there out of the box.

What is there is better raw material. KumoMTA exports more than a hundred Prometheus metrics natively, at standard endpoints, covering queue depths, delivery and bounce rates, latency percentiles and system health, and there are pre-built Grafana dashboards ready to consume them. For a team already running Prometheus and Grafana, the monitoring is close to zero-configuration; for everyone else, that endpoint is a universal integration point into whatever observability platform they prefer. Closing the interface gap is one of the first things we do: we stand up the dashboards, define the alerts that matter, and where a client wants a managed view rather than a Grafana login, an optional control panel. The result is that moving to a more capable engine does not cost you visibility — you trade a bundled monitor for observability that is genuinely deeper, without having to build it yourself.

Does Traffic Shaping Automation mean KumoMTA runs itself?

The feature that most defines operating KumoMTA is Traffic Shaping Automation, the TSA daemon. It runs as its own service alongside the main engine, watching the responses providers send back — the temporary deferrals and permanent rejections — and adjusting the engine’s traffic-shaping rules in real time to stay within what each mailbox provider will tolerate. It is the difference between a static throttle that is wrong the moment a provider changes behaviour and a shaping policy that follows the provider as it moves.

That power comes with operational weight. TSA is configured across the engine’s init policy and the daemon’s own configuration, it merges a community-maintained shaping dataset with custom rules you define for your specific senders, and in a clustered deployment every node has to publish to and subscribe from the daemons correctly, with fault tolerance designed in. Run well, it is a genuine advantage that reacts faster than any human could. Run carelessly — a daemon that silently stopped, community rules that do not fit your sending, a cluster wired so one node is shaping blind — and it becomes a source of problems rather than a solution to them. Operating it properly means keeping the daemon healthy, layering shaping rules that match your actual traffic, and confirming through monitoring that it is reacting the way it should.

# Is the TSA daemon alive and reacting? (a silent daemon is a hidden outage)
$ systemctl is-active kumo-tsa-daemon && kcli tsa-status --summary
active · 3 rules firing · last adjustment 40s ago · cluster: 3/3 nodes subscribed

# Are queues draining and reputation holding across providers?
$ kcli queue-summary --by-site --top 3
gmail.com    D 41920  Q 18   deferral-rate 0.4%   OK
outlook.com  D 28110  Q  0   deferral-rate 0.1%   OK
yahoo.com    D 15044  Q  6   deferral-rate 0.3%   OK

# Alerting fires before you would ever notice — this is the quiet you pay for

Clustering and scale, operated

KumoMTA handles millions of messages an hour on a single server, so many senders never need more than one well-run node. When volume does outgrow that, the engine scales horizontally — more nodes, orchestrated with Docker or Kubernetes — and the operational picture changes with it. A cluster is not just several copies of one server; it is a system whose parts have to coordinate, and the coordination is where careful operation earns its place.

Traffic Shaping Automation is the clearest example. On a single node the daemon watches one engine and adjusts it. In a cluster, every node has to publish its provider responses to the daemons and subscribe to the shaping decisions that come back, so the whole estate shapes traffic as one coordinated sender rather than as a handful of nodes each guessing independently. Get that wiring wrong and one node shapes blind, sending into a provider the rest of the cluster already knows is deferring. We design the topology — a daemon per node or shared daemons, with a load balancer in front for fault tolerance so losing one daemon does not stop the cluster shaping — and operate it as a unit. Scaling, in other words, is not just adding machines; it is keeping a growing number of moving parts behaving like a single, coherent estate, which is operational work rather than a one-time architecture decision.

Integrations and the data pipeline

One of KumoMTA’s strengths is how openly it connects to the rest of a stack. Delivery and engagement events can flow out through webhooks, AMQP or Kafka into whatever data pipeline you already run, and policy can read directly from your databases, a secrets store like Vault, or other live sources through Lua hooks. For a data-driven sender that means the MTA stops being a black box at the edge of the system and becomes a participant in it — bounces, complaints and deliveries landing in the same warehouse as everything else, in close to real time.

Those integrations are powerful, and they are also moving parts that break quietly when a schema changes or an endpoint moves. Part of operating the estate is keeping them wired correctly and confirming the events are actually flowing, so the dashboards and downstream systems that depend on them are not silently working from stale data. We build the connections a sender needs and keep them honest, rather than leaving a feed that worked on launch day to rot.

Configuration as code is a discipline

KumoMTA’s configuration-as-code model is one of its real strengths and one of its real demands. Because policy is written in Lua rather than set in a static file, a change to how mail is routed, throttled or signed is a change to code — and it deserves the discipline code gets. We keep configuration in version control, review changes before they ship, and test them away from production rather than editing a live policy and watching what happens.

The reason is not bureaucracy; it is that Lua gives you enough power to cause real damage. Concurrency handled wrongly, a policy structured badly, a hook that reaches into a database without care — these are bugs, and on a production MTA a bug is a deliverability incident. Treating configuration as software, with the safeguards software has earned over decades, is what keeps that power an asset. A team operating KumoMTA by editing files directly on the box is one typo away from an outage; an estate operated as code is not.

Warmup and reputation, semi-automated

One of KumoMTA’s nicer properties is that warmup logic can be written into the configuration itself, adjusting sending volumes by IP age, historical performance, or whatever criteria you define, and combined with the TSA daemon’s real-time response to provider signals, warmup becomes substantially automated. That is a meaningful improvement over manually editing a config file every day of a ramp.

It is not, and we will not pretend it is, push-button simple. You still have to understand warmup principles, design schedules that fit the volume you genuinely have, and watch the results against real placement rather than trusting the automation blindly. Reputation is still earned slowly and lost quickly, and the automation executes a strategy — it does not invent one. So warmup under management is the encoded ramp doing the repetitive work, with an experienced eye setting the policy and watching the outcome. The automation removes the tedium; it does not remove the need for someone who knows what good looks like.

Can you take over a KumoMTA estate someone else set up?

Not every managed engagement starts from a migration we ran. A common one is taking over a KumoMTA estate someone else built — an in-house team that has moved on, a previous contractor, an install that worked at launch and has drifted since. We start these the same way every time: with an audit before any change. We read the existing Lua configuration, the TSA setup, whatever monitoring exists and the current reputation, so we understand exactly what we are inheriting rather than assuming it matches the documentation, if there is any.

What the audit turns up is fairly predictable. The install usually works, but it is often under-observed — metrics exposed and nobody watching them — or it carries a configuration translated literally from an old PowerMTA setup and never adapted to how KumoMTA actually wants to run. Sometimes the TSA daemon is misconfigured or quietly stopped, and the estate has been shaping traffic with stale rules for weeks. We stabilise first, bringing observation and shaping back to a healthy baseline, then improve from there in reviewed, version-controlled steps rather than rebuilding for its own sake. The goal of an onboarding is that the estate becomes legible and reliable, not that it becomes ours; an estate we could not hand back cleanly is one we operated badly.

What does managed KumoMTA operation include?

Pulling it together, this is the scope of a managed KumoMTA engagement. Not every client needs every item from day one, but each is part of what keeping a KumoMTA estate healthy actually requires.

• Monitoring and alerting on queues, delivery, deferrals, bounces and reputation, around the clock
• Configuration maintenance — Lua policy changes, reviewed and tested before they reach production
• Traffic Shaping Automation tuning, including custom rules layered over the community shaping data
• Warmup design and execution for new IPs and domains, measured against placement
• Authentication upkeep — DKIM, SPF, DMARC and the DNS that supports them
• Deliverability work: placement testing, provider relationships, reputation recovery
• Version upgrades and security patching on a controlled schedule
• Incident response when a provider blocks, a queue backs up or a listing appears
• Scaling support as volume grows, from a single node to a monitored cluster

The goal is an estate that runs quietly

The measure of managed operation done well is how little you have to think about it. The aim is not a flurry of visible activity; it is an estate that sends what it should, lands where it should, and rarely demands your attention — the state where the MTA becomes the part of the stack the team spends the least time on, because it quietly works. When something does go wrong, an experienced team is already watching and already responding, often before it reaches your inbox as a problem. Open-source software gives you the engine and the freedom. Managed operation gives you the quiet that makes that freedom worth having.

Because problems do not keep office hours, neither does the operation. Our team spans European, North American and Latin American time zones, so an alert that fires overnight reaches someone who can act on it rather than a queue that waits until morning — which, with reputation, is the difference between a non-event and an incident. The point of paying for operation rather than software is exactly this: that there is always someone whose job it is to be watching, and to move before a wobble becomes a problem you hear about from your own customers. There is a quieter economic argument underneath all of this, too. The licence fee that open source removes was always the visible cost; the invisible one is the senior engineering time a capable in-house operator would spend on call, on upgrades and on deliverability firefighting, time that rarely shows up on a budget line until an incident makes it impossible to ignore. Managed operation converts that unpredictable, lumpy cost into a known one, and frees the engineers you already employ to work on the product rather than on keeping the mail flowing.