Knowledge base

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

max-connect-rate

<domain>set by the Hub

How fast to open new connections to this recipient domain
in the configuration this is a linemax-connect-rate 30/minside the block <domain>
How fast to open new connections

It limits not the number of simultaneous connections but the rate at which they are opened. max-smtp-out says “how many conversations to hold at once,” this one — “how often to start a new one.” It is written the same way: 30/m means thirty new connections per minute.

Why this is separate from the connection limit. Twenty connections opened over twenty minutes and twenty opened within two seconds are completely different events from the receiver’s point of view. The second looks like scanning, and many receiving servers react to it sooner than to the volume itself.

The main trap. The directive does not save you from dropped connections. If the node closes the connection after every message — for example, because of a low max-msg-per-connection — the opening rate will hit this limit, and the queue will stall while the receiver is alive. These two settings have to be looked at together.
What the Hub does. It writes it from the node preset: “Careful” — ten connections per minute, “Balanced” — thirty, “Aggressive” — a hundred. In the first two the Hub also keeps a pause between connections (smtp-out-rampup-interval) so that even the allowed rate is not used up in a single burst. The line is not written for addresses under warm-up: they have a single connection.
Recommended values
Mode Per address (vMTA) In the provider rule When this is your case
Warm-up, cold address 1/h — An address younger than 4–6 weeks or back from a pause
Careful 10/m — Strict receivers, questionable reputation, the first weeks after warm-up
Balanced default 30/m — Normal operation of an established fleet
Aggressive 100/m — Warmed-up addresses, friendly receivers, urgent volumes
PowerMTA default unlimited — If the directive is not written at all

Count it together with the number of messages per connection. The connection rate and max-msg-per-connection are two sides of the same thing: the fewer messages one connection carries, the more often new ones have to be opened.

Receivers limit the connection frequency separately from the message rate. A refusal over connection frequency looks like a refusal over rate, but it is fixed by a different directive — the response text tells them apart.

The Hub’s presets: ten connections per minute in “Careful,” thirty in “Balanced,” a hundred in “Aggressive.”

Our recommendation; the vendor sets no default limit.
Example configuration
# the connection rate and messages per connection are counted together
<domain *>
    max-connect-rate 30/m    max-msg-per-connection 50
</domain>
Thirty connections a minute at fifty messages per connection is fifteen hundred messages a minute, if the receiver agrees. The bottom line decides how many connections will be needed.
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▶

Lowering the message rate instead of the connection rate

§ 3.3.10.95

What it costsThe receiver limited the connection frequency, not the message flow. Lowering the message rate will stretch out sending, but there will not be fewer connections — they depend on the number of messages per connection.
How to spot itRefusals continue after lowering the message rate; the response text talks about connection frequency.
How to do it rightRead the response text. Limit the quantity the receiver is talking about, not the one closest at hand.

Not accounting for the limit applying to each queue

§ 3.3.10.95

What it costsWith three sending addresses going to one receiver, there will be three times as many connections as written. The receiver sees the sum, not a share.
How to spot itRefusals over connection frequency at a value that, by calculation, is half of what is allowed.
How to do it rightMultiply by the number of sending addresses this receiver is served from.
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-connect-rate <rate>
Values
unlimited · 0 · N/[M] with a unit d|day|h|hr|m|min|s|sec — for example 30/m
Default
unlimited § 3.3.10.90
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
It merges across matching <domain> blocks from general to specific and across the node, pool and sending address levels. Each receiver queue gets the value separately — with several sending addresses there will be that many times more connections. It is picked up by pmta reload.
How to check on the node
The effective value is printed by the queue settings command:
pmta show settings gmail.com/mta-news-1
The max-connect-rate line next to max-msg-per-connection — these are the ones to look at together. When it triggers, the monitor shows a line with this directive’s name in parentheses.
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
Address warm-up · Tune the pace for a provider