Module 1 · Lesson 2 of 25

The MTA landscape and where Kumo fits

Part of KumoMTA: High-Volume Sending Engine — Introduction to KumoMTA.

Three families of MTAs in 2026:

1. General-purpose (Postfix, Exim, Sendmail). Receive, queue, deliver. Fine for a few thousand emails/day. Hard to tune for huge volume — no native per-destination concurrency, weak observability.

2. Sending engines (KumoMTA, PowerMTA, Halon, MailerQ). Built for outbound only. Per-destination queues, IP pools, warmup curves, bounce processing, FBL ingestion. This is the bulk-sender category.

3. Cloud APIs (SendGrid, Postmark, Amazon SES). You hand off via HTTPS or SMTP-relay. They handle MTA + IPs + reputation. Easy at low scale, expensive at high scale, less control.

Where Kumo wins:

  • You're shipping >100k msgs/day and SendGrid pricing hurts.
  • You need per-domain throttling that respects Gmail's 250/sec or Yahoo's 100/sec.
  • You want to own your IPs and reputation.
  • You want hot-reload config without restarts.

Where you should NOT use Kumo:

  • You ship <10k msgs/day. Use SES or a Postfix relay; the operational overhead isn't worth it.
  • You also need to receive mail. Pair with Postfix or just don't.

Sign in to keep track of what you have read.

Pulse · self-hosted sending

Own the infrastructure your pipeline depends on.

One install script on your own server. Pulse sets up the MTA, mailboxes, certificates and dashboard; you add domains and start sending.

# on a fresh Ubuntu server
$ cd pulse && sudo ./install.sh
→ docker compose up · kumomta · stalwart · caddy
→ dashboard ready on https://pulse.yourdomain.com
$

Also from us:Beat — monitoring that tells you the fixConsulting — $65/hr, no retainer