Managed PowerMTA
on European hardware.

The config.cf file is where the personality of the installation lives. Listener ports, TLS settings, DKIM signing, throttling tables, and the per-domain policy maps. The snippet below is from the global domain block we apply by default — DKIM signing on all messages, also signing the Feedback-ID and List-Unsubscribe headers as the Google and Yahoo bulk sender rules require, and optimistic TLS so that mailbox providers that support STARTTLS get encryption while older relays do not break.

## Global domain defaults — apply unless overridden per-receiving-domain
<domain *>
  dkim-sign           yes
  dkim-algorithm      rsa-sha256     # RFC 8463, default since 2018
  dkim-body-canon     simple         # DKIMCore recommendation
  dkim-headers        Feedback-ID,List-Unsubscribe
  use-starttls        yes
  require-starttls    no             # optimistic — try, do not require
  max-msg-rate        200/min        # default; overridden per-domain below
  backoff-policy      aggressive     # lower retry delays under load
</domain>

Per-receiving-domain throttling is where most senders go wrong. Gmail at 200/min from a freshly warmed IP will defer the moment you push past their per-source threshold; Microsoft tolerates higher concurrency but punishes elevated complaint rates more aggressively than the others. The numbers below are starting points, not absolutes — we tune them per client based on the per-domain placement reports we run weekly.

## Per-receiving-domain throttling — production starting points
<domain gmail.com>
  max-msg-rate        120/min
  max-smtp-out        15            # concurrent connections, per IP
  backoff-max-msg-rate 30/min       # under deferral, ramp down hard
</domain>

<domain outlook.com>
  max-msg-rate        300/min       # Microsoft tolerates higher rate
  max-smtp-out        25
  backoff-max-msg-rate 60/min
</domain>

<domain yahoo.com>
  max-msg-rate        100/min       # strict on per-IP volume
  max-smtp-out        10
</domain>

The bounce processor is the second pillar. PowerMTA classifies bounces into well-defined categories that map cleanly to deliverability decisions: bad-mailbox, bad-domain, routing-errors, and inactive-mailbox are hard bounces — the recipient should be removed from the list immediately. spam-related and policy-related are reputation bounces that need investigation rather than deletion. bad-configuration, bad-connection, quota-issues are soft — the message will retry. We integrate with the Magicdude4eva PowerMTA bounce handler (the de-facto standard since 2016) or a custom Logstash pipe that feeds Graylog, depending on what your stack already runs.

Hard bounces (immediate suppression):
  bad-mailbox       — mailbox does not exist
  bad-domain        — recipient domain has no MX
  routing-errors    — relay loop, DNS failure
  inactive-mailbox  — recipient marked as no longer accepting

Reputation bounces (investigate before suppressing):
  spam-related      — receiving server flagged as spam
  policy-related    — content policy or RBL listing

Soft bounces (retry, escalate after N consecutive):
  bad-connection    — transient network failure
  bad-configuration — DKIM/SPF temporary check failure
  quota-issues      — recipient mailbox full
  content-related   — message structure issue
  invalid-sender    — return-path rejected

The third pillar is FBL processing — feedback loops where mailbox providers tell you when a recipient marked your message as spam. Yahoo's CFL is still active and well-documented. AOL still operates the legacy FBL despite folding into Yahoo. Microsoft retired the SNDS-based loop and now requires you to read the postmaster portal directly (we automate that read). Gmail does not have a public FBL — they use Postmaster Tools instead, which we also pull into your dashboard. Every complaint that comes back is matched against the original send and added to the suppression list within a minute. That recipient never gets another message from you.

The fourth pillar is the accounting log pipeline. PowerMTA writes a per-message CSV to /var/log/pmta/acct.csv with timestamps, source IP, destination domain, response code, and latency. By itself this is a flat file. Through Logstash it becomes a structured stream into Graylog or Elasticsearch, where we can query placement by domain, reputation drift by IP, and bounce trends by traffic class — in real time, not the next morning. Every Sender-tier client gets a Grafana view of their fleet. Enterprise clients get a custom dashboard wired to their suppression and analytics stack.

Vendor throughput numbers are useless and everyone in this industry knows it. Port25 publishes "300+ million messages per hour per server" on the PowerMTA datasheet. The real number on a single 32-core VM with the same configuration we ship is closer to 15 million per hour, sustained, with full DKIM signing and per-domain throttling enforced. The gap between 300 million theoretical and 15 million in production is not a bug — it is the difference between a synthetic benchmark on a closed loopback and a real workload pacing against real receiver throttles. Operators who size capacity from datasheet numbers run into the same wall every time. We size from production curves we measured ourselves.

The chart below shows the actual throughput curve for one of our 32-core PowerMTA boxes against the same workload on three alternatives — Postfix tuned aggressively, Haraka with default queueing, and KumoMTA with Lua throttle scripts. Same hardware, same target receivers, same message corpus of 100,000 distinct recipients across 50 domains, full DKIM 2048-bit signing on every message. PowerMTA peaks at roughly 15 million per hour. KumoMTA reaches 11 million. Haraka tops out at 4 million before queue depth becomes the bottleneck. Postfix, even with aggressive tuning, holds at 1.5 million. The numbers are surprising in two directions — Postfix is closer than the marketing of either commercial MTA suggests, and KumoMTA is closer to PowerMTA than the licence-fee gap implies.

Three things are worth pulling out of those numbers. First, throughput at the MTA layer is rarely the bottleneck for senders below 50 million messages per month — every option in the chart handles that volume on a single box. Second, the gap between commercial MTAs and the open-source alternatives narrowed significantly between 2022 and 2026 as KumoMTA matured. Third, the production curve looks nothing like the vendor curve, regardless of which vendor. Choose your MTA based on operational fit — configuration model, monitoring story, runtime extensibility — not on the number on the datasheet. We have run all four in production at this point. The operational differences matter more than the throughput differences for everyone except the very largest senders.

PowerMTA is the right choice when your team has muscle memory in the PMTA flat-file syntax accumulated over years; when procurement requires a vendor SLA backed by a commercial entity (Bird) for compliance reasons; when you are running a mature pipeline where the configuration is stable and the cost-per-server is negligible against your sending revenue; or when you are migrating from an older PMTA install and the existing config can be lifted across with minor adjustments rather than rewritten in Lua. Most large ESPs that started in the 2010s are in this position. Continuity has real value when the alternative is a six-month config rewrite project.

PowerMTA is not the right choice when you are starting fresh with no existing config to preserve and no procurement constraint forcing the commercial route; when the per-server license cost is meaningful against your margin; when you want programmability that goes beyond the flat-file directive set; or when your operations style is "configuration as code" with everything checked into git and reviewed in pull requests. KumoMTA's Lua configuration is genuinely better for that workflow.

For volume, the rough rule we use: under 1M emails a month, neither PowerMTA nor KumoMTA pays for itself — the SMTP Relay tier at €89/month is the right answer. 1M to 10M a month, both are reasonable; the choice comes down to team familiarity. Above 10M, you want dedicated MTA either way, and the choice is whether you value the commercial backing more than the Lua flexibility. Above 100M a month, almost everyone we run has both — PMTA on the legacy IPs, KumoMTA on the newer ones, gradually migrating.

If you want a side-by-side comparison table covering 10 dimensions (licensing, throughput, configuration, throttling, observability, webhooks, IP routing, lock-in, sovereignty, best-fit volume), it is on the home page in the Choosing your MTA section.

The €449 monthly figure is what you see on the invoice. The total cost of running PowerMTA yourself climbs well past the managed figure once everything is included. Hardware depreciation if you self-host. The PowerMTA licence itself if you buy direct from Port25 — usually €4,000 to €8,000 per year per server, varying by tier. Engineer hours for ongoing tuning plus monitoring plus incident response — typically 8 to 14 hours per month at fully loaded €120 per hour. Network egress and IP rental if your provider charges for those. The chart below tracks actual 24-month spend across three deployment models we have run for clients in 2024 and 2025, normalised to a 5 million messages per month workload.

Three deployments compared. The first is self-hosted on AWS m6i.4xlarge with PowerMTA bought direct from Port25 — the cheapest looking option on month one and the most expensive by month twelve once licence renewal lands. The second is self-hosted on a colocated bare metal server with the same direct licence — lower hardware cost than AWS, but the licence dominates and the engineer hours are the same. The third is BIG BOX hosting at the Multi-IP tier, €949 per month for multi-IP PowerMTA with the Port25 licence and the engineer hours included in the figure. The self-hosted AWS path crosses €30,000 cumulative before the BIG BOX line, because the €6,000 annual licence and the twelve monthly engineer-hours land on top of the instance cost. The bare-metal path is cheaper on hardware but carries the same licence and labour, so it crosses our line later but still crosses it. The point is not the headline monthly figure — it is everything that sits underneath the self-hosted number and never appears until the invoice does.

The TCO comparison is not the argument we usually lead with because it sounds self-serving. It is the argument that holds up under audit. Procurement teams that build their own model with their own engineer rates and their own AWS quotes land in the same neighbourhood every time. The variable that breaks the model in our favour is engineer hours — clients consistently estimate the time their team will spend on monitoring, incident response, and licence management at half what it actually takes. Our pricing is fixed in advance because the operational time is on us. That predictability is worth more than the headline number on month one suggests.

Five things. We learned them the hard way and the vendor documentation does not mention any of them. None are reasons not to use PowerMTA — we run more PowerMTA than KumoMTA across the client base, and have for years. But they are operational realities that change how you should run it on day one rather than discovering them in production. If you are evaluating the product for the first time, knowing these in advance saves between four and eight weeks of avoidable incidents.

1 — The flat-file config trap

The first thing is that PowerMTA's flat-file configuration syntax is harder to manage at scale than it looks. A 4,000-line pmta.conf for a multi-tenant deployment with 50 sending domains looks readable until you need to change the throttle for one specific receiver across 30 of those domains. That edit is 30 separate text replacements, each at a different line offset, with no way to validate consistency programmatically. We have made this mistake. We caught one incident in 2024 where an apparently identical change was applied to 27 of 30 domains because the operator missed three near-duplicate stanzas during a manual review at 2am. The remaining three domains kept the old throttle, started exceeding receiver limits, and earned a 24-hour soft-block at Yahoo before anyone noticed. The lesson is to template the config externally — Ansible or Jinja generating pmta.conf from a YAML inventory — instead of editing the file directly.

2 — The bounce parser is dated

Second, PowerMTA's bounce categorisation is conservative and dated. The default rules treat bounces by SMTP code prefix — 5xx as hard, 4xx as soft — and the bounce categorisation file (bouncecategories.csv) ships with patterns that have not been meaningfully updated to match how the major ISPs phrase modern reputation rejections. A Gmail rejection that says "your message did not pass authentication" gets binned as "spam" by default, when it should be "authentication-failure" so the reputation team can route it differently. We maintain a fork of the bounce categorisation file with thirty-eight additional patterns we have observed in 2024 and 2025, and ship it as part of the standard config. Without that, the reputation dashboard makes the wrong recommendations to the operator more often than it gets it right.

3 — The per-IP queue depth limit

Third, the per-IP queue depth limit. PowerMTA documents a queue depth setting and most operators tune it once during initial deployment and never look at it again. What the docs don't tell you is that the default of 5,000 messages per VirtualMTA queue interacts badly with burst patterns where a single recipient receives a thousand messages in a five-minute window. The queue fills, new injections get deferred, and the operator sees a deliverability problem that looks like a receiver issue but is actually self-inflicted backpressure. The fix is two configuration lines. The discovery, if you have not seen this pattern before, takes about three days of debugging to trace from "Gmail volume is dropping" to "our own queue manager is the bottleneck."

4 — TLS cert renewal is not handled

Fourth, PowerMTA does not handle TLS certificate renewal automatically. The product expects you to drop new certs in a specific path and reload the daemon — there is no Let's Encrypt integration, no auto-renew, no graceful failure when a cert is about to expire. We have audited deployments where production senders served expired TLS certificates for weeks because the renewal cron failed silently and nobody had alerting on the cert expiration date. Every PowerMTA installation needs an external monitoring layer specifically for cert expiration. We use Prometheus blackbox exporter pointing at port 25 with STARTTLS probing, alert if expiry is under 30 days. That alone has caught seven near-incidents in the last eighteen months across the client base.

5 — The memory profile under multi-VMTA load

Fifth, the memory profile under heavy multi-VirtualMTA load. PowerMTA's process model holds in-memory state per VMTA, and the resident set size grows roughly linearly with active VMTAs above 200. We have seen a 64 GB box become memory-bound at around 800 active VMTAs, well below where CPU or network throughput would be the limit. The symptom is not a clean OOM. It is gradual swap pressure that degrades latency from sub-second to multi-second over the course of an hour, then catastrophic recovery when the kernel reclaims pages. Sizing for VMTA count, not just throughput, is something the documentation does not emphasise. We size for two GB of headroom per 100 VMTAs above the baseline, and we monitor RSS hourly. The cost is one extra dashboard panel. The benefit is not getting paged at three in the morning.