Contents
- Why connection limits matter
- What max-smtp-out controls
- Connection count versus connection rate
- Why too many connections is a negative signal
- Receiver sensitivity to connections
- Tuning per domain, not globally
- Connections and the message rate
- Observing to find the right values
- When connection limits are wrong
Why connection limits matter
An operator tuning PowerMTA for throughput naturally thinks about message rates, but the connection limits, how many SMTP connections PowerMTA opens and how fast, are an equally important and sometimes overlooked lever. Connection limits affect both the throughput PowerMTA can achieve and, crucially, how receivers perceive the sender, because an excessive number of connections is itself a negative signal that triggers receiver defenses.
This guide exists to cover the connection-related tuning properly. The structure of this guide: why connection limits matter, what max-smtp-out controls, the distinction between a connection count limit and a connection rate limit, why too many connections is a negative signal, which receivers are particularly sensitive to connection count, why the limits are tuned per domain rather than globally, the relationship between connections and the message rate, observing the accounting log to find the right values, and the diagnostic workflow when connection limits are wrong.
What max-smtp-out controls
The max-smtp-out directive controls the maximum number of simultaneous SMTP connections PowerMTA will open, and it is typically set per domain, controlling the concurrent connections to a particular receiving domain.
When PowerMTA delivers mail to a receiver, it opens SMTP connections to that receiver's mail servers, and it delivers multiple messages in parallel by holding several connections open at once. The max-smtp-out directive sets the ceiling on that concurrency:
<domain example-isp.com>
max-smtp-out 10
</domain>With max-smtp-out set to 10 for a domain, PowerMTA uses up to ten concurrent connections to that domain, delivering up to ten messages in parallel at any moment.
The directive matters because the concurrent connection count affects two things:
- Throughput. More connections allow more parallel delivery, and therefore potentially more throughput.
- How the receiver perceives the sender. More connections mean more load on the receiver and a more aggressive-looking sending pattern.
So max-smtp-out is a key tuning lever for a domain block. Set too low, it can artificially limit throughput by not allowing enough parallel delivery. Set too high, it presents an aggressive connection pattern that the receiver penalizes. The right value gives reasonable parallel delivery while staying within what the receiver comfortably accepts.
Connection count versus connection rate
There are two distinct connection-related limits, and tuning involves both.
| Limit | Directive | Controls |
|---|---|---|
| Connection count | max-smtp-out | How many connections are open simultaneously |
| Connection rate | max-conn-rate | How fast new connections are opened |
The connection count limit, max-smtp-out, controls how many SMTP connections PowerMTA holds open simultaneously, the concurrency. It is a limit on the number of connections in use at any one moment.
The connection rate limit, expressed with a directive such as max-conn-rate, controls how quickly PowerMTA opens new connections, the rate of connection establishment, for example a number of new connections per minute. It is a limit on how fast connections are created, not how many exist at once.
<domain example-isp.com>
max-smtp-out 10
max-conn-rate 10/m
</domain>The two are distinct, and a receiver can be sensitive to either. A receiver might tolerate a moderate number of connections being open but be unhappy if the sender opens them in a sudden burst, that is the connection rate. Or a receiver might accept connections being opened steadily but cap the total simultaneous count, that is the connection count.
So tuning a domain block for connections involves both: max-smtp-out for the concurrency ceiling, and the connection rate limit so connections are not established too aggressively. A connection-related throttling problem with a receiver can be a matter of either, so both are considered when tuning and when diagnosing.
Why too many connections is a negative signal
A central point: too many connections to a receiver is not just a neutral throughput choice, it is itself a negative signal.
Receiving mail servers manage their resources, and a sender that opens a large number of connections consumes the receiver's resources and presents a sending pattern that looks aggressive. Receivers have expectations about how many connections a legitimate sender of a given volume needs, and a sender that far exceeds those expectations stands out as behaving aggressively or abnormally.
Receivers respond to an excessive connection count in several ways:
- They may refuse additional connections beyond a limit.
- They may close connections.
- They may throttle the sender.
- The aggressive connection behavior can feed negatively into how the receiver regards the sender overall.
The tempting assumption is that raising max-smtp-out always raises throughput, more parallel connections, more mail delivered. This holds only up to the point the receiver is comfortable with. Beyond that point, additional connections do not buy more delivered mail; they trigger the receiver's defensive responses, refused connections, closed connections, throttling, which can actually reduce delivery. Connection limits are not purely a throughput lever, they are also a politeness setting that keeps PowerMTA's connection behavior within what the receiver considers reasonable. A sender who sets connection limits high in pursuit of throughput, past the receiver's tolerance, inflicts throttling on themselves.
So the connection limits should be set to a level that provides reasonable parallel delivery without crossing into the aggressive-looking territory that receivers penalize. The goal is enough connections for good throughput, not the maximum possible number.
Receiver sensitivity to connections
Different receivers have different tolerances for connection count, and one in particular deserves specific mention.
Microsoft consumer mail, the Outlook and Hotmail family, is well known for being particularly sensitive to connection count. Microsoft does not tolerate a large number of simultaneous connections from a sender, and it responds to excessive connections with throttling. This is why Microsoft domain blocks are typically configured with conservative connection limits, a deliberately modest max-smtp-out, because Microsoft's connection tolerance is lower than some other receivers'.
Other major receivers are generally more tolerant of connections than Microsoft, but every receiver has a limit, and every receiver treats a sufficiently excessive connection count as a negative signal. The major receivers can handle a reasonable number of connections from a sender with good standing.
The practical implication is that the connection limits should be set with the specific receiver in mind. A connection count appropriate for a tolerant receiver may be too aggressive for Microsoft. This is one of the reasons connection limits are tuned per domain, covered next, the right value genuinely differs by receiver, with Microsoft commonly the most conservative.
An operator setting up domain blocks should give the Microsoft family block conservative connection limits as a matter of course, and tune the other major receivers' limits to their observed tolerances, which are generally more generous but still finite.
Tuning per domain, not globally
The connection limits should be tuned per domain, in the individual domain blocks, rather than relying on a single global value, because the right value differs by receiver.
As established, different receivers have different connection tolerances, Microsoft conservative, others more generous. A single global connection limit cannot be right for all of them: a value conservative enough for Microsoft would needlessly limit throughput to more tolerant receivers, and a value generous enough for the tolerant receivers would be too aggressive for Microsoft.
The structure to use:
- A sensible default in the domain default block. The domain default block can carry a moderate connection limit that is reasonable for the generic receivers without specific blocks.
- Specific limits in the major receivers' blocks. The major receivers, Microsoft, Gmail, Yahoo, with their own domain blocks, carry connection limits tuned to each one's tolerance, Microsoft's conservative, the others' tuned to their observed behavior.
This per-domain approach, using PowerMTA's domain block inheritance, lets each receiver get connection limits appropriate to it. The Microsoft block's conservative limits do not constrain Gmail, and Gmail's more generous limits are not applied to Microsoft.
The connection limits are part of the same per-domain tuning as the message rate, and they should be set thoughtfully for each major receiver as part of configuring that receiver's domain block, informed by the receiver's known character and by observation of how the receiver responds.
Connections and the message rate
The connection limits and the message rate limit are related, and an operator tuning a domain block should understand how they interact.
The message rate, set by max-msg-rate, limits how many messages PowerMTA sends to a domain per unit of time. The connection count, max-smtp-out, limits how many connections are open. The two together shape the delivery to the domain.
The relationship: the messages are delivered over the connections. With more connections, PowerMTA can deliver more messages in parallel, which supports a higher message rate. With few connections, the parallel capacity is limited, which can cap the achievable message rate regardless of what max-msg-rate allows.
So the two limits should be coherent. If max-msg-rate is set high but max-smtp-out is set very low, the few connections may not be able to carry the allowed message rate, and the connection limit becomes the effective constraint. Conversely, if max-smtp-out is generous but max-msg-rate is low, the message rate is the constraint and the extra connection capacity is unused.
In practice, the message rate is usually the primary throttle the operator thinks in terms of, the rate at which they want to send to the receiver, and the connection count should be set to a level that comfortably supports that rate without being excessive. The connection count enables the message rate; it should be sufficient for it but not gratuitously high. When tuning a domain block, the operator sets the message rate to the receiver's reputation-appropriate level, and sets the connection limits to a level that supports that rate while respecting the receiver's connection tolerance.
Observing to find the right values
The right connection limit values are not universal numbers; they are found by observation, the same way message rates are tuned.
The approach:
Start with sensible values. For each major receiver, start with connection limits informed by the receiver's known character, conservative for Microsoft, moderate for the more tolerant receivers.
Watch the accounting log. Observe how the receiver responds. The accounting log shows the delivery results, and connection-related problems show up as connection refusals, connections being closed by the receiver, and throttling responses. If the receiver is refusing or closing connections, or throttling, the connection limits may be too aggressive.
Adjust toward the receiver's tolerance. If the receiver is showing connection-related pushback, reduce the connection limits. If the receiver is accepting the connections smoothly and throughput is constrained, the connection limits can be raised cautiously.
Find the comfortable level. The right value is the one at which the receiver accepts the connections without pushback and the parallel delivery supports the desired message rate. That comfortable level is found by converging on it through observation.
This observational tuning is ongoing, not one-time. A receiver's tolerance can shift, and the sender's reputation, which influences how much the receiver will accept, changes over time. The connection limits, like the message rates, are reviewed and adjusted as the accounting log shows how the receivers are responding. The principle is the same throughout: the receiver's actual behavior, visible in the accounting log, is the guide to the right values.
When connection limits are wrong
When connection limits are set wrong, the diagnostic workflow:
Step 1: identify the symptom. Connection limits set too high show as connection refusals, closed connections, and throttling from a receiver. Connection limits set too low show as throughput to a receiver being capped below what the message rate and reputation would allow.
Step 2: read the accounting log for the receiver. Check the delivery results for the affected domain. Connection refusals and connections closed by the receiver indicate the connection behavior is too aggressive. Look at whether the responses are about connections specifically.
Step 3: for connection pushback, reduce the limits. If the receiver is refusing or closing connections, reduce max-smtp-out, and consider the connection rate, reducing max-conn-rate if connections are being opened too fast. For Microsoft especially, conservative connection limits are correct.
Step 4: distinguish count from rate. Determine whether the problem is the simultaneous count or the establishment rate. If connections are refused once a certain number are open, it is the count, max-smtp-out. If connections are refused when opened in a burst, it is the rate, max-conn-rate.
Step 5: for capped throughput, check if connections are the limit. If throughput to a receiver is capped and the receiver is not throttling, check whether max-smtp-out is too low to support the message rate. If so, raise it cautiously.
Step 6: confirm the message rate and connections are coherent. Verify max-msg-rate and max-smtp-out are coherent, the connection count sufficient to support the message rate without being excessive.
Step 7: adjust, reload, and observe. Make the adjustment, validate and reload the configuration, and observe the receiver's response over the following period to confirm the change resolved the problem.
An operator we worked with was struggling with delivery to the Microsoft family, Outlook and Hotmail. Their mail to Microsoft was being throttled, and they could not understand why, their reputation with Microsoft, as far as SNDS showed, was not bad, their authentication was correct, their content was unremarkable. They had assumed the throttling was a reputation issue and had been working on reputation, with no improvement. When we looked at their PowerMTA configuration, the cause was in the Microsoft domain block, but not in the message rate, in the connection limits. They had configured their domain blocks with a single approach, the same fairly generous connection limits applied across all their major receivers, including Microsoft, with a max-smtp-out set to a value that was reasonable for a tolerant receiver but well above what Microsoft tolerates. They had not given Microsoft its own conservative connection limits, they had treated all receivers the same. Microsoft is particularly sensitive to connection count, it does not accept a large number of simultaneous connections from a sender, and PowerMTA, following the generous max-smtp-out, was opening more concurrent connections to Microsoft than Microsoft was willing to accept. Microsoft was responding exactly as it does to an excessive connection count: it was throttling the sender. The throttling was not a reputation problem at all; it was a direct response to the connection behavior. The accounting log, looked at with this in mind, showed the connection-related pushback from Microsoft that confirmed it. The fix was to give the Microsoft family domain block its own connection limits, a conservative max-smtp-out appropriate to Microsoft's known sensitivity, well below the value that was reasonable for the more tolerant receivers, along with a conservative connection rate. Once PowerMTA was opening only a modest number of connections to Microsoft, within Microsoft's tolerance, the connection-driven throttling stopped, and delivery to the Microsoft family improved, without any change to reputation, which had never been the problem. The lesson is twofold. First, connection count is a real and distinct factor in deliverability, an excessive connection count triggers throttling independent of reputation, and a throttling problem is not always a reputation problem. Second, connection limits must be tuned per receiver, because receivers' connection tolerances genuinely differ, and Microsoft in particular needs conservative connection limits that a single one-size-fits-all setting, generous enough for tolerant receivers, will exceed. Giving Microsoft its own conservative connection limits is a basic part of configuring a Microsoft domain block correctly.
Connection limits are an important and sometimes overlooked part of tuning PowerMTA, alongside the message rate. The max-smtp-out directive controls the number of simultaneous SMTP connections PowerMTA opens to a domain, and a connection rate limit controls how fast new connections are established; both matter, because a receiver can be sensitive to either the count or the rate. The central point is that too many connections is itself a negative signal, beyond the point a receiver is comfortable with, additional connections do not buy throughput, they trigger the receiver's defensive throttling, so connection limits are a politeness setting as much as a throughput lever. Receivers differ in their connection tolerance, with Microsoft notably sensitive and requiring conservative limits, which is why the connection limits are tuned per domain rather than with a single global value. The connection count should be coherent with the message rate, sufficient to support it without being excessive, and the right values are found by observing how each receiver responds in the accounting log. Operators who tune connection limits per receiver, keep them within each receiver's tolerance, and give Microsoft conservative limits, avoid a whole category of self-inflicted throttling; operators who apply one generous connection setting everywhere, as the case shows, find a tolerant-receiver value throttled by a sensitive receiver like Microsoft.