PowerMTA System Requirements and Installation Prerequisites: Complete 2026 Operator Guide

Why prerequisites matter

PowerMTA installations fail in predictable ways when prerequisites are not properly verified before installation begins. The software itself installs cleanly; the failures come from environment issues that the installer cannot detect and cannot fix: outbound port 25 blocked at the provider network level, an unsupported or end-of-life operating system, missing dependency libraries, insufficient file descriptors, license key mismatch. Each of these produces an installation that appears to succeed but does not actually work, and the diagnostic path from "PowerMTA installed but does not deliver" back to the actual prerequisite failure is non-obvious for operators new to the software.

This guide exists because prerequisite verification is the cheapest possible insurance against the most expensive category of PowerMTA problems. Ten minutes verifying prerequisites before installation prevents hours of post-installation debugging. The structure: supported operating systems, hardware requirements scaled by volume, the changes in PowerMTA 6.0 versus 5.5, the licensing model and activation key requirements, port 25 outbound verification, dependency packages, pre-installation OS preparation, file descriptor configuration, the upgrade path from 5.5 to 6.0, and the common installation failures that prerequisite verification prevents.

Supported operating systems

PowerMTA 5.5 and 6.0 support mainstream enterprise Linux distributions in 64-bit x86 architecture:

Distribution	Supported versions	Notes
Ubuntu	20.04, 22.04, 24.04 LTS	Recommended for new deployments
Debian	11, 12	Stable, well-supported
Red Hat Enterprise Linux	8, 9	Requires subscription
AlmaLinux	8, 9	RHEL-compatible, free
Rocky Linux	8, 9	RHEL-compatible, free

The RHEL-family distributions (RHEL, AlmaLinux, Rocky) are functionally equivalent for PowerMTA purposes. AlmaLinux and Rocky Linux are RHEL-compatible rebuilds created after CentOS shifted to the rolling-release CentOS Stream model, and both provide the stable RHEL-equivalent platform that operators previously got from CentOS.

The architecture requirement is 64-bit Intel x86. ARM architecture is not officially supported as of 2026, which matters for operators considering ARM-based cloud instances (AWS Graviton, Ampere-based VMs) for cost reasons.

PowerMTA is not available in any official OS package repository. The installer is downloaded from the Bird/SparkPost portal as a distribution-specific package (.deb for Debian/Ubuntu, .rpm for RHEL-family) or as a .tar.gz archive.

Hardware requirements by volume

PowerMTA's official minimum is modest (2 GB RAM, 4 GB disk, 64-bit processor) but practical requirements scale with sending volume:

Sending volume	vCPU	RAM	Storage
Official minimum	1	2 GB	4 GB
Practical minimum (test/dev)	2	4 GB	40 GB SSD
Under 500K/day	4	8 GB	100 GB SSD
500K-2M/day	8	16 GB	250 GB NVMe
2M-10M/day	16	32 GB	500 GB NVMe
10M+/day	32+	64 GB+	1 TB+ NVMe

The official 2 GB minimum is genuinely minimal and adequate only for testing or very low-volume production. Any serious production deployment should start at 4 GB RAM minimum and scale up. Storage must be SSD or NVMe; HDD storage produces unacceptable performance even at modest volumes because of PowerMTA's spool I/O patterns.

The substantive sizing point: memory matters more than CPU for PowerMTA at scale because message queues and accounting buffers live in RAM. When budget-constrained, choose memory over CPU.

PowerMTA 6.0 versus 5.5

PowerMTA 6.0 introduced substantive changes over 5.5 focused on security and cloud compatibility:

Change	Impact
OpenSSL upgrade to 3.0.8	Disallows legacy algorithms and weak key sizes
FIPS 140-2 compliance	Suitable for government and regulated deployments
Cloud-compatibility improvements	Better scalability in cloud environments
New License Activation Key format	6.0 LAK incompatible with 5.5 license

The OpenSSL 3.0.8 upgrade is the most consequential change for existing operators. OpenSSL 3.0 disallows legacy algorithms and weak key sizes that OpenSSL 1.1.x permitted. TLS configurations that worked under PowerMTA 5.5 may need adjustment under 6.0 if they relied on deprecated ciphers or small RSA keys. Operators upgrading should verify their TLS certificate key sizes (2048-bit RSA minimum, 4096-bit preferred, or ECDSA) and cipher configurations work under the stricter OpenSSL 3.0 requirements.

The FIPS 140-2 compliance makes PowerMTA 6.0 suitable for deployments with Federal Information Processing Standards requirements. This matters for government contractors, healthcare under certain frameworks, and other regulated industries where FIPS compliance is mandated.

The licensing change requires attention: PowerMTA 6.0 needs a new License Activation Key (LAK) compatible only with version 6.0. The 5.5 license does not validate against 6.0. This is covered in detail in the licensing section below.

Licensing and activation keys

PowerMTA is commercial software requiring a valid license. The licensing model and the activation key requirements:

License acquisition. PowerMTA licenses come from Bird (the company that acquired the SparkPost portfolio including PowerMTA). The license is tied to the PowerMTA version and, for volume-based licenses, to a sending volume tier.

License Activation Key (LAK). Each PowerMTA installation activates with a LAK. The LAK for PowerMTA 6.0 is a different format than the 5.5 key and the two are not interchangeable. Running PowerMTA 6.0 with only a 5.5 license produces license validation failure and PowerMTA will not start or will not send.

Volume-based licensing. Some PowerMTA licenses are volume-based, where the license permits sending up to a specified volume tier. Volume-based licenses require an API key for PowerMTA to authenticate with Bird/SparkPost and report sending volume. This key is provided alongside the volume-based license.

License placement. The license file or key is placed in the PowerMTA configuration location (typically /etc/pmta/) during installation. The installer prompts for the license; the operator pastes the key received from Bird.

License validation connectivity. PowerMTA license validation may require outbound internet connectivity to Bird's license servers. Firewall rules must permit this outbound connectivity, or license validation fails with confusing errors that look like license problems but are actually network connectivity problems.

Port 25 outbound access

This is the single most important prerequisite to verify, and the one operators most frequently overlook.

PowerMTA delivers email by connecting to receiving mail servers, which almost universally listen on port 25 (the SMTP relay port per RFC 5321). PowerMTA therefore requires outbound TCP access to port 25 on arbitrary internet destinations.

Many cloud providers block outbound port 25 by default as an anti-spam measure:

Provider	Default outbound 25	Unblock process
AWS EC2	Blocked for new accounts	Request form, account verification
Google Cloud	Blocked	Generally not unblockable, use relay
Microsoft Azure	Blocked for most accounts	Limited unblock options
Hetzner	Open by default (after account age)	Usually available
OVH	Usually open	Available
DigitalOcean	Blocked for new accounts	Support ticket
Vultr	Blocked by default	Support ticket

The verification before installation: from the intended PowerMTA host, test outbound port 25 connectivity:

telnet gmail-smtp-in.l.google.com 25

A successful test shows a connection establishing with a 220 banner from Google's mail server. If the connection times out or is refused, outbound port 25 is blocked and PowerMTA cannot deliver until the provider lifts the restriction.

The alternative nc -zv gmail-smtp-in.l.google.com 25 achieves the same verification. Verify before installing PowerMTA, not after; discovering the block after deployment means relocating the entire installation to a provider that permits outbound 25.

Dependency packages

PowerMTA requires certain system libraries present before installation. The exact dependency set varies slightly by distribution and version, but the common requirements:

For Ubuntu/Debian:

apt update
apt install -y libc6 libssl3 zlib1g ca-certificates curl wget

For RHEL/AlmaLinux/Rocky:

dnf install -y glibc openssl-libs zlib ca-certificates curl wget

PowerMTA 6.0's OpenSSL 3.0.8 requirement means the system OpenSSL libraries should be the 3.x series. On Ubuntu 22.04+ and Rocky 9, OpenSSL 3.x is the default; on older distributions OpenSSL 1.1.x is default and PowerMTA 6.0 may require the 3.x libraries specifically. This is one of the reasons end-of-life distributions are unsuitable for PowerMTA 6.0.

The PowerMTA installer typically checks dependencies and reports missing packages. Installing the common dependency set above before running the installer prevents the installer from stopping partway through with dependency errors.

Pre-installation OS preparation

Before running the PowerMTA installer, prepare the operating system:

1. Update all packages: apt update && apt upgrade -y (Ubuntu/Debian) or dnf update -y (RHEL-family)
2. Set the hostname to a fully qualified domain name: hostnamectl set-hostname mta1.example.com
3. Verify the hostname resolves: add to /etc/hosts if needed
4. Set timezone to UTC: timedatectl set-timezone UTC
5. Disable or remove any existing MTA (Postfix, sendmail, exim) that occupies port 25: systemctl stop postfix && systemctl disable postfix
6. Verify port 25 is free locally: ss -tlnp | grep :25 should return nothing
7. Verify outbound port 25 works (the critical check above)
8. Configure firewall to allow needed ports (25 inbound from trusted sources, the HTTP monitoring port from trusted sources)
9. Install dependency packages (above)
10. Configure file descriptor limits (next section)
11. Ensure adequate disk space on the partition where /var/spool/pmta and /var/log/pmta will live

Step 5 is critical and frequently missed. Most Linux distributions ship with an MTA (Postfix is common) that occupies port 25. PowerMTA cannot bind port 25 if another process holds it. The installer may or may not detect this conflict; verifying port 25 is free before installation prevents a confusing "address already in use" failure.

File descriptor and ulimit setup

PowerMTA holds file descriptors for SMTP connections, spool files, and log files. The Linux default of 1024 open files per process is too low for any production PowerMTA.

Configure ulimit before installation. Create /etc/security/limits.d/99-pmta.conf:

pmta soft nofile 65536
pmta hard nofile 65536
pmta soft nproc 16384
pmta hard nproc 16384

For systemd-managed PowerMTA, also configure the service unit. After installation, create /etc/systemd/system/pmta.service.d/override.conf:

[Service]
LimitNOFILE=65536
LimitNPROC=16384

Apply with systemctl daemon-reload and restart PowerMTA. Verify the limits took effect:

cat /proc/$(pgrep pmtad)/limits | grep "open files"

Should show 65536 rather than 1024. The values here (65536) are appropriate for moderate production; high-volume deployments scale higher (100000+) as covered in our high-volume tuning guide. For initial installation, 65536 is a reasonable starting point that prevents the "too many open files" errors that the default 1024 produces under any real load.

Upgrade path 5.5 to 6.0

Operators on PowerMTA 5.5 considering the upgrade to 6.0 follow a defined path:

Step 1: obtain the 6.0 license. Request the 6.0 License Activation Key from Bird. Critically, keep the 5.5 license valid during the transition; running both versions during migration requires both licenses.

Step 2: verify OS compatibility. PowerMTA 6.0's OpenSSL 3.0.8 requirement means the OS should provide OpenSSL 3.x. If currently on an older distribution with OpenSSL 1.1.x, the OS may need upgrading first, which is a larger undertaking than the PowerMTA upgrade itself.

Step 3: review TLS configuration. OpenSSL 3.0 disallows legacy algorithms and weak keys. Audit current TLS certificate key sizes and cipher configurations. Certificates with RSA keys under 2048 bits or configurations relying on deprecated ciphers need updating before the 6.0 upgrade.

Step 4: test in staging. Install PowerMTA 6.0 in a staging environment with the 6.0 license. Verify configuration loads, TLS works, deliveries succeed, accounting writes correctly. The configuration format is largely compatible between 5.5 and 6.0 but TLS-related directives are the area most likely to need adjustment.

Step 5: schedule production upgrade. Plan a maintenance window. Download the 6.0 installer, ensure the 6.0 LAK is in place, run the upgrade, verify operation. Keep the 5.5 installer and license available for rollback if issues arise.

Step 6: verify post-upgrade. Confirm PowerMTA 6.0 starts cleanly, license validates, TLS handshakes succeed with receiving MTAs, accounting log writes correctly, queue processing works normally.

Operators on 5.5 are not forced to upgrade immediately. PowerMTA 5.5 continues to function. But the security benefits of 6.0 (modern OpenSSL, FIPS compliance) make the upgrade worthwhile to plan, particularly for deployments with security or compliance requirements.

Common installation failures

The installation failures prerequisite verification prevents:

Outbound port 25 blocked. Installation succeeds, PowerMTA runs, accepts messages, queues them, every delivery times out. Cause: cloud provider blocks outbound 25. Prevention: verify outbound 25 before installing. This is the single most common PowerMTA installation failure.

Port 25 already in use locally. Installation fails or PowerMTA cannot bind its listener. Cause: existing MTA (Postfix) holds port 25. Prevention: disable existing MTA before installation, verify port 25 free.

License key mismatch. PowerMTA 6.0 installed with 5.5 license, or vice versa. Cause: wrong LAK for the version. Prevention: confirm the license matches the PowerMTA version being installed.

License validation network failure. License appears invalid but is actually fine; the failure is network connectivity to Bird's license servers. Cause: firewall blocking outbound license validation traffic. Prevention: ensure outbound connectivity for license validation.

Missing dependency libraries. Installer stops partway with library errors. Cause: required system libraries not present. Prevention: install dependency packages before running installer.

Unsupported or EOL operating system. Installer fails or PowerMTA behaves unpredictably. Cause: CentOS 7, Ubuntu 18.04, or other unsupported OS. Prevention: use a supported distribution.

OpenSSL version mismatch (6.0). PowerMTA 6.0 fails because OS provides OpenSSL 1.1.x rather than 3.x. Cause: OS too old for PowerMTA 6.0. Prevention: use OS with OpenSSL 3.x, or install PowerMTA 5.5 instead.

Insufficient file descriptors. PowerMTA runs but fails under load with "too many open files". Cause: ulimit at default 1024. Prevention: configure ulimit before or immediately after installation.

Insufficient disk space. PowerMTA runs but spool or log writes fail. Cause: small disk partition for /var/spool/pmta or /var/log/pmta. Prevention: provision adequate disk, monitor disk usage.

Hostname not FQDN. PowerMTA presents an invalid EHLO hostname to receiving MTAs, hurting deliverability. Cause: hostname set to a short name rather than FQDN. Prevention: set hostname to a fully qualified domain name with proper DNS.

PowerMTA installation is straightforward when prerequisites are verified beforehand and frustrating when they are not. The supported OS list, hardware sizing, version selection, licensing, the critical port 25 verification, dependencies, OS preparation, and ulimit configuration together form a prerequisite checklist that takes perhaps 30 minutes to work through and saves hours of post-installation debugging. The single most important item is outbound port 25 verification because it is the most common failure and the hardest to diagnose after the fact. Operators who treat prerequisite verification as a required step rather than an optional courtesy produce installations that work the first time.