KumoMTA and KumoProxy
Prepare KumoProxy

Prepare A KumoProxy Host

KumoProxy is optional. Use it when your KumoMTA host should send through a separate egress host or IP pool.

When KumoProxy helps

  • Your control-plane provider blocks direct outbound mail.
  • You want recipient providers to see a different controlled IP.
  • You need to share egress IPs across multiple KumoMTA hosts.
  • You want to isolate reputation by egress host.

Host checklist

  • Static public IP.
  • PTR/rDNS set to the egress hostname, such as proxy.yourdomain.com.
  • Firewall allows only trusted KumoMTA hosts to connect to the SOCKS5 port.
  • System limits are tuned for connection volume.
  • Service restarts automatically.
  • Metrics are restricted.

KumoProxy affects sender reputation because recipient providers see the egress IP path. Treat the proxy host as part of your sending identity, not as a generic network utility.

Example service shape

Use your KumoMTA installation method to run the proxy server as a managed service. The service should listen only where KumoMTA can reach it.

listen: 10.0.0.20:5000
allowed_clients:
  - 10.0.0.10

Replace the private IPs with your internal network addresses.

Validate egress

Before production traffic:

  1. Confirm KumoMTA can connect to KumoProxy.
  2. Confirm provider firewalls allow outbound SMTP from the proxy host.
  3. Confirm recipient providers see the proxy IP as the source.
  4. Confirm SPF authorizes the source IP.
  5. Confirm PTR/rDNS matches the egress hostname.

Common mistakes

  • Authorizing the KumoMTA host IP in SPF when recipients actually see the proxy IP.
  • Leaving the proxy port open to the internet.
  • Sharing one proxy across unrelated brands without reputation isolation.
  • Forgetting PTR/rDNS on the proxy egress IP.
  • Increasing send volume before deferral and complaint behavior is known.

Next configuration pages

Prepare KumoMTADNS and TLS