Knowledge base

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

max-msg-rate

<domain>criticalset by the Hub

How fast to hand messages to this receiver
in the configuration this is a linemax-msg-rate 10/minside the block <domain>
Message hand-off rate to the receiver

How many messages per unit of time the node tries to hand to this receiver. It is written as a pair “number slash unit”: 10/m — ten messages a minute, 500/h — five hundred an hour. The limit is counted per queue: receiver plus sending address.

Attempts are counted, not successes. A bounce, a deferral and a delivery use up the limit equally. So 10/m does not mean “ten messages will arrive” but “we will try ten times”; with a third of them bouncing, about seven reach the mailboxes. Reading this number as delivery volume is the most common planning mistake.

What happens if you overdo it. The provider answers with temporary failures, the queue goes into backoff, and backoff-max-msg-rate takes over — usually three times lower. So overdoing it does not just stop growth, it throws the pace back for hours.

The main trap. The limit is per queue, not per receiver. Ten sending addresses sending to Gmail at 10/m give Gmail a hundred messages a minute. Count from the fleet: how many messages a minute you are ready to show the receiver, then divide by the number of addresses.
What the Hub does. The value is taken from the chosen pace and the warm-up stage. A cold address gets 1/h — one message an hour per receiving server, and that is not caution but a warm-up requirement: in the first weeks a provider judges an address by its first few dozen messages.
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 2/m — Strict receivers, questionable reputation, the first weeks after warm-up
Balanced default 10/m — Normal operation of an established fleet
Aggressive 30/m — Warmed-up addresses, friendly receivers, urgent volumes
PowerMTA default unlimited — If the directive is not written at all

Adjusting for fleet size. Multiply by the number of addresses sending to the same receiver. We keep the product within a hundred messages a minute per receiver: ten addresses mean 10/m each, three addresses can go at 30/m.

The unit matters. 60/h and 1/m are different things: the first allows all sixty to go out in the first minute of the hour, the second spreads them evenly. For strict receivers always choose the minute unit.

The values are our recommendation, proven on the fleet. From the manual here is only the “unlimited” in the last row.
Example configuration
# the queue pace and its backoff twin — side by side
<virtual-mta mta-news-1>
    <domain *>
        max-msg-rate 500/h        backoff-max-msg-rate 1/h
    </domain>
</virtual-mta>
The rate form with a multiplied denominator comes from the manual; the block is ours.
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▶

Reading the limit as delivery volume

our experience

What it costsThe limit counts attempts. With a third of messages bouncing, 10/m gives about seven delivered messages a minute, and a mailing plan calculated at face value is not met — while the cause is sought in anything but arithmetic.
How to spot itThe report shows noticeably fewer sent than planned, although the node is not in backoff and the queue is not growing.
How to do it rightPlan from deliveries: take last week’s success rate for this receiver and divide the plan by it.

Setting an hourly unit for a strict receiver

§ 3.3.10

What it costs600/h allows all six hundred messages to go out in the first minute of the hour. The receiver sees a burst rather than a flow and answers with temporary failures — even though it would calmly accept the average hourly pace.
How to spot itBounces cluster at the start of the hour, then the hour goes quiet; the monitor shows a sawtooth chart instead of a flat line.
How to do it rightFor strict receivers set a minute unit: 10/m instead of 600/h. The same number, a different behavior.
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-rate <rate>
Values
unlimited · 0 · N/[M] with a unit d|day|h|hr|m|min|s|sec — for example 500/h or 100/15m
Default
unlimited § 3.3.10.40
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 exact, and across levels — node, pool, sending address — where the narrowest is strongest. The value goes to each queue of this receiving server: with three sending addresses the total flow is three times what is written. It is picked up by pmta reload.
How to check on the node
The effective value — after merging — is printed by the queue settings command:
pmta show settings gmail.com/mta-news-1
The max-msg-rate line in the queue settings section is the effective value. The limit actually kicking in shows in the web monitor as the line message rate limit reached (based on max-msg-rate in configuration).
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