Demo
Demo

Knowledge base

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

max-smtp-out

<domain>criticalset by the Hub

How many simultaneous connections the node keeps to one receiver
in the configuration this is a linemax-smtp-out 15inside the block <domain>
The same name 2:<domain><virtual-mta><virtual-mta-pool>— some of them are other settings, some are the same one
Number of simultaneous connections

One connection is one “conversation” with the receiver’s mail server: while the conversation lasts, messages go through it one after another. The directive sets how many such conversations to hold at once. More connections mean more messages a minute, but also a more noticeable load on the receiving side.

Why touch it. Simultaneous connections are what providers watch most closely, far more closely than total volume. Ten messages a minute over one connection is ordinary sending; the same ten messages over twenty streams are a reason to answer with a temporary failure and hold the sender back.

What happens if you overdo it. The receiver starts answering “too many connections” (code 421), the queue goes into backoff, and delivery slows down more than if there had been fewer connections from the start. Undershooting is safer, but the queue builds up and messages arrive late.

The main trap. The limit is counted per queue, not per receiver. Ten addresses sending to Gmail are ten such limits at once: at a value of 20 the receiver sees 200 connections, and nobody will allow that many. Count from the fleet, not from the queue.
What the Hub does. It does not write this line into the common <domain *> block at all: the connection ceiling there is set one level up, on the sending address itself. In a receiver block it appears only in a mailbox provider rule — 2, 5 or 10 connections depending on the chosen pace, always more restrained than the address value, because Yahoo and AOL cut connections harder than the rest. For an address being warmed up all of this equals one, and it is changed not here but by switching the warm-up stage.
Recommended values
Mode Per address (vMTA) In the provider rule When this is your case
Warm-up, cold address 1 1 An address younger than 4–6 weeks or back from a pause
Careful 5 2 Strict receivers, questionable reputation, the first weeks after warm-up
Balanced default 15 5 Normal operation of an established fleet
Aggressive 40 10 Warmed-up addresses, friendly receivers, urgent volumes
PowerMTA default 20 — If the directive is not written at all

Adjusting for fleet size. Multiply the value by the number of addresses sending to the same receiver — that is what it will see. We keep the product within fifty connections per receiver: ten addresses mean five each, three addresses can have fifteen each. The node ceiling is separate (total-max-smtp-out, the Hub sets 5000), and hitting it on an ordinary fleet is hard.

Strict receivers. Yahoo and AOL cut connections harder than the rest, so in a mailbox provider rule the limit is always lower than on the address itself — you can see it in the table.

The values are our recommendation, proven on the fleet, not a vendor norm. From the manual here is only the default of 20.
Example configuration
# common block — the base for all receivers
<domain *>
    max-smtp-out 15
    max-msg-rate 10/m
</domain>

# strict receiver — its own value
<domain yahoo.com>
    max-smtp-out 5</domain>
Messages to yahoo.com get 5, all the others get 15.
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 ends5 mistakes▶

Counting the limit per receiver rather than per queue

§ 3.3.10.84

What it costsEach address opens its own limit to the receiver. Ten addresses at a value of 20 are 200 simultaneous connections to Gmail. The provider starts answering 421, the queue goes into backoff, and the fleet delivers more slowly than one careful address.
How to spot itIn the monitor the queue is in backoff while the node is alive; bounces show “too many concurrent connections” or a 421 with no clear text. Delivery drops in a step, not gradually.
How to do it rightSplit the connection budget across the fleet: first decide how many connections it is acceptable to show the receiver, then divide by the number of addresses that go to it.

Setting a value above the node ceiling

§ 3.3.1.2

What it costsThe instance limit (total-max-smtp-out) kicks in first, and on a Standard license this happens silently: the config says 200, but in fact only as many work as the ceiling allows. The setting looks applied but does not act.
How to spot itThe number of connections hits the same value regardless of what the block says. Check it with pmta show settings — it shows what came out, not what is written.
How to do it rightRaise the node ceiling first, then the queue limit. The Hub sets the ceiling at 5000 — an ordinary fleet has plenty of headroom with that.

Editing the value on an address being warmed up

our experience

What it costsWarm-up keeps a cold address on one connection deliberately: a provider judges a new address most strictly in the first weeks. Raise it to fifteen “to go faster” — and you get complaints and the Spam folder, and warm-up has to start over.
How to spot itA growing bounce rate and falling deliverability precisely on the new address, while the rest of the fleet runs smoothly.
How to do it rightDo not touch it at all: the warm-up block in the config is marked with WARMUP-MANAGED markers and is rewritten by the Hub on every apply — a manual edit inside it will be lost anyway.

Writing the limit into the common block instead of a specific receiver

§ 3.3.10

What it costsA value from <domain *> goes to all receivers at once. Lower it for Yahoo, and you slow down Gmail and corporate domains that would calmly have accepted three times as much.
How to spot itQueues to all receivers grow the same way although there are no bounces: the node simply does not open enough connections.
How to do it rightThe common block is a moderate base, separate blocks are for strict receivers. The most exact match wins, not the order of lines.

Changing the value and expecting a stuck queue to move

§ 3.3.10.84

What it costsRereading the config applies the new value to new connections, but what is already in the queue with a scheduled retry plan goes on as before. Hence the conclusion “the setting does not work” and a second edit right after the first — usually for the worse.
How to spot itAfter applying, the number of connections grows, but the queue does not drain right away — this is normal and means the retry schedule is playing out the old plan.
How to do it rightLet the queue play out, and if it is needed right now, push it forcibly from “Control” rather than turning the limit a second time.
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-smtp-out <integer>
Values
a positive integer, the number of simultaneous connections; the engine default is 20
Default
20 § 3.3.10.84
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
<domain> blocks merge from general to specific: a value from <domain *> is overridden by a value from <domain gmail.com>. The most exact match wins; the order of lines in the file does not matter.
⇄

Related directives

4 relations

Depends on

total-max-smtp-outGlobalThe node ceiling this limit works under; it is itself limited by the license tier. § 3.3.1.2

Same name in other blocks

max-smtp-out<virtual-mta>The same setting at another level. § 3.3.10.84

Works together with

backoff-max-smtp-out<domain>The backoff twin — but with its own default of 20, not this value. § 3.3.10.85source-ip-max-smtp-out<domain>The same ceiling, but broken down by sending address within the queue. § 3.3.10.88

Referenced from

smtp-out-rampup-interval<domain>How many connections the pause is spread across: their number determines how long reaching the full rate takes. inferencemax-smtp-out<virtual-mta-pool>The same limit at the recipient domain queue level; a pool member takes the smaller of the two. § 3.3.10.84

How to check on the node
The node can tell you what value came out after all the blocks were merged — no need to read the config by eye. The sending address name after a slash adds a second section to the output:
pmta show settings gmail.com/mta-news-1
The output splits in two: Virtual MTA Settings — the ceiling for the whole sending address, Queue Settings — the limit of this queue. Both are called max-smtp-out, and one command shows which of them kicks in first. The Hub does not do this step yet: it generates, applies and does not ask the node what came out. § 6.3.16
◇

What else to read

3 articles

◇Four ways to say “slower”Messages, data volume, connection rate and number of connections — each has its own limit, and each has a “per source address” variant and a backoff mode twin.◇A queue is a receiving server together with a sending addressThe engine groups messages by the “recipient domain plus sending address” pair: one domain from two addresses is two independent queues with their own counters, connections and mode.◇Three pool rules the manual states directlyRotation-based distribution, inheritance of settings by members with the member’s own values overriding, and a namespace shared with sending addresses.

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
Priority
critical
Neighboring settings of the block <domain>:max-msg-ratemax-connect-ratesource-ip-max-connect-ratebackoff-max-smtp-outbackoff-max-msg-rateAll 135 directives of the block →