Contents
Why throughput diagnosis goes wrong
When a PowerMTA operation cannot send as fast as it wants, the instinct is to look at PowerMTA, the server, the configuration, for a performance problem. Sometimes that instinct is right. But far more often it is wrong, and an operator who spends a day tuning the PowerMTA server when the real constraint is the receiving ISPs has spent that day on the wrong problem.
This guide exists to make throughput diagnosis systematic, so the operator finds the actual bottleneck rather than the assumed one. The central message is that there are three distinct kinds of throughput bottleneck, ISP-imposed, server-resource, and configuration, and they have different signatures and different fixes; the diagnosis is fundamentally a matter of localizing which one is in play before doing any tuning. The structure of this guide: why throughput diagnosis goes wrong, the crucial fact that the ISP is usually the bottleneck, the three bottleneck types, localizing the bottleneck, the server resource bottlenecks, the configuration bottlenecks, the DNS bottleneck, and the structured diagnosis workflow.
The ISP is usually the bottleneck
The single most important fact in throughput diagnosis: the receiving ISPs are usually the bottleneck, not PowerMTA.
PowerMTA on capable hardware can deliver enormous volumes; its raw capacity is high. But PowerMTA delivers to receivers, and each receiver, Gmail, Yahoo, Microsoft, accepts mail from a given sender only as fast as that sender's reputation and the receiver's policies allow. Push faster than a receiver wants, and the receiver throttles, deferring mail with 4xx codes, and that throttling caps the effective rate regardless of how fast PowerMTA could theoretically send.
So in the typical case, the bottleneck is the ISPs' acceptance, governed by the sender's reputation. The throughput an operation achieves is mostly a function of its reputation with the receivers, not its server's horsepower.
The expensive diagnostic mistake is assuming a throughput problem is a PowerMTA performance problem and tuning the server, more memory, more CPU, configuration changes, when the real constraint is the receivers throttling a sender whose reputation does not support a higher rate. No amount of server tuning raises throughput that the ISPs are capping. If the accounting log shows the throughput is limited by 4xx throttle codes from the receivers, the bottleneck is the ISPs, and the answer is reputation work, list quality, engagement, complaint reduction, warming, not server tuning. The first question in throughput diagnosis must be whether the limit is ISP-imposed, because answering it wrong sends the operator down a fruitless path.
This does not mean server-side and configuration bottlenecks never happen, they do, and the rest of this guide covers them. It means the diagnosis must start by determining which kind of bottleneck is actually present, rather than assuming it is a server problem.
The three bottleneck types
A PowerMTA throughput bottleneck falls into one of three categories:
| Bottleneck type | What limits throughput | Signature |
|---|---|---|
| ISP-imposed | The receivers throttle the sender | 4xx throttle codes in the accounting log |
| Server resource | A server resource is at its limit | A maxed-out resource metric |
| Configuration | PowerMTA's own limits set too low | Capped below ISP tolerance and server capacity |
An ISP-imposed bottleneck is the receivers throttling the sender. The throughput is capped because the receivers will not accept faster. The signature is throttle codes in the accounting log.
A server resource bottleneck is a resource on the PowerMTA server, file descriptors, memory, CPU, disk I/O, hitting its limit. The throughput is capped by the server's own constraint. The signature is a server resource metric maxed out.
A configuration bottleneck is PowerMTA's own rate or connection limits set too low. PowerMTA is self-limiting, sending below what the receivers would accept and below what the server could handle. The signature is throughput capped with neither throttle codes nor resource exhaustion.
The whole of throughput diagnosis is identifying which of these three is the actual bottleneck, because each has a completely different fix: reputation work for ISP-imposed, server tuning for server-resource, configuration adjustment for configuration. Tuning the wrong one accomplishes nothing.
Localizing the bottleneck
Localizing the bottleneck to one of the three types is done by reading two things: the accounting log and the server's resource metrics.
Read the accounting log for throttle codes. Query the accounting log for the deferrals and their diagnostic text. If the throughput is capped and the log is full of 4xx throttle deferrals, Yahoo TSS codes, Microsoft S-codes, Gmail rate-limit phrasing, the receivers are throttling, and the bottleneck is ISP-imposed.
Read the server resource metrics. Check the server's file descriptor usage, memory, CPU, and disk I/O. If a resource is at its limit, the bottleneck is server-resource.
The two readings together place the bottleneck:
| Accounting log | Server resources | Bottleneck |
|---|---|---|
| Full of throttle codes | Comfortable | ISP-imposed |
| Not dominated by throttling | A resource maxed out | Server resource |
| Not dominated by throttling | Comfortable | Configuration |
If the accounting log shows throttling and the server is comfortable, it is an ISP bottleneck. If the server shows a resource at its limit, it is a server-resource bottleneck. If neither, throughput capped but no throttle codes and no maxed resource, PowerMTA is self-limiting and it is a configuration bottleneck.
This localization is the pivot of the whole diagnosis. It takes only a look at the accounting log and the server metrics, and it tells the operator which of the three problems they actually have, before any tuning is attempted.
The server resource bottlenecks
When the localization points to a server-resource bottleneck, four resources are the candidates.
File descriptors. This is the most commonly overlooked, and often the first to check. PowerMTA opens many simultaneous connections, and each connection and each open file consumes a file descriptor. The operating system limits how many file descriptors a process may hold, and the default limit on many systems is far too low for a high-volume mail server. If PowerMTA hits the file descriptor limit, it cannot open more connections, and throughput is capped. Tuning the file descriptor limit, the ulimit, upward is a standard part of preparing a server for PowerMTA, and a throughput problem on a server where the ulimit was never raised is very often this.
# Check the file descriptor limit and current usage
ulimit -n
# Check open file descriptors for the PowerMTA process
ls /proc/$(pgrep -x pmtad)/fd 2>/dev/null | wc -lMemory. PowerMTA uses memory for its queues and operations. An undersized server, or one whose queues have grown very large, can run short of memory, which constrains throughput and risks instability. Check memory usage and whether it is near the server's capacity.
CPU. Under very high volume, CPU can be a bottleneck, particularly the cryptographic work of TLS and DKIM signing. CPU is less commonly the limit than file descriptors or memory, but at high volume it should be checked.
Disk I/O. PowerMTA writes the spool and the accounting log to disk. A slow disk, or a disk under heavy contention, slows PowerMTA's spool operations and caps throughput. Check disk I/O utilization and latency.
Of these four, the file descriptor limit deserves first attention because its default is so often inadequate and its symptom, connections not being opened, looks like a performance problem when it is really a single configurable limit. After file descriptors, memory is the next most common server-resource constraint.
The configuration bottlenecks
When the localization points to a configuration bottleneck, PowerMTA is self-limiting: its own settings cap the throughput below what the receivers and the server would allow.
The configuration settings that can throttle PowerMTA's own output:
- Domain block rate limits. A max-msg-rate on a domain block set lower than the receiver actually tolerates limits the rate to that domain unnecessarily.
- Connection limits. max-smtp-out and max-conn-rate set too conservatively limit how much parallel delivery PowerMTA does.
- The default block. A domain default block with very conservative limits caps the rate to all the non-major receivers it governs.
- Per-VMTA rate limits. Per-IP rate caps set low limit each VMTA's output.
The signature of a configuration bottleneck, as noted, is throughput capped with no throttle codes from the receivers (so the receivers would accept more) and no maxed-out server resource (so the server could handle more). PowerMTA is simply configured to send slower than it could.
The fix is to raise the relevant limits, carefully. The important caution: raising a rate limit is only correct if the receiver actually tolerates the higher rate. Raising max-msg-rate above what a receiver accepts does not increase throughput, it pushes the receiver into throttling, converting a configuration bottleneck into an ISP bottleneck. So the configuration adjustment should be informed by the receivers' actual tolerance: raise the limits toward what the receivers accept, observe whether throttling appears, and stop at the rate the receivers handle smoothly.
A configuration bottleneck is, in a sense, the good problem to have, because it has a direct fix within the operator's control, unlike an ISP bottleneck which requires the slow work of reputation. But the fix must respect the receivers' real tolerance, or it just relocates the bottleneck.
The DNS bottleneck
One more bottleneck deserves specific mention because it is easy to overlook: DNS.
PowerMTA depends on DNS to resolve the MX records of the receiving domains it delivers to. Every delivery involves a DNS lookup. If the DNS resolution is slow, a slow resolver, an overloaded resolver, network latency to the resolver, every delivery is delayed by the slow lookup, and throughput is capped by the DNS rather than by anything else.
A DNS bottleneck has a distinctive character: throughput is constrained, but the accounting log does not show ISP throttling, and the server resources are not maxed out. It can look like a configuration bottleneck, but raising configuration limits does not help, because the constraint is the time each delivery spends waiting on DNS.
Checking for a DNS bottleneck: test the DNS resolution speed from the PowerMTA server, query some MX records and measure the response time. Slow responses point at the DNS. The fix is to improve the DNS resolution, a faster or local resolver, a well-provisioned caching resolver close to the PowerMTA server, so DNS lookups are fast and do not gate delivery.
For a high-volume PowerMTA deployment, a fast, reliable, well-provisioned DNS resolver is part of the infrastructure, and a DNS resolver that was adequate at lower volume can become a bottleneck as volume grows. When a throughput problem does not fit the ISP, server-resource, or configuration pattern cleanly, DNS is the thing to check.
The throughput diagnosis workflow
The structured workflow for diagnosing a throughput bottleneck:
Step 1: confirm the throughput problem is real. Confirm PowerMTA actually has more mail to send than it is sending, queues accumulating, rather than simply having less to send. A low rate with no backlog is not a bottleneck.
Step 2: read the accounting log for throttle codes. Check whether the deferrals are dominated by 4xx throttle codes from the receivers. If so, the bottleneck is ISP-imposed.
Step 3: read the server resource metrics. Check file descriptors, memory, CPU, and disk I/O. If a resource is at its limit, the bottleneck is server-resource.
Step 4: localize. From steps 2 and 3, place the bottleneck. Throttle codes plus comfortable server means ISP-imposed. A maxed resource means server-resource. Neither means configuration or DNS.
Step 5: for an ISP bottleneck, do reputation work. The throughput is limited by reputation. The path to higher throughput is improving reputation, list quality, engagement, complaint reduction, and warming additional IP capacity. Server and configuration tuning will not help.
Step 6: for a server-resource bottleneck, tune the resource. Raise the file descriptor limit if that is the constraint, add memory if memory is short, address CPU or disk I/O as needed.
Step 7: for a configuration bottleneck, raise the limits carefully. Raise the domain block rates, connection limits, or per-VMTA limits toward what the receivers tolerate, observing for throttling and stopping at the rate the receivers accept smoothly.
Step 8: if it fits none cleanly, check DNS. Test the DNS resolution speed; a slow resolver caps throughput in a way that looks like a configuration problem but is not.
Step 9: re-measure and iterate. After addressing the identified bottleneck, re-measure the throughput. Removing one bottleneck can reveal the next, a server-resource fix may uncover that the ISP is now the limit, so the diagnosis may iterate.
An operator we worked with was frustrated that their PowerMTA throughput had plateaued. They had a substantial sending volume, the queues were backing up, and they could not push the rate higher. They concluded the server had become underpowered for their volume, and they invested in a significant server upgrade, more CPU, more memory, faster storage, expecting the upgrade to lift the throughput ceiling. After the upgrade, the throughput was essentially unchanged. The queues still backed up, the rate still plateaued at the same level. The expensive upgrade had bought them nothing, and they could not understand why. We went through the throughput diagnosis with them properly, starting with the accounting log. The accounting log told the story immediately: the deferrals were overwhelmingly 4xx throttle codes from the major receivers. The receivers were throttling their mail, and the throughput was capped at exactly the rate the receivers were willing to accept. The server, both before and after the upgrade, had never been the bottleneck, its resources had been comfortable all along, which is why a more powerful server changed nothing. The bottleneck was ISP-imposed: the operator's sending reputation with the major receivers did not support a higher rate, and the receivers were throttling them down to the rate their reputation justified. The real path to higher throughput was not a faster server, it was reputation work: improving their list quality to reduce the spam-trap hits and bounces dragging their reputation down, improving engagement, reducing complaints, and warming additional IP capacity to spread the volume. That work was slower and less satisfying than buying a server, but it was the only thing that would actually lift the ceiling, because the ceiling was the receivers' acceptance, not the server's capacity. The lesson is the central one of throughput diagnosis: the ISP is usually the bottleneck, and the accounting log reveals it in minutes. The operator had assumed a throughput plateau was a server performance problem and spent significantly on a server upgrade without ever checking the accounting log, which would have shown them, before they spent anything, that the receivers were the constraint and no server could change that.
Diagnosing a PowerMTA throughput bottleneck is fundamentally about localizing which of three bottlenecks is actually in play, ISP-imposed throttling, a server-resource limit, or a configuration limit, before doing any tuning, because each has a different fix and tuning the wrong one accomplishes nothing. The crucial fact is that the ISP is usually the bottleneck: PowerMTA's raw capacity is high, and the throughput an operation achieves is mostly governed by its reputation with the receivers, not its server's horsepower. The localization is quick, the accounting log shows throttle codes for an ISP bottleneck, the server metrics show a maxed resource for a server-resource bottleneck, and neither signature points to a configuration limit or a slow DNS resolver. An ISP bottleneck is answered by reputation work, a server-resource bottleneck by tuning the constrained resource (the file descriptor limit first of all), a configuration bottleneck by raising PowerMTA's limits toward the receivers' real tolerance. Operators who read the accounting log and the server metrics before tuning find the actual bottleneck and fix it; operators who assume a throughput plateau is a server problem, as the case shows, can spend heavily on a server upgrade that changes nothing because the receivers were the limit all along.