Module 4 · Lesson 8 of 25

Scheduled queues = tenant × destination

Part of KumoMTA: High-Volume Sending Engine — Queues, Scheduling & Traffic Shaping.

Every accepted message lands in a scheduled queue keyed by (tenant, campaign, destination_domain). Each queue has its own throttle, retry schedule, and source IP pool.

Define queue config dynamically:

kumo.on('get_queue_config', function(domain, tenant, campaign, routing_domain)
  -- Defaults
  local cfg = {
    max_age = '24h',
    retry_interval = '20m',
    max_retry_interval = '4h',
    max_connection_rate = '5/s',
  }

  -- Gmail tightening
  if domain == 'gmail.com' or domain:match('%.googlemail%.com$') then
    cfg.max_connection_rate = '20/s'
    cfg.max_message_rate    = '250/s'
  end

  -- Microsoft 365 tightening
  if domain:match('%.protection%.outlook%.com$') then
    cfg.max_connection_rate = '4/s'
    cfg.max_message_rate    = '40/s'
  end

  return kumo.make_queue_config(cfg)
end)

Retry curves are exponential by default. Tune retry_interval (first retry) and max_retry_interval (cap). Production rule of thumb: 5 min → 30 min → 2 h → 4 h, max age 24–48 h.

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