KumoMTA: What It Is and Who It's For

What Is KumoMTA

KumoMTA is an open-source mail transfer agent written in Rust, designed for high-volume email sending. It was created by engineers who previously worked on PowerMTA, bringing enterprise-grade email infrastructure to the open-source world.

The "Kumo" name comes from the Japanese word for cloud, reflecting its design for modern cloud infrastructure. Unlike traditional MTAs that grew from the Unix mail system era, KumoMTA was built from scratch for the challenges of sending millions of marketing and transactional emails.

Who Should Use KumoMTA

Good fit:

• Organizations sending 500K+ emails/day
• ESPs and email marketing platforms building their own infrastructure
• Companies replacing expensive PowerMTA licenses
• Teams that need per-tenant or per-campaign queue isolation
• Anyone building a multi-tenant email platform

Not ideal for:

• Small senders under 100K emails/day (Postfix via Mailcow is simpler)
• Those who need proven enterprise support contracts (PowerMTA)
• Simple transactional email needs (consider Postmark or SendGrid)
• Teams without Linux sysadmin experience

Practitioner note: I recommend KumoMTA for clients who've outgrown Postfix but can't justify PowerMTA licensing (see our MTA comparison). The sweet spot is 500K to 5M emails/day. Below that, Postfix works fine. Above that, you might want PowerMTA's enterprise support.

Key Features

Lua-Based Configuration

Unlike Postfix's flat configuration files, KumoMTA uses Lua scripts for configuration. This means you can write actual logic:

-- Traffic shaping based on domain
kumo.on('smtp_server_ehlo', function(domain)
  if domain:find('gmail.com') then
    return {
      max_connection_rate = '10/minute',
      max_deliveries_per_connection = 20
    }
  end
end)

Per-Tenant Queue Isolation

If you're building a multi-tenant platform, each customer gets isolated queues:

kumo.on('get_queue_config', function(domain, tenant)
  return {
    queue_name = tenant .. '-' .. domain,
    -- Each tenant's traffic is independent
  }
end)

This prevents one tenant's reputation problems from affecting others.

Traffic Shaping

KumoMTA shapes traffic per-destination automatically:

• Connection limits: How many simultaneous connections per domain
• Rate limits: Messages per minute/hour/day
• Throttling: Automatic backoff when receiving 4xx responses
• Warmup: Gradual volume increase for new IPs

HTTP API

Everything is API-accessible:

# Inject a message
curl -X POST http://localhost:8000/api/inject \
  -H "Content-Type: application/json" \
  -d '{"from": "[email protected]", "to": ["[email protected]"], "body": "..."}'

# Check queue status
curl http://localhost:8000/api/queues

# Pause a queue
curl -X POST http://localhost:8000/api/queues/pause -d '{"queue": "marketing"}'

Event Webhooks

Get real-time delivery notifications:

kumo.on('delivery_complete', function(msg, result)
  -- POST to your webhook endpoint
  http.post('https://your-app.com/webhooks/email', {
    message_id = msg:id(),
    status = result.status,
    response = result.response
  })
end)

KumoMTA vs Other MTAs

Feature	KumoMTA	Postfix	PowerMTA	Halon
License	Open source	Open source	Commercial	Commercial
Volume	Millions/hour	Millions/day*	Millions/hour	Millions/hour
Configuration	Lua scripts	Flat files	Flat files	Lua scripts
Multi-tenant	Built-in	Manual	Built-in	Built-in
Traffic shaping	Built-in	Manual	Built-in	Built-in
API	HTTP REST	None	HTTP/CLI	HTTP REST
Support	Community/paid	Community	Enterprise	Enterprise

*With extensive tuning

Installation

KumoMTA runs on Linux (Ubuntu 20.04+, Rocky Linux 8+). Basic installation:

# Add the repository
curl -fsSL https://repos.kumomta.com/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/kumomta.gpg
echo "deb [signed-by=/usr/share/keyrings/kumomta.gpg] https://repos.kumomta.com/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/kumomta.list

# Install
sudo apt update
sudo apt install kumomta

# Start
sudo systemctl enable kumomta
sudo systemctl start kumomta

Practitioner note: KumoMTA's installation is straightforward, but the real work is in the Lua configuration. Plan to spend a day or two getting familiar with the scripting model before deploying to production. The documentation is solid but assumes you understand email infrastructure concepts.

Basic Configuration

Create /opt/kumomta/etc/policy/init.lua:

-- Basic listener
kumo.start_esmtp_listener {
  listen = '0.0.0.0:25',
  relay_hosts = { '127.0.0.1', '10.0.0.0/8' }
}

-- HTTP API
kumo.start_http_listener {
  listen = '0.0.0.0:8000'
}

-- Traffic shaping defaults
kumo.on('get_egress_path_config', function(domain)
  return {
    max_connection_rate = '100/minute',
    max_deliveries_per_connection = 100,
    max_message_rate = '1000/minute'
  }
end)

-- Logging
kumo.on('delivery_complete', function(msg, result)
  kumo.log(result.status .. ': ' .. msg:recipient())
end)

Performance Considerations

KumoMTA is designed for performance:

• Memory: Uses streaming where possible; doesn't buffer entire messages
• CPU: Rust's efficiency means lower CPU per message than interpreted languages
• I/O: Asynchronous I/O handles thousands of concurrent connections
• Queue: On-disk queuing with memory-mapped files for speed

Typical hardware requirements:

• 500K/day: 2 CPU, 4GB RAM, SSD storage
• 5M/day: 8 CPU, 16GB RAM, NVMe storage
• 50M/day: Multiple servers with load balancing

Migration from Postfix

If you're running Postfix and considering KumoMTA:

1. Run in parallel first: Set up KumoMTA alongside Postfix
2. Migrate one stream: Move marketing email first, keep transactional on Postfix
3. Monitor closely: Compare delivery rates between the two
4. Full cutover: Once confident, migrate all traffic

The configuration paradigm is completely different, so don't expect to "translate" your Postfix config. You're rebuilding from scratch with new capabilities.

When to Choose Something Else

Choose Postfix if:

• Volume under 500K/day
• Simple single-tenant use case
• Team is already Postfix-expert
• You need something proven over decades

Choose PowerMTA if:

• You need enterprise support contracts
• Compliance requires proven, audited software
• Team is already PowerMTA-trained

Choose a hosted service if:

• You don't want to manage infrastructure
• Volume under 1M/day (cost makes sense)
• You need deliverability support included

If you're evaluating MTAs for your email infrastructure and need help determining whether KumoMTA, Postfix, or a commercial solution fits your needs, schedule a consultation.

Sources

• KumoMTA Official Documentation: docs.kumomta.com
• KumoMTA GitHub Repository: github.com/KumomtaProject/kumomta
• Apache 2.0 License: opensource.org/licenses/Apache-2.0
• PowerMTA Documentation (for comparison): port25.com/support

---

v1.0 · March 2026