KumoMTA vs Postfix

The honest comparison is general-purpose against purpose-built

What is the real difference?

The gap shows up in two places: scope and shaping. Postfix is designed to do many mail jobs adequately, which is a strength when you want one tool for everything and a limitation when one of those jobs — high-volume outbound — outgrows the rest. Its per-destination controls exist, but they are coarse next to an engine built specifically for bulk delivery. KumoMTA narrows its scope to outbound on purpose, and spends that focus on fine control: how it paces each provider, how it backs off on deferrals, how it isolates streams.

The second difference is how that control is expressed. Postfix puts it in static configuration files — predictable, easy to read, the same every run. KumoMTA puts it in Lua policy, so a shaping or routing decision can depend on whatever logic you write and can be reviewed and versioned like any other code. For a small, stable mail server the static model is a virtue; for a sending operation that changes and grows, policy-as-code earns its keep.

How each one shapes traffic to a provider

To pace sending to a single provider, Postfix uses static per-transport settings: you declare a concurrency limit and a rate delay in configuration, the same for every message on that route. The snippet below shows that approach. KumoMTA reaches the same outcome through Lua policy evaluated per message, so the pacing can adapt to context rather than being fixed in a file.

# Postfix main.cf — per-transport pacing is static
# (illustrative: one fixed rule per destination class)

default_destination_concurrency_limit = 20
default_destination_rate_delay        = 1s

# a dedicated transport for one provider, tuned by hand
gmail_destination_concurrency_limit   = 10
gmail_destination_rate_delay          = 0s

# master.cf
# gmail   unix  -  -  n  -  -  smtp

This works, and for moderate volume it works well. The strain appears at scale, when every provider wants different pacing that shifts with your reputation and their mood that day. Tuning that by editing static files for dozens of destinations is the manual work KumoMTA’s policy model is designed to absorb — the same job, expressed as logic instead of as a growing list of fixed entries.

The point where Postfix gives way

Think of it as a single road with a bend in it. From low volume up to roughly half a million messages a day, Postfix carries you comfortably and a move would be wasted effort. Around that point the cost of holding outbound reputation by hand starts to rise, and an engine built for the job — KumoMTA — takes the load off. The bend is gradual, not a wall; the diagram marks where most senders feel it.

We run both, and we will tell you to stay put when that is right

Because neither engine carries a licence and we operate both as managed infrastructure, we gain nothing by pushing you to migrate. A low-volume sender keeps a tuned Postfix and our honest advice is to leave it alone; a sender whose outbound has outgrown it gets KumoMTA on the stream that needs it, often alongside the Postfix that still handles everything else. The recommendation tracks your volume, not a sale.

What we add underneath either choice is the part that is hard to assemble yourself: 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 is a free choice between two good open-source options; the dedicated, sovereign, operated base it runs on is the differentiator. For how this pair sits among the others, the MTA comparison hub places Postfix and KumoMTA alongside Exim, PowerMTA, Halon and MailerQ.