Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.81

max-msg-per-connection

<domain>set by the Hub

How many messages go out over one connection before reconnecting
in the configuration this is a linemax-msg-per-connection 50inside the block <domain>
How many messages go out over one connection

After the specified number of messages, the node closes the connection and opens a new one. Zero means “no limit”: the connection lives as long as there is something to send or until connection-idle-timeout fires.

Too few is also bad. Each reconnect means a TCP handshake, a TLS handshake and an SMTP greeting all over again. The provider counts connections too, so max-msg-per-connection 1 at high volume looks more aggressive than a hundred messages over one connection.

The main trap. A low value here turns into a high rate of opening connections and runs into max-connect-rate. Two settings in contradiction produce a queue that stands still without a single refusal: the node simply cannot open the next connection.
What the Hub does. It writes it from the node preset: “Careful” — 20 messages per connection, “Balanced” — 50, “Aggressive” — 100.

For addresses under warm-up the line is not written at all: they have the vendor’s “no limit,” and the pace is held by a single connection and max-msg-rate.

Recommended values
Mode Per address (vMTA) In the provider rule When this is your case
Warm-up, cold address 1 — An address younger than 4–6 weeks or back from a pause
Careful 20 — Strict receivers, questionable reputation, the first weeks after warm-up
Balanced default 50 — Normal operation of an established fleet
Aggressive 100 — Warmed-up addresses, friendly receivers, urgent volumes
PowerMTA default 0 — If the directive is not written at all

The default pays off almost always. The manual says directly: it is usually more efficient to send as many messages as possible over a connection. Limiting is worth it where the receiver itself asks for reconnects — not “just in case.”

Count it together with the connection rate. The number of messages per connection and max-connect-rate are two sides of one thing: the fewer the first, the more often new connections have to be opened. Twenty messages per connection at a thousand messages an hour is fifty connections an hour, and they must fit into the allowed rate.

Zero is not “off” but “no limit.” The connection lives as long as there is something to send or until connection-idle-timeout fires.

Our recommendation; the vendor default is no limit.
Example configuration
# the message limit and the connection rate are chosen together
<domain hotmail.com>
    max-msg-per-connection 50    max-connect-rate 30/m
    connection-idle-timeout 5m
</domain>
Fifty messages per connection at a thousand messages an hour is twenty connections an hour, far below the allowed thirty a minute.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Limiting it without need

§ 3.3.10.81

What it costsThe manual says it usually pays to send as many messages as possible over a connection. A low value forces reconnects, and receivers watch frequent connections more closely than volume.
How to spot itThe number of connections is comparable to the number of messages; responses about too-frequent connections appear.
How to do it rightKeep the default until the receiver asks otherwise. Limit it in response to a specific complaint, not in advance.

Changing it without looking at the connection rate

our experience

What it costsThe number of messages per connection went down — the number of connections went up. If max-connect-rate stayed the same, the queue will hit it and send more slowly than before the edit.
How to spot itThere are consistently as many connections as the connection rate allows, and many messages in the queue.
How to do it rightEdit both settings together and check their product against the actual volume.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
max-msg-per-connection <integer>
Values
an integer number of messages; 0 means “no limit”
Default
0 § 3.3.10.81
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. It is picked up by pmta reload, no restart needed; already open connections live out their time with the old value.
How to check on the node
There is no direct messages-per-connection counter. Indirectly it is visible from the ratio of connections to what was sent over the same period:
pmta show queues --maxitems=20
pmta show settings hotmail.com/vmta1 | grep -i max-msg-per-connection
The second command prints the effective value after blocks are merged — the only reliable way to find out which value won. If there are noticeably more connections than calculated, check whether a more specific block with its own number sits somewhere further down the file.
In the Hub
Managed at
Configurations → Delivery limits
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Tune the pace for a provider