Install PowerMTA on AlmaLinux 9

AlmaLinux 9 is one of the cleanest foundations you can put a high-volume mail server on. It is a 1:1 binary-compatible rebuild of Red Hat Enterprise Linux 9, it carries security updates through May 2032, and it ships the two security subsystems a public-facing SMTP host most needs — SELinux and firewalld — switched on out of the box. This guide walks the full PowerMTA install on AlmaLinux 9 and spends most of its time on the two places the RHEL family trips people up: the firewall, and SELinux. It assumes the general flow from the full install guide and fills in everything specific to Alma.

One thing stays constant on every page here: PowerMTA is commercial software. You supply a valid license and we automate the work around it. Nothing on this site distributes the binary, ships a key, or helps run a cracked build. If you would rather not buy a license at all, the KumoMTA section below covers the open-source route on the same operating system.

Why AlmaLinux 9 is a good base for this

The PowerMTA niche has historically lived on whatever CentOS box was lying around. CentOS Linux is gone, and the RHEL-compatible rebuilds took its place. AlmaLinux 9 is the most widely deployed of them for mail work, and the reasons are practical rather than fashionable. Because it tracks RHEL 9 one-to-one, anything the vendor tests against RHEL 9 behaves the same here — the same glibc, the same systemd, the same OpenSSL. PowerMTA's RPM was built for that ABI, so it lands without surprises.

The lifecycle matters more than people credit. AlmaLinux 9 has active support until 31 May 2027 and security support until 31 May 2032. A mail server is infrastructure you want to leave alone for years once it is warmed and reputable; rebuilding it because the OS fell out of support is the kind of disruption that costs you inbox placement. A nine-year security runway from a fresh 2026 build is hard to beat. Each minor version — 9.5, 9.6 and so on — reaches end of life when the next minor lands, so the practical rule is to stay current on minor updates within the major release, which a periodic dnf update handles.

AlmaLinux 9 also assumes the security posture you actually want on a sending host. SELinux runs enforcing, firewalld is the front door, SSH root login is off by default, and the audit daemon is logging. None of that is in your way once it is configured correctly, and all of it is genuinely useful on a box whose entire job is to talk to the open internet. The one hardware caveat worth checking: RHEL 9 and its rebuilds require a CPU that supports the x86_64-v2 instruction set. Any server-class processor from the last decade qualifies, but a very old virtualised host, or a VM pinned to an ancient CPU model, can fail to boot the 9 kernel. If you are spinning up a budget VPS, confirm the CPU model before you commit.

What you need before you start

Five things turn this from a frustrating afternoon into a fifteen-minute job. A clean AlmaLinux 9 server with root or sudo. A valid PowerMTA license — the License Activation Key from your vendor portal, plus the RPM for the build you are entitled to. Control of DNS for the sending domain and the server's PTR record, because authentication and reverse DNS are not optional in 2026. Outbound port 25 actually open at the provider, which is the single most common reason a fresh install "works" but sends nothing. And a hostname you intend to keep, since changing it after warm-up resets reputation tied to the IP and name.

The install at a glance

Seven steps, in order. Update and name the box. Make sure port 25 is yours and reachable. Open the firewall. Install the package. Settle SELinux. Activate and start. Run first-send checks. The first three are AlmaLinux housekeeping; the middle two are where Alma differs from a Debian box; the last two are universal. Work through them top to bottom and do not skip the SELinux step by reaching for setenforce 0 permanently — that habit is exactly what gets a mail host owned.

1. Update the system and set a real hostname

Start from a fully patched base. On a brand-new install there can be a meaningful gap between the ISO and current packages, and you want that closed before you layer anything on top.

sudo dnf -y update
sudo dnf -y install wget curl nano bind-utils tar policycoreutils-python-utils
# bind-utils gives you dig/host; policycoreutils-python-utils gives you semanage

Set a fully qualified hostname that matches the name you will publish in DNS and in your PTR record. PowerMTA uses this name in its HELO/EHLO, and mismatches between HELO, forward DNS and reverse DNS are a reliable way to land in spam folders.

sudo hostnamectl set-hostname mail.example.com
hostnamectl status | grep -i hostname

A reboot is worth it after the first big update so you are running the latest kernel before you start the mail service. It is the cheapest insurance you will buy all day.

2. Confirm port 25 is free locally and reachable outbound

This is the step that quietly wrecks more first installs than any SELinux or config error. There are two separate questions, and both have to be yes. Is anything already bound to port 25 on this server? And will your provider let packets leave the box on port 25 at all?

Check the local side first. Many AlmaLinux images ship Postfix and start it, which means it is sitting on 25 before PowerMTA ever gets there.

# is anything already listening on 25?
sudo ss -lntp | grep ':25 '

# if Postfix is holding it, stop and mask it
sudo systemctl disable --now postfix
sudo systemctl mask postfix

Masking, rather than just disabling, stops anything from quietly starting Postfix back up as a dependency later. Re-run the ss check and confirm nothing answers.

The provider side is the one that catches people. AWS, DigitalOcean, Google Cloud, Vultr, Hetzner and most others block outbound port 25 by default to stop compromised instances spewing spam. That block sits at their network edge, upstream of your server, so no amount of firewalld tweaking will move it. You request the unblock through a support ticket or a dedicated form, and they usually want to see that the account and the use case are legitimate before they lift it. Test whether you are blocked by trying to reach a known mail server's port 25 from the box:

# if this hangs and times out, your egress is blocked upstream
nc -zv -w5 gmail-smtp-in.l.google.com 25

3. Open the firewall with firewalld

AlmaLinux 9 runs firewalld, and it is zone-based. For a sending server you need outbound 25 (which the default zone already permits) and an inbound rule for the SMTP traffic you receive — bounces and feedback-loop reports come back over 25. You will also expose PowerMTA's web monitor, and you do not want that open to the world.

sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

PowerMTA's monitor listens on TCP 8080 by default. Rather than opening it globally, scope it to your own admin address with a rich rule so the dashboard is reachable from where you work and nowhere else:

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

Swap in your real management IP for 203.0.113.4. If your address is dynamic, front the monitor with an SSH tunnel or a reverse proxy with authentication instead of widening the rule. An exposed, unauthenticated MTA dashboard is an open invitation, and on a box that already has a clean sending reputation it is worth more to an attacker than most people assume.

4. Install the PowerMTA RPM

Upload the RPM you downloaded from your vendor portal, then install it with dnf pointed at the local file rather than bare rpm. The difference matters on a minimal AlmaLinux 9: dnf install ./file.rpm resolves and pulls any missing dependencies, whereas rpm -ivh fails with a dependency error and leaves you chasing libraries by hand.

# dnf resolves dependencies; rpm -ivh does not
sudo dnf install -y ./PowerMTA-6.0r4.x86_64.rpm

Match the filename to the exact build you are licensed for. After install, the files you care about are predictable:

• /etc/pmta/config — the main configuration file, the heart of the system.
• /usr/sbin/pmta — the control command (pmta show status, pmta reload).
• /var/log/pmta/ — accounting and the main log.
• /usr/share/doc/pmta/UsersGuide.pdf — the vendor reference, worth keeping open.

Dependencies on a minimal install

A minimal AlmaLinux 9 is deliberately sparse. Beyond what dnf pulls for the RPM itself, keep a Perl interpreter available if you plan to use the bundled accounting pipes or custom pipe handlers, and have your DNS tools installed (you added bind-utils in step one). Do not install a second MTA "just in case" — Postfix or Sendmail sitting alongside PowerMTA is how port 25 conflicts and confused mail routing start.

5. Handle SELinux the right way

This is the section that defines an AlmaLinux build, and the one where the internet's advice is worst. AlmaLinux 9 ships SELinux enforcing. The lazy fix that floats around grey-hat forums is to set it permissive or disabled and never think about it again. On a mail server reachable from the entire internet, that throws away one of the few protections that actually contains a compromise. Do it properly instead — it takes a few extra minutes once.

The right pattern is: validate in permissive, capture the denials PowerMTA generates, turn those denials into a small targeted policy, and go back to enforcing. SELinux logs what it would have blocked while permissive, which gives you a precise list to allow.

# 1. drop to permissive temporarily (does NOT survive reboot)
sudo setenforce 0

# 2. start PowerMTA and send a real test so it touches everything
sudo systemctl start pmta

# 3. turn the recorded denials into a targeted module
sudo ausearch -m avc -ts recent | audit2allow -M pmta_local
sudo semodule -i pmta_local.pp

# 4. back to enforcing — and confirm it stuck
sudo setenforce 1
getenforce

If PowerMTA needs to listen on a non-standard port — say you moved the monitor off 8080 — SELinux will block the bind until you label the port. Use semanage for that rather than turning SELinux off:

# example: label a custom monitor port so SELinux permits the bind
sudo semanage port -a -t http_port_t -p tcp 8443

Make sure the permanent SELinux mode in /etc/selinux/config still says enforcing — setenforce only changes the running state, not the boot default. The combination you want at the end of this step is: config set to enforcing, getenforce reporting Enforcing, your pmta_local module loaded, and a test send succeeding.

6. Activate the license and start the service

With the package in and SELinux settled, point PowerMTA at your license. The License Activation Key goes into the configuration, then you enable the service so it survives reboots and start it.

sudo systemctl enable --now pmta
pmta show status

A healthy pmta show status shows the daemon running, the license recognised, and the queues empty on a fresh box. If the license line complains, recheck the key against your vendor portal and confirm the server's clock is correct — a wrong system time can make a valid license look expired. Sync time before you do anything else:

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

From here, the real configuration work — virtual MTAs, IP pools, authentication, throttling — happens in /etc/pmta/config, which the configuration reference walks through directive by directive.

7. First-send checks before you scale

The package being installed is not the finish line. A mail server that sends without correct reverse DNS and authentication will deliver to spam at best and bounce at the SMTP layer at worst — since February 2024 for Gmail and Yahoo bulk, and since May 2025 for Microsoft, missing SPF, DKIM and DMARC on bulk mail is a hard rejection, not a soft filter. Run these checks before you turn up volume.

• PTR and FCrDNS. Your sending IP must resolve to your hostname, and that hostname must resolve back to the IP. The PTR is set at your provider, not on the box. Verify with dig -x YOUR.IP.ADD.RESS and a forward lookup of the result.
• SPF, DKIM, DMARC. Confirm each record resolves and is valid before the first real send. The authentication guide covers the records and the PowerMTA signing setup; the generator tool will draft them for you.
• One real test message. Send a single message to a seed address you control and read /var/log/pmta/ as it goes out. A clean accept from the receiving server tells you egress, DNS and auth are all working together.
• Then warm up. Do not point full volume at a fresh IP. Ramp gradually — the warm-up service and the scheduler tool exist precisely because the first weeks set the IP's reputation.

Running KumoMTA on AlmaLinux 9 instead

If the PowerMTA license is the sticking point, KumoMTA is the open-source route on the same operating system. It is the first open-source high-volume MTA, written in Rust with policy in Lua, released under Apache 2.0 — free to run, with source you can read. On AlmaLinux 9 the shape of the install is different but the surrounding work is identical to everything above.

KumoMTA ships its own package repository for the RHEL 9 family. You add the repo, install with dnf, and the daemon runs as the kumod service under systemd. Its configuration is Lua rather than a directive file, and it lives under /opt/kumomta — the policy entry point is a Lua script you edit and reload. Everything on this page that is about AlmaLinux rather than about PowerMTA still applies without change: port 25 must be free locally and unblocked upstream, firewalld needs the same SMTP rule, SELinux should stay enforcing with a targeted policy built the same way, and PTR plus SPF, DKIM and DMARC are no less mandatory.

The one thing KumoMTA does not ship is an administration interface — there is no equivalent of PowerMTA's web monitor, no panel for managing virtual MTAs, pools and throttling visually. That missing layer is exactly what the Auto PMTA Configurator generates: it stands up KumoMTA on AlmaLinux and gives it the panel the project leaves out, so you get an open-source engine with a usable front end. If you want the deeper comparison before choosing, the PowerMTA vs KumoMTA breakdown lays out cost, control and operational trade-offs side by side.

AlmaLinux-specific mistakes to avoid

A handful of errors come up again and again on RHEL-family installs, and every one of them is avoidable.

• Disabling SELinux to make an error go away. The error is information. Capture the denial and write a targeted policy; do not switch off the protection on an internet-facing mail host.
• Forgetting the egress request. firewalld rules cannot open a port your provider blocks upstream. Request the outbound 25 unblock first, then debug locally.
• Leaving Postfix bound to 25. A pre-installed, auto-started Postfix silently wins the race for the port. Disable and mask it before installing PowerMTA.
• Installing with bare rpm -ivh on a minimal box. It fails on dependencies. Use dnf install ./file.rpm so they resolve.
• Shipping without PTR. No reverse DNS means spam folders or rejections regardless of how clean the config is. Set the PTR at the provider before the first send.
• An x86_64-v1 VM. A very old or constrained virtual CPU can fail to boot the EL9 kernel. Confirm the host supports x86_64-v2.
• Turning firewalld off rather than configuring it. Same reasoning as SELinux — configure the front door, do not remove it.

The bottom line

Installing PowerMTA on AlmaLinux 9 is not hard once you respect the two RHEL-family realities: port 25 has a local owner and an upstream gatekeeper, and SELinux is a tool to configure rather than an obstacle to remove. Update and name the box, claim port 25 and confirm egress, open firewalld narrowly, install the RPM through dnf, build a targeted SELinux policy, activate the license, and verify reverse DNS and authentication before you send a single bulk message. Do that and you have a server that will hold its reputation for years on an OS supported through 2032.

If you would rather not spend the afternoon — or you want the same correct-by-default setup repeated identically across a fleet — the one-click installer performs every step here over SSH for PowerMTA or KumoMTA. Either way, the standard holds: a licensed or open-source engine, opt-in sending only, real deliverability engineering, and nothing that helps spam.