Install PowerMTA on Ubuntu 24.04

Ubuntu 24.04 LTS is the Debian-family side of this install. The package manager is apt and the package is a .deb, the firewall is UFW rather than firewalld, and the mandatory-access-control layer is AppArmor rather than SELinux — but the seven-step shape from the full install guide is unchanged. If you are weighing the operating system itself, the AlmaLinux 9 and Rocky Linux 9 pages are the RHEL-family counterparts; this page is where the Debian-family specifics live.

The constant everywhere on this site holds here too: PowerMTA is licensed commercial software. You bring a valid license and we automate the work around it — no bundled binary, no key, nothing that helps run a cracked build. If avoiding the license is the point, the KumoMTA route at the end runs on Ubuntu 24.04 for free.

Why Ubuntu 24.04 LTS is a sound base for a sender

Noble Numbat, released in April 2024, is the modern Ubuntu long-term-support baseline: Linux kernel 6.8, systemd 255, OpenSSH 9.6, and an OpenSSL 3 crypto stack. For a mail server, two of its properties matter more than the version numbers.

The first is the support runway. Standard security maintenance runs five years to 31 May 2029. An Ubuntu Pro subscription — free for personal use on up to five machines — extends that to ten years, to 2034, and adds Kernel Livepatch, which applies kernel security fixes without a reboot. For a host whose value is a warmed, trusted IP, rebootless patching is a real benefit: you keep the server current without an interruption that could disturb sending. Pro is optional, but on a box you intend to leave running for years it is worth a look.

The second is the default hardening. Ubuntu 24.04 ships with a stronger out-of-the-box posture than its predecessor: restrictions on unprivileged user namespaces backed by AppArmor, hardened package builds, and — directly relevant to email — TLS 1.0 and 1.1 disabled by default in the system libraries. Modern receivers expect modern TLS, so a base that refuses the obsolete protocols is working in your favour rather than against it.

Ubuntu or a RHEL rebuild for this job

PowerMTA and KumoMTA run equally well on Debian-family and RHEL-family systems, so the choice is about the surrounding tooling and what your team already knows. The honest differences for a mail server:

• Packages. Ubuntu uses apt and .deb; the RHEL rebuilds use dnf and .rpm. The vendor ships both formats.
• Firewall. UFW on Ubuntu, firewalld on the RHEL family. Both end up driving the kernel's netfilter; the command syntax differs.
• Mandatory access control. AppArmor on Ubuntu, SELinux on the RHEL family. AppArmor is path-based and generally lighter to reason about; SELinux is label-based and stricter. For PowerMTA, neither ships a vendor profile, so the practical work is similar.
• Lifecycle. Ubuntu 24.04 standard support to 2029 (2034 with Pro); AlmaLinux and Rocky 9 to 2032. Either gives you years of runway.

There is no wrong answer here. Pick the family your operators patch and troubleshoot fastest, and standardise on it so you are not maintaining two playbooks.

What you need before you start

A clean Ubuntu 24.04 server with sudo. A valid PowerMTA license, and the .deb built for your CPU architecture. Control of DNS for the sending domain and the server's PTR record. Outbound port 25 actually permitted by the provider. And a hostname you intend to keep, because renaming a warmed host throws away reputation tied to the name.

1. Update and set the hostname

sudo apt update && sudo apt -y full-upgrade
sudo apt install -y wget curl ca-certificates dnsutils
sudo hostnamectl set-hostname mail.example.com

Reboot after the first large upgrade so the current kernel is running before the mail service starts. Confirm the hostname matches what you publish in DNS and in the PTR record — HELO, forward DNS and reverse DNS all agreeing is a baseline deliverability requirement. If you plan to attach Ubuntu Pro for Livepatch, this is the moment to do it.

2. Free port 25 from Postfix and confirm egress

Two separate things have to be true: nothing local holds port 25, and the provider lets traffic leave on it. On Ubuntu the local culprit is almost always Postfix, which gets pulled in as a dependency of other packages and starts on 25.

sudo systemctl stop postfix 2>/dev/null
sudo apt -y purge postfix              # remove it cleanly
sudo ss -lntp | grep ':25 '            # nothing should answer now

The provider side is the one that quietly defeats fresh installs. Most clouds block outbound port 25 by default and lift it only on request, and that block is upstream of your server where UFW cannot reach it. The mechanics are identical across operating systems, so rather than repeat them, the connection-timed-out fix covers the full diagnosis. Confirm egress before debugging anything else:

# should connect; if it hangs, egress is blocked upstream
nc -zv -w5 gmail-smtp-in.l.google.com 25

3. Open UFW for SMTP

UFW is Ubuntu's firewall front end over the kernel's nftables. Allow inbound SMTP 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 ufw allow 25/tcp
sudo ufw allow from 203.0.113.4 to any port 8080 proto tcp
sudo ufw enable
sudo ufw status verbose

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 — an exposed, unauthenticated MTA dashboard on a reputable sending host is worth more to an attacker than most people expect. Note that ufw enable on a remote box will not drop your SSH session as long as port 22 is allowed (it is, by Ubuntu's default profile), but confirm an SSH allow rule exists before enabling if you have customised anything.

4. Install the PowerMTA .deb

Upload the .deb from your vendor portal, matched to your architecture, then install it and let apt resolve dependencies.

dpkg --print-architecture                # amd64 or arm64?
sudo dpkg -i PowerMTA-6.0r4.amd64.deb
sudo apt -f install                      # pull any missing dependencies

The dpkg -i step can report unmet dependencies on a minimal server; apt -f install immediately afterward fixes them by installing what is missing. Typical dependencies are the OpenSSL and PCRE runtime libraries, which Noble already carries. After install the files land predictably: /etc/pmta/config for configuration, /usr/sbin/pmta for control, and /var/log/pmta/ for logs.

The libssl trap on Noble — use a 6.0 build

There is a specific dependency trap on Ubuntu 24.04 that older guides will walk you straight into. Noble ships only OpenSSL 3; the previous-generation libssl1.1 package is gone from the archive entirely. A PowerMTA .deb from the 5.x line was linked against OpenSSL 1.1.1, so on Noble its dependency on libssl1.1 cannot be satisfied — apt -f install will not conjure a package that no longer exists, and the install stalls. The fix is not to hunt down an obsolete library and force it in; that leaves you with an unsupported, insecure shim. The fix is to use a PowerMTA 6.0 build, which was rebuilt against OpenSSL 3.0.8 precisely so it links cleanly on current systems. This is the same reason 6.0 dropped CentOS 7 and Debian 9: those carried the retired OpenSSL 1.1.1. On Ubuntu 24.04 the right combination is unambiguous — a 6.0 package with a 6.0 license key.

The architecture check that the old guides get wrong

For years the standard advice was "use a 64-bit x86 server," and the package is for architecture error was treated as a sign you had strayed onto the wrong hardware. PowerMTA 6.0 changed that by adding ARM support. On an arm64 instance — Ampere, AWS Graviton, Google Axion — you now install the arm64 build rather than being told to switch servers. The rule is simply to match: read dpkg --print-architecture and use the package that agrees with it. The error means a mismatch, not that ARM is unsupported.

5. AppArmor and Ubuntu 24.04 hardening

AppArmor is Ubuntu's mandatory-access-control system, the analog to SELinux on the RHEL family. The practical situation for PowerMTA is straightforward: the vendor package does not ship an AppArmor profile, so the daemon runs unconfined, which is normal for third-party software. You can check what is confined on the box and, if your security policy requires it, author a profile.

sudo aa-status                           # what profiles are loaded and enforcing

If you do write a profile, the workflow mirrors SELinux's validate-then-enforce: load it in complain mode, exercise PowerMTA with a real send, refine the profile from the logged accesses with aa-logprof, then switch it to enforce. For most operators that is optional. The Ubuntu 24.04 hardening that affects you whether or not you touch AppArmor is already on by default — restricted unprivileged user namespaces, hardened builds, and TLS 1.0 and 1.1 disabled in the system libraries. That last one is a gift for a sender: obsolete TLS is exactly what you do not want to negotiate with a modern receiver.

The unprivileged-user-namespace restriction is the one item that can surprise you. Ubuntu 24.04 uses AppArmor to limit which unprivileged programs may create user namespaces — a change that hardens the box against a class of local privilege-escalation tricks, but that can also block legitimate software which relies on that capability, such as some sandboxed helpers or container tooling you might run alongside the MTA. PowerMTA itself does not need it, so a default install is unaffected. If a companion tool breaks with a namespace-related error, the control is the sysctl kernel.apparmor_restrict_unprivileged_userns; the correct response is to grant the specific program an AppArmor profile that permits the capability rather than to switch the protection off globally. Knowing the knob exists saves an afternoon of confusion when it does bite.

6. Activate the license and start the service

Apply your 6.0 License Activation Key in the configuration, then enable and start the service through systemd 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, check that the key is a 6.0 key and that the clock is correct — a wrong system time can make a valid license read as expired. Sync time first:

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

One Ubuntu detail worth knowing: the host resolver is systemd-resolved, listening on 127.0.0.53. PowerMTA does its own DNS for MX lookups, but your command-line tools (dig, host) go through the stub resolver, so keep that in mind when you are verifying records. From here the real configuration — virtual MTAs, IP pools, authentication, throttling — happens in /etc/pmta/config.

At real volume, DNS becomes a quiet performance factor: every recipient domain means MX and policy lookups, and a high-throughput sender can generate a great many of them per second. The default systemd-resolved stub is fine for ordinary use, but if you are pushing serious volume it is worth running a local caching resolver — unbound on the loopback is the usual choice — so repeated lookups for the big providers are answered locally instead of round-tripping to an upstream server each time. Point PowerMTA's resolver configuration at it, keep the cache warm, and you remove DNS latency from the send path. This is tuning, not a requirement; a modest sender will never notice, but a large one will feel it.

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. 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 fresh.
• 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 Ubuntu 24.04 instead

If the license is the blocker, KumoMTA is the open-source path on the same OS, and Ubuntu is one of its better-trodden platforms. It is the first open-source high-volume MTA — Rust, Lua policy, Apache 2.0 — installed from its own apt repository, running as the kumod service with its policy under /opt/kumomta. Everything Ubuntu-specific above still applies: purge Postfix, the same UFW rules, AppArmor as the MAC layer, and the same PTR and authentication requirements. 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 install pillar and the comparison content cover the trade-offs if you have not decided between the engines.

Ubuntu-specific mistakes to avoid

• Assuming x86 only. PowerMTA 6.0 supports arm64. Match the package to dpkg --print-architecture instead of insisting on a particular CPU.
• Letting Postfix linger. It comes in as a dependency and grabs port 25. Purge it before installing PowerMTA.
• Running dpkg -i and stopping at the dependency error. Follow it with apt -f install; the error is expected on a minimal box.
• Forgetting to enable UFW, or enabling it without an SSH rule. Confirm port 22 is allowed before ufw enable on a remote server.
• Disabling AppArmor wholesale. You do not need to. PowerMTA runs unconfined already; leave the system's other profiles in place.
• Treating the egress block as a config bug. If mail defers endlessly, check outbound 25 at the provider before touching /etc/pmta/config.

The bottom line

Ubuntu 24.04 LTS is a strong base for a long-lived sender: a five-year standard runway to 2029, ten with Pro, a kernel and TLS stack that default to modern behaviour, and Livepatch for rebootless patching of a host you would rather not interrupt. The install is the Debian-family flow — purge Postfix and confirm egress, open UFW narrowly, install the .deb that matches your architecture with dpkg -i then apt -f install, understand that AppArmor is the MAC layer, activate a 6.0 license key, and verify reverse DNS and authentication before sending. The two things that catch people on Ubuntu specifically are the outdated x86-only assumption — gone since 6.0 added ARM — and Postfix quietly holding port 25.

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 on Ubuntu and Debian. The standard does not move: a licensed or open-source engine, opt-in sending only, real deliverability work, and nothing that helps spam.