🚀 How to Deploy KumoMTA on Rocky Linux VPS (Easy Step-by-Step Guide)

This is a practical “get it running” guide demonstrating how to deploy KumoMTA on Rocky Linux VPS.

What is KumoMTA?

KumoMTA is a modern, high-performance Mail Transfer Agent (MTA) designed for large-scale, high-volume email delivery with a strong focus on deliverability, policy control, and automation.

Pre-requisites

• Rocky Linux 8/Rocky Linux 9 fresh install
• You have root (or sudo) access.
• You have a hostname you control (View: How to Point a Domain to Your VPS Server).
• You want KumoMTA to send mail reliably (not just “it starts”).

Notes up front (important in real life):

• Many email deliverability problems are DNS + reputation, not MTA configuration.
• Outbound SMTP is often blocked by VPS providers by default—confirm port 25 policy early. Rad Web Hosting supports compliant outbound SMTP by default.

Recommended Server Specs

🚀 How to Deploy KumoMTA on Rocky Linux VPS

• Prep the VPS (system update, tools, time sync)

  sudo dnf -y update
  sudo dnf -y install curl wget tar unzip jq nano firewalld policycoreutils-python-utils bind-utils
  sudo systemctl enable --now firewalld
  

  Make sure time is correct (SMTP + TLS can get weird if time is wrong):

  sudo dnf -y install chrony
  sudo systemctl enable --now chronyd
  timedatectl status
  

• Set hostname + verify reverse DNS (PTR)

  Set a proper hostname (example: mta1.example.com):

  sudo hostnamectl set-hostname mta1.example.com
  hostnamectl
  

  Reverse DNS (PTR) must match your hostname:

  • Your VPS provider controls PTR. (View: Guide for Rad Web Hosting IPs)
  • Set PTR of your server IP → mta1.example.com
  • Ensure mta1.example.com A record → your server IP

  Quick checks:

  hostname -f
  dig +short mta1.example.com A
  

• Open firewall ports you’ll actually use

  Typical ports:

  • 25/tcp SMTP (server-to-server)
  • 587/tcp Submission (authenticated clients)
  • 465/tcp SMTPS (optional legacy/client)
  • 443/tcp if you later expose a metrics endpoint behind a reverse proxy (optional)
  • 80/tcp only if you do HTTP challenges for TLS (optional)

  Open the basics:

  sudo firewall-cmd --zone=public --permanent --add-service=smtp
  sudo firewall-cmd --zone=public --permanent --add-port=465/tcp
  sudo firewall-cmd --zone=public --permanent --add-service=smtps
  sudo firewall-cmd --zone=public --permanent --add-service=http
  sudo firewall-cmd --zone=public --permanent --add-service=https
  sudo firewall-cmd --reload
  

• Confirm your provider allows outbound SMTP (Not Required if Using Rad Web Hosting VPS)

  Before you spend time installing anything:

  sudo dnf install nc -y
  nc -vz gmail-smtp-in.l.google.com 25
  

  If you see timeouts/refusals, your provider may block outbound 25. Options:

  • Request SMTP unblocking / mail enablement from provider
  • Use a smart host / relay (SES, Mailgun, etc.) for outbound
  • Use 587 to a relay (still needs proper SPF/DKIM)

• Install KumoMTA

  KumoMTA’s install method can vary by version (package repository vs tarball).

  A) Install from SSH

  1. SSH the VPS as root.
  2. Run the following commands to prepare the environment and install KumoMTA:

     sudo dnf clean all
     sudo dnf update -y
     sudo systemctl stop postfix.service
     sudo systemctl disable postfix.service
     sudo dnf -y install dnf-plugins-core
     sudo dnf config-manager \
         --add-repo \
         https://openrepo.kumomta.com/files/kumomta-rocky.repo
     sudo dnf install kumomta -y

  3. Enable and start the service:

     sudo systemctl start kumomta
     sudo systemctl enable kumomta

  B) Verify installation and service

  Once installed:

  sudo systemctl daemon-reload
  sudo systemctl enable --now kumomta || true
  sudo systemctl status kumomta --no-pager || true
  

• Create a dedicated user (optional but recommended)

  If KumoMTA supports/encourages running as its own user:

  sudo useradd --system --home /var/lib/kumomta --shell /sbin/nologin kumo 2>/dev/null || true
  

  Whether you do this depends on the official package/service unit defaults—don’t fight the vendor defaults unless you have a reason.

• Configure DNS for sending (SPF, DKIM, DMARC)

  This is non-negotiable if you care about inbox placement.

  A) SPF record

  For your sending domain (example.com), add:

  • If you send directly from your VPS IP:
  • v=spf1 ip4:YOUR_SERVER_IP -all

  If you also use another provider (like Google Workspace, SES, etc.), include them properly (don’t stack multiple SPF TXT records—use one).

  B) DKIM

  KumoMTA will typically generate DKIM keys per domain or per tenant. The exact config path/commands depend on Kumo’s layout.

  General flow:

  1. Generate DKIM key (selector like k1)
  2. Publish DNS TXT:
     • k1._domainkey.example.com → DKIM public key value
  3. Configure Kumo to sign outgoing mail for that domain using that selector/private key.

  C) DMARC

  Start with monitoring:

  • _dmarc.example.com TXT:
  • v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1; adkim=s; aspf=s

  Later, move to p=quarantine then p=reject after you’re confident.

• TLS certificates for submission (587/465)

  Even if server-to-server TLS uses STARTTLS opportunistically, you typically want a real cert for submission.

  Option A: Use Let’s Encrypt (recommended)

  You’ll need a public DNS record pointing to the server and typically port 80 open during issuance.

  Install certbot:

  sudo dnf -y install epel-release
  sudo dnf -y install certbot
  

  Stop anything using port 80 (if needed), then issue:

  sudo certbot certonly --standalone -d mta1.example.com
  

  Certs land in:

  • /etc/letsencrypt/live/mta1.example.com/fullchain.pem
  • /etc/letsencrypt/live/mta1.example.com/privkey.pem

  Then configure KumoMTA to use them for submission listeners (exact config depends on Kumo).

  Auto-renew:

  sudo systemctl enable --now certbot-renew.timer
  systemctl list-timers | grep certbot
  

  Option B: Use your own cert

  Just place cert + key somewhere readable by the Kumo service user and reference them in config.

• Core KumoMTA configuration checklist

  Kumo’s config style may be TOML/YAML/Lua/JSON depending on version—use their example config as your base. These are the things you must set:

  • Server identity
  • HELO/EHLO hostname: mta1.example.com
  • Listener ports
  • 25 (inbound SMTP)
  • 587 (submission, auth required)
  • 465 (optional)
  • Relay policy
  • Absolutely do not allow open relay
  • Require auth on submission
  • Restrict IPs allowed to submit if applicable
  • Queues + spool paths
  • Ensure adequate disk space
  • Put queues on fast disk if high volume
  • Logging
  • Set log location + rotation policy
  • DKIM signing
  • Per domain/tenant keys
  • Bounce handling
  • Set a return-path domain you control
  • Rate limiting + backoff
  • Protect your IP reputation and avoid remote throttling
  • Outbound IP binding
  • If you have multiple IPs, bind per tenant/domain

  After changes:

  sudo systemctl restart kumomta || true
  sudo systemctl status kumomta --no-pager || true
  

• SELinux considerations (Rocky default = enforcing)

  If KumoMTA binds to privileged ports or reads TLS keys, SELinux can block it.

  First, see what’s denied:

  sudo ausearch -m avc -ts recent | tail -n 50
  

  If you see blocks around reading /etc/letsencrypt/... or binding ports, you have options:

  • Use vendor-provided SELinux policy (best)
  • Adjust contexts for cert files
  • Create a minimal local policy module

  Example approach (only if you confirm SELinux is the blocker):

  sudo setenforce 0
  # test if it works
  sudo systemctl restart kumomta || true
  sudo setenforce 1
  

  If it works only with permissive, you need a real policy/label fix (don’t leave SELinux off long-term).

• Validate SMTP functionality

  A) Check listeners

  ss -lntp | egrep ':(25|465|587)\s'
  

  B) StartTLS test (server-to-server)

  openssl s_client -starttls smtp -connect 127.0.0.1:25 -crlf
  

  C) Submission test (587)

  openssl s_client -starttls smtp -connect 127.0.0.1:587 -crlf
  

  D) Send a test email (simple)

  If Kumo provides a CLI test tool, use it. Otherwise, install a basic SMTP test client like swaks:

  sudo dnf -y install epel-release
  sudo dnf -y install swaks
  

  Then (example for unauthenticated port 25 to remote is often blocked; better test submission with auth if configured):

  swaks --to you@yourdestination.com --server 127.0.0.1 --port 25
  

• Deliverability hardening (high value)

  Do these before real traffic:

  • Ensure rDNS PTR is correct and matches forward A
  • Ensure SPF passes
  • Ensure DKIM passes
  • Ensure DMARC exists
  • Use a dedicated sending subdomain (recommended):
  • mail.example.com or mta.example.com
  • Add a basic postmaster/abuse mailbox (some receivers check)
  • Warm up IP if new (small volume, slowly ramp)
  • Monitor bounces/complaints and throttle

• Logging, monitoring, and safe maintenance

  A) Log rotation

  If Kumo logs to files, add a logrotate entry (vendor may already ship one).

  B) Resource monitoring

  At minimum:

  dnf -y install htop iotop
  df -h
  free -m
  

  Queue growth is your “something is wrong” early warning.

Conclusion

You now know how to deploy KumoMTA on Rocky Linux VPS.