How to Install PowerMTA on RHEL, AlmaLinux, and Rocky Linux: Complete 2026 Operator Guide

Why CentOS 7 and 8 are no longer an option

For years, CentOS was the default choice for a RHEL-family server, and a great deal of older PowerMTA installation guidance assumes CentOS 7 or CentOS 8. In 2026 that guidance is out of date, and the first thing to establish is clear: CentOS 7 and CentOS 8 should not be used for a PowerMTA installation.

Both are end-of-life. CentOS 8 reached end-of-life at the end of 2021 when Red Hat discontinued the traditional CentOS in favor of CentOS Stream. CentOS 7 reached end-of-life in mid-2024. An end-of-life operating system receives no security updates, which by itself makes it unsuitable for production email infrastructure, infrastructure that sits exposed and handles a sensitive workload.

Beyond the security argument there is a concrete technical blocker. PowerMTA 6.0 requires OpenSSL 3.x. CentOS 7 ships only the older OpenSSL 1.0.x or 1.1.x. PowerMTA 6.0 simply cannot run on CentOS 7; the OpenSSL dependency is not satisfied.

So the CentOS question is settled. An operator with an existing PowerMTA installation on CentOS 7 or 8 should plan a migration to a supported distribution. A new installation must go on a current, supported distribution from the start. This guide covers installing PowerMTA on the RHEL-family distributions that are current and supported in 2026, and the rest of it assumes one of those, not an end-of-life CentOS.

The supported RHEL-family distributions

The RHEL-family distributions suitable for PowerMTA in 2026:

Distribution	Status	Notes
RHEL 8 / 9	Supported	The commercial Red Hat product
AlmaLinux 8 / 9	Supported	Community RHEL-compatible, free
Rocky Linux 8 / 9	Supported	Community RHEL-compatible, free
CentOS 7 / 8	End-of-life	Do not use

RHEL itself, Red Hat Enterprise Linux, in its 8 and 9 lines, is the commercial product and a fully supported choice.

AlmaLinux and Rocky Linux are the community RHEL-compatible distributions that emerged specifically after the CentOS discontinuation. They are free, binary-compatible with RHEL, and are the natural successors for operators who were running CentOS. Both, in their 8 and 9 lines, are supported choices for PowerMTA.

For a new installation, the version 9 line, RHEL 9, AlmaLinux 9, or Rocky Linux 9, is the recommended choice. The 9 line ships OpenSSL 3.x, satisfying the PowerMTA 6.0 requirement, and is the more current line with a longer remaining support horizon. The 8 line also ships OpenSSL 3.x and is supported, but for a fresh install the 9 line is the better starting point. For an operator migrating off CentOS, AlmaLinux 9 or Rocky Linux 9 is the most direct equivalent, free, RHEL-compatible, current.

The OpenSSL 3.x requirement

The OpenSSL version is the technical pivot of the distribution choice, so it deserves a clear statement.

PowerMTA 6.0 requires OpenSSL 3.x, specifically the OpenSSL 3.0.8 generation. This requirement comes from PowerMTA 6.0's modernization, which updated the TLS stack to the current OpenSSL.

The RHEL-family distributions and their OpenSSL:

• RHEL 9, AlmaLinux 9, Rocky Linux 9: ship OpenSSL 3.x. PowerMTA 6.0 runs.
• RHEL 8, AlmaLinux 8, Rocky Linux 8: ship OpenSSL 3.x as well in their current state. PowerMTA 6.0 runs.
• CentOS 7: ships OpenSSL 1.0.x or 1.1.x. PowerMTA 6.0 does not run.

The check, on any candidate server before installing PowerMTA 6.0:

openssl version

If this reports an OpenSSL 3.x version, PowerMTA 6.0's OpenSSL requirement is satisfied. If it reports OpenSSL 1.1.x or older, the server's OS is too old for PowerMTA 6.0 and the installation must go on a newer distribution.

Beyond just running, OpenSSL 3.0 enforces stricter TLS rules than the older versions: it disallows legacy algorithms and weak key sizes. This matters for the TLS configuration but does not block the installation; it simply means the TLS certificates and cipher settings must meet OpenSSL 3.0's standards, current key sizes, current ciphers.

The pre-installation checklist

Before starting the installation, work through this checklist:

1. Confirm a supported OS. RHEL, AlmaLinux, or Rocky Linux, 8 or 9 line, not an end-of-life CentOS.
2. Confirm OpenSSL 3.x. Run openssl version; for a PowerMTA 6.0 install it must report 3.x.
3. Confirm 64-bit x86. PowerMTA runs on 64-bit x86, not on ARM.
4. Obtain the License Activation Key. Get the LAK from the vendor in advance; a 6.0 install needs the 6.0-generation key.
5. Identify a conflicting system MTA. RHEL-family systems frequently have Postfix or Sendmail installed; it must be removed or disabled before PowerMTA can bind port 25.
6. Set up reverse DNS. The sending IP needs proper rDNS resolving to a hostname that forward-resolves back.
7. Check outbound port 25. On a cloud server, the provider likely blocks outbound port 25; the unblock must be requested.
8. Plan disk space. Ensure the partitions for the spool and the logs have adequate space.

This checklist catches the problems that otherwise surface partway through the installation: an OpenSSL incompatibility, a missing license, a port conflict, a cloud port 25 block. Working through it first means the install proceeds cleanly.

Removing a conflicting system MTA

RHEL-family distributions frequently ship with a mail transfer agent already installed and running, usually Postfix, sometimes Sendmail. This system MTA occupies port 25, the port PowerMTA's SMTP listener needs. Two processes cannot bind the same port, so the conflicting MTA must be removed or disabled before PowerMTA is installed.

Check what is present and using port 25:

# See what is listening on port 25
ss -tlnp | grep ':25 '

# Check whether Postfix is installed and running
systemctl status postfix

If Postfix is present, stop and disable it so it does not occupy the port and does not start on boot:

systemctl stop postfix
systemctl disable postfix

The disable step is as important as the stop. A system MTA that is only stopped will return on the next reboot and reintroduce the port conflict, which can surface confusingly later when a reboot reshuffles the service start order. Disabling it removes it from the boot sequence entirely. Some operators choose to remove the package outright rather than just disable it, which is also fine and leaves no possibility of it returning.

The installation steps

With the prerequisites in place, the PowerMTA installation itself is straightforward. PowerMTA is distributed as a package, and on a RHEL-family system the installation uses the RPM package manager.

The general flow:

1. Obtain the PowerMTA package for the correct version from the vendor.
2. Transfer the package to the server.
3. Install the package with the RPM-based package manager.
4. The installation places the PowerMTA files, the binaries, the configuration directory at /etc/pmta/, the spool and log directories, and the service unit.

The installation step itself:

# Install the PowerMTA RPM package
dnf install ./PowerMTA-package.rpm

# Or with rpm directly
rpm -ivh PowerMTA-package.rpm

The package installation sets up the directory structure and the systemd service unit. After the package is installed, PowerMTA is present on the system but needs its license and configuration before it can run properly.

The exact package name and any version-specific installation notes follow the vendor's documentation for the PowerMTA version being installed. For PowerMTA 6.0, the package is the 6.0 package, and it requires the OpenSSL 3.x that the supported distributions provide.

Placing the License Activation Key

PowerMTA needs its license to run. The License Activation Key, obtained from the vendor as part of the pre-installation checklist, goes into a license file in the PowerMTA configuration directory.

The LAK is placed into the license file that PowerMTA reads at startup, located in /etc/pmta/ alongside the main configuration file. The exact filename and the way the LAK is referenced follow the PowerMTA version's conventions.

The critical points for the license at install time:

• The LAK must be the correct generation for the PowerMTA version. A PowerMTA 6.0 installation needs the 6.0-generation key; an older key will not validate with 6.0.
• The license file must be in the configuration directory and readable by the PowerMTA process.
• PowerMTA's license validation has a network component, so the server needs outbound connectivity to the vendor's licensing infrastructure. A firewall that blocks this will cause a license validation failure even when the license itself is correct.

If PowerMTA fails to start after installation with a license error, the license is the first thing to check: is the LAK the right generation, is the file in place and readable, and can the server reach the licensing servers.

The initial configuration

PowerMTA reads its configuration from /etc/pmta/config. A fresh installation needs an initial configuration before it can deliver mail meaningfully.

The minimum elements of an initial configuration:

• An SMTP listener so PowerMTA accepts messages for delivery, typically on port 25 from the local application, or another port for the submission path.
• A source definition for the systems allowed to submit mail to PowerMTA, with relaying permitted for the trusted internal submitters.
• At least one virtual MTA binding to the sending IP with its smtp-source-host, and the DKIM signing via the domain-key directive.
• Domain blocks for the major receivers, plus a domain default block, with sensible throttling.
• An accounting file so PowerMTA records what happens to messages.

A minimal skeleton:

# Listener for local application submission
<smtp-listener 127.0.0.1:25>
</smtp-listener>

<source 127.0.0.1>
    always-allow-relaying yes
</source>

<virtual-mta primary>
    smtp-source-host 203.0.113.10 mail.example.com
    domain-key sel1,example.com,/etc/pmta/keys/example.pem
</virtual-mta>

<domain default>
    max-msg-rate 500/h
    virtual-mta primary
</domain>

<acct-file /var/log/pmta/accounting.csv>
    records d,b,t,rb,f
</acct-file>

This skeleton is a starting point; a production configuration adds specific domain blocks for the major receivers, the monitoring listener, the retry directives, and the rest. After writing the configuration, the operator should validate it with PowerMTA's configuration check before starting the service, which catches any syntax error before it causes a failed start.

The cloud port 25 block

If PowerMTA is being installed on a cloud server, there is a critical issue that catches many operators: the major cloud providers block outbound port 25 by default.

AWS, Google Cloud, Azure, DigitalOcean, Vultr, and other cloud platforms block outbound connections on port 25 from new instances as an anti-abuse measure. Port 25 is the port used to deliver mail to receiving servers, and an unrestricted port 25 would let compromised or abusive instances send spam freely, so the providers block it by default.

The resolution is to request that the cloud provider lift the outbound port 25 restriction for the instance. Each provider handles this through its own process, typically a support request that asks about the intended use and the sending practices. Some providers grant the request readily for legitimate senders; others are more restrictive. The request should be made early, as part of pre-installation planning, not discovered after the install when PowerMTA is running but nothing delivers.

Verifying the installation

After installation, configuration, and the license, verify PowerMTA is working:

Check	Confirms
PowerMTA starts cleanly	Installation, license, config all valid
pmta show status	Service running, correct version
The license validates	The LAK is accepted
The listener is bound	PowerMTA accepts submissions on port 25
A test message delivers	End-to-end delivery works
Accounting records appear	Accounting is functioning

Start PowerMTA and run pmta show status; it should report the service running and the correct version. Confirm the SMTP listener is bound on the expected port. Then send a test message through PowerMTA and confirm it delivers to an external mailbox, which exercises the whole path including the outbound port 25 connectivity. Check that an accounting record for the test delivery appeared in the accounting file.

A test message that delivers successfully to an external address is the definitive confirmation that the installation is complete and working: it proves the configuration is valid, the license is accepted, the listener works, the VMTA and DKIM signing function, and the outbound port 25 path is open.

When the install does not complete cleanly

When the installation hits a problem, the diagnostic workflow:

Step 1: read the PowerMTA log. If PowerMTA will not start, the log at /var/log/pmta/log records why. Read it first.

Step 2: for an OpenSSL or library error. If the log or the system journal mentions a library or OpenSSL problem, the OS is likely too old, an OpenSSL 1.1.x system for a PowerMTA 6.0 install. The fix is a supported distribution with OpenSSL 3.x.

Step 3: for a license error. If the log reports a license problem, check the LAK is the right generation, the license file is in place and readable, and the server can reach the licensing servers.

Step 4: for a port bind failure. If PowerMTA cannot bind port 25, a conflicting system MTA is the cause. Confirm Postfix or Sendmail is stopped and disabled.

Step 5: for a config parse error. If the log reports a configuration syntax error, go to the named line and correct it; run the configuration check.

Step 6: for PowerMTA running but not delivering. If PowerMTA starts fine but deliveries fail to connect, suspect the cloud port 25 block. Confirm whether outbound port 25 is open from the server.

Step 7: verify each prerequisite. If the cause is unclear, walk back through the pre-installation checklist, confirming the OS, OpenSSL, architecture, license, MTA conflict, rDNS, and port 25 are each as they should be.

Installing PowerMTA on RHEL-family Linux in 2026 starts with a clear constraint: CentOS 7 and 8 are end-of-life and must not be used, both for the security reason and because PowerMTA 6.0's OpenSSL 3.x requirement cannot be met on them. The supported choices are RHEL, AlmaLinux, and Rocky Linux in the 8 and 9 lines, with the 9 line the recommended starting point and AlmaLinux or Rocky Linux the natural successors for operators leaving CentOS. The installation itself is straightforward, a package install, the License Activation Key in place, an initial configuration, once the prerequisites are met: a supported OS with OpenSSL 3.x, 64-bit x86, the license obtained, a conflicting system MTA removed, reverse DNS set up, and crucially the cloud outbound port 25 block lifted. Working through the pre-installation checklist before starting means the install proceeds cleanly rather than hitting an OpenSSL incompatibility or a port 25 surprise. Operators who choose a current supported distribution from the start, complete the checklist, and verify with a real test delivery, get a clean, working PowerMTA installation; operators who try to install on an end-of-life CentOS discover that the dead operating system blocks current PowerMTA outright.