Install PowerMTA on Rocky Linux 9

Rocky Linux 9 is a 1:1 binary-compatible rebuild of Red Hat Enterprise Linux 9, which means installing PowerMTA on it follows the same package-level steps as AlmaLinux 9. Rather than repeat the shared RHEL-family mechanics in full, this page leans into what is genuinely Rocky-specific — its governance and why that matters for a long-lived mail server, the migrate-versus-rebuild decision when you are leaving CentOS, and the OpenSSL 3 and FIPS story that makes PowerMTA 6.0 a tidy fit here. For the deep firewalld and SELinux walkthroughs, the Alma page is the companion reference.

As everywhere on this site: PowerMTA is licensed commercial software. You bring a valid license and we automate the work around it. Nothing here distributes the binary or a key, and nothing helps run a cracked build. If you would rather avoid the license entirely, the KumoMTA route at the end runs the same way on Rocky 9 for free.

Why Rocky Linux 9 is a safe base for a sending server

A mail server is not a disposable box. Once an IP and hostname are warmed and trusted, you want to leave them in place for years, because reputation is the asset and churn is the enemy. That makes the operating system's stability and its institutional stability both worth weighing — and Rocky's case is largely about the second.

Rocky Linux exists because of how CentOS ended. It was started by Greg Kurtzer, a CentOS co-founder, after Red Hat redirected CentOS to a rolling upstream model, and it is governed by the Rocky Enterprise Software Foundation, a public-benefit non-profit with a technical steering committee and a board. CIQ is the founding commercial sponsor and employs many of the developers, but by design it does not control the foundation, the signing keys, the boot shims, or the infrastructure — that control sits with the community structure specifically so the project cannot be acquired or pivoted the way CentOS was. For a host whose value is a multi-year reputation, "the distribution will still be here, unchanged in character, in 2032" is a real operational input rather than marketing.

On the concrete side, Rocky 9 is bug-for-bug compatible with RHEL 9 and carries a ten-year lifecycle: security support runs to 31 May 2032, with Rocky 8 supported to May 2029 and Rocky 10 to May 2035. You can plan five years of infrastructure around it without baking in a forced migration. Minor versions supersede each other within the major line, so the maintenance rhythm is ordinary dnf update rather than periodic rebuilds.

Rocky, AlmaLinux, RHEL or Oracle for this workload

PowerMTA and KumoMTA run identically on any RHEL 9-family system, so the choice is about everything around the mail engine, not the engine itself. A short, honest map:

• Rocky Linux 9 — community governance built to resist corporate capture, free, ten-year lifecycle. The default pick if you want a RHEL clone with a foundation behind it and no licensing relationship.
• AlmaLinux 9 — functionally the same for this job, governed by its own foundation, with a slightly faster release cadence and continued support for the older x86_64-v2 hardware baseline. A fine choice, and the one whose install page carries the deeper plumbing notes.
• RHEL 9 — the upstream itself, with paid subscriptions and Red Hat support. Worth it if you already buy Red Hat support across the estate; otherwise the rebuilds give you the same binaries free.
• Oracle Linux 9 — free to use, with the optional Unbreakable Enterprise Kernel and paid Ksplice live patching. A reasonable pick if you specifically want UEK or are already in Oracle's orbit.

For most operators standing up a self-hosted sender in 2026, the realistic decision is Rocky or Alma, and either is correct. Standardise on whichever your fleet already runs so you patch one way, not two.

Coming from CentOS: migrate, or build fresh?

A lot of people land on Rocky 9 because their old CentOS box is out of support. There are two routes, and for a mail server the answer is clearer than it is for a generic application server.

The in-place route is the official migrate2rocky9 script from the rocky-tools repository. It swaps the distribution packages for Rocky equivalents while leaving your applications, configuration and data in place, and it works for converting an Enterprise Linux 9 system (CentOS Stream 9, AlmaLinux 9, RHEL 9 or Oracle Linux 9) to Rocky 9. It does not do major-version upgrades — a CentOS 7 host cannot be converted to Rocky 9 this way, because the jump in Python, systemd and libraries is too large. If you do run it, the rules are firm: snapshot the machine first (non-negotiable), run it inside a screen or tmux session so a dropped SSH connection does not strand the conversion, and read the log it leaves at /var/log/migrate2rocky.log. Expect the old running kernel to remain after the reboot — that is normal and you can remove it later.

What you need before you start

A clean Rocky Linux 9 server with root or sudo. A valid PowerMTA license — and note the version trap below. Control of DNS for the sending domain plus the server's PTR record. Outbound port 25 actually permitted by the provider. And a hostname you intend to keep, since renaming after warm-up throws away reputation tied to the name.

1. Update and set the hostname

sudo dnf -y update
sudo dnf -y install wget curl nano bind-utils tar policycoreutils-python-utils
sudo hostnamectl set-hostname mail.example.com

Reboot after the first large update so you are on the current kernel before the mail service starts. Confirm the hostname matches what you will publish in DNS and in the PTR record — HELO, forward DNS and reverse DNS all agreeing is a baseline deliverability requirement, not a nicety.

2. Claim port 25 — local owner and upstream gate

Two separate things have to be true. Nothing local should already hold port 25, and the provider has to let traffic leave on it. Rocky 9 images sometimes ship Postfix running, which takes the port before PowerMTA can.

sudo ss -lntp | grep ':25 '          # nothing should answer
sudo systemctl disable --now postfix  # if present
sudo systemctl mask postfix

Almost every cloud provider blocks outbound 25 by default and lifts it only on request through a support ticket. That block is upstream of your server, so firewalld cannot touch it. The AlmaLinux page covers the full diagnosis, and the port-25 fix covers the local-conflict case in depth — the mechanics are identical on Rocky.

3. Open firewalld for SMTP

Rocky 9 uses zone-based firewalld, the same as Alma. Allow the smtp service for the bounce and feedback-loop traffic you receive, and scope PowerMTA's web monitor (default TCP 8080) to your own address rather than the world.

sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.4/32" port port="8080" protocol="tcp" accept'
sudo firewall-cmd --reload

Replace 203.0.113.4 with your management IP. If your address is dynamic, reach the monitor through an SSH tunnel instead of widening the rule. The longer reasoning for narrow monitor exposure is on the AlmaLinux firewall section.

4. Install the PowerMTA 6.0 RPM

Upload the RPM from your vendor portal and install it with dnf pointed at the local file so dependencies resolve — bare rpm -ivh will fail on a minimal box and leave you chasing libraries.

sudo dnf install -y ./PowerMTA-6.0r4.x86_64.rpm
# if a system dependency is missing, enable EPEL and retry
sudo dnf install -y epel-release

The files land in the usual places — /etc/pmta/config for configuration, /usr/sbin/pmta for control, /var/log/pmta/ for logs, and the User's Guide PDF under /usr/share/doc/pmta/.

OpenSSL 3, FIPS and TLS on Rocky 9

This is where Rocky 9 and PowerMTA 6.0 line up neatly. PowerMTA 6.0 was rebuilt against OpenSSL 3.0.8 and added FIPS 140-2 compliance, which is exactly the crypto generation Rocky 9 ships — it is one of the reasons 6.0 dropped CentOS 7 and RHEL 7, since those carried the now-retired OpenSSL 1.1.1. The practical consequences for a sender are worth knowing. OpenSSL 3 disallows legacy algorithms and weak key sizes, and at its default security level it no longer trusts X.509 certificates signed with SHA-1. If your outbound TLS uses a certificate anywhere in the chain still signed with SHA-1, the handshake can fail — so make sure your mail server's certificate and its issuing chain are SHA-256. If a peer rejects your connection after the upgrade, the TLS handshake fix walks through the usual causes.

For senders with regulatory obligations, Rocky 9 can run in FIPS mode using its OpenSSL FIPS provider, and PowerMTA 6.0's FIPS 140-2 support means the engine cooperates. FIPS mode disables some legacy algorithms outright, so validate your entire TLS path end to end before you rely on it. If you need formal certification rather than FIPS mode on the stock build, CIQ's hardened Rocky (RLC-H) carries FIPS 140-3 validation.

5. Keep SELinux enforcing

Rocky 9 ships SELinux enforcing, and on an internet-facing mail host you keep it that way. The correct pattern is the same one detailed step by step on the AlmaLinux SELinux section: run permissive while you validate, capture the denials PowerMTA actually generates, turn them into a targeted module, and return to enforcing.

sudo setenforce 0                      # temporary; not a boot setting
sudo systemctl start pmta              # exercise it with a real test
sudo ausearch -m avc -ts recent | audit2allow -M pmta_local
sudo semodule -i pmta_local.pp
sudo setenforce 1 && getenforce

Read what audit2allow proposes before loading it — you want a tight policy for PowerMTA's real file and socket access, not a blanket allow that undoes the point of SELinux. Confirm /etc/selinux/config still reads enforcing so the setting survives a reboot.

6. Activate the license and start the service

Apply your 6.0 License Activation Key in the configuration, then enable and start the service so it survives reboots.

sudo systemctl enable --now pmta
pmta show status

A clean status shows the daemon running, the license recognised and queues empty. If the license line complains, recheck that the key is a 6.0 key and that the clock is right — a wrong system time can make a valid license read as expired. Sync it before anything else, then move on to /etc/pmta/config:

sudo timedatectl set-ntp true
timedatectl status | grep -i 'synchronized'

The real configuration — virtual MTAs, IP pools, authentication, throttling — happens in the config file, directive by directive.

7. First-send checks before you scale

Installation is the start, not the finish. Since February 2024 for Gmail and Yahoo bulk and May 2025 for Microsoft, bulk mail without SPF, DKIM and DMARC is rejected at the SMTP layer rather than filed to spam. Clear these before you send volume.

• PTR and FCrDNS. The sending IP must resolve to your hostname and back again. Set the PTR at the provider, then check with dig -x YOUR.IP.ADD.RESS.
• SPF, DKIM, DMARC. Confirm each resolves and is valid using the authentication guide; draft them with the generator tool if you are starting from scratch.
• One real test message to a seed you control, watching /var/log/pmta/ as it sends.
• Then warm up gradually — the warm-up service and the scheduler exist because the first weeks set the IP's reputation.

Running KumoMTA on Rocky 9 instead

If the license is the blocker, KumoMTA is the open-source path on the same OS. It is the first open-source high-volume MTA — Rust, Lua policy, Apache 2.0 — installed from its own package repository, running as the kumod service with its policy under /opt/kumomta. Everything Rocky-specific above still applies: claim port 25, the same firewalld rule, SELinux enforcing with a targeted policy, the same PTR and authentication requirements, and the same OpenSSL 3 TLS realities. KumoMTA does not ship an administration panel, which is the gap the Auto PMTA Configurator fills — an open-source engine with a usable front end. The PowerMTA vs KumoMTA comparison weighs the trade-offs if you have not decided.

Rocky-specific gotchas to avoid

• Converting a production sender in place. migrate2rocky9 is solid for generic servers, but a warmed mail host is worth a clean rebuild rather than a risk.
• Expecting a CentOS 7 migration. The script does not do major-version jumps. CentOS 7 to Rocky 9 is a fresh install, full stop.
• A 5.x key against a 6.0 build. PowerMTA 6.0 needs a 6.0 LAK. Mismatched versions will not activate.
• SHA-1 certificates after OpenSSL 3. OpenSSL 3 will not trust SHA-1-signed certs at the default security level — make the TLS chain SHA-256.
• Disabling SELinux or firewalld instead of configuring them. Both are protections you want on a public mail host. Build the targeted policy; keep the firewall narrow.
• Bare rpm -ivh on a minimal install. Use dnf install ./file.rpm, and reach for EPEL only if a system dependency is genuinely missing.

The bottom line

Rocky Linux 9 is a strong base for a long-lived sender: bug-for-bug RHEL 9 compatibility, a ten-year lifecycle to 2032, and governance built to outlast corporate strategy shifts. The install itself is the standard RHEL-family flow — claim port 25 locally and upstream, open firewalld narrowly, install the 6.0 RPM through dnf, keep SELinux enforcing with a targeted policy, activate a 6.0 license key, and verify reverse DNS and authentication before sending. The two things that bite on Rocky specifically are the migrate-versus-rebuild choice when leaving CentOS — rebuild, for a mail server — and the OpenSSL 3 alignment, which is mostly a gift but will reject SHA-1 certificates. Get those right and you have an engine that will hold its reputation for years.

If you would rather not do it by hand, or want the same setup repeated identically across a fleet, the one-click installer runs every step here over SSH for PowerMTA or KumoMTA. The standard does not move: a licensed or open-source engine, opt-in sending only, real deliverability work, and nothing that helps spam.