Demo
Demo

Knowledge base

PMTA knowledge base›Block <virtual-mta>›Directive§ 3.3.12.2

max-smtp-msg-rate

<virtual-mta>

How many recipients per interval to attempt from this whole address
in the configuration this is a linemax-smtp-msg-rate unlimitedinside the block <virtual-mta>
The same name 1:<virtual-mta><virtual-mta-pool>— some of them are other settings, some are the same one
The only limit that counts the address as a whole

How many recipients the sending address undertakes to serve per interval — in total, across all receivers at once. Both delivered messages and mere attempts count: a temporary refusal from a receiver uses up the limit just like an accepted message.

It counts the address, not the queue — and that is the whole difference. Its close relative max-msg-rate lives in a receiver block and acts on one queue: 500/h with ten receivers means five thousand messages an hour from the address, not five hundred. Here it is the opposite: 500/h means five hundred, no matter how many receivers there are. If you need a ceiling for the address as such, there is no other way to set it.

What triggering looks like. The web monitor writes message rate limit reached (based on max-smtp-msg-rate in configuration) — the text immediately shows which directive held back sending, and there are five similar ones in this family. Messages are neither refused nor lost: the limit stretches sending out over time rather than cutting it off.

The manual advises measuring first. The advice there is direct: take a baseline without the limit and make sure the limit improves deliverability rather than merely slowing down sending. It is not superfluous — a receiver sees only its share of the flow, and a ceiling for the whole address does not always help: it fits when the address is young or when several senders send from one node, and is useless when the bottleneck is not the address but a specific queue.

The main trap. In a pool the limit is not divided among addresses but given to each of them. The manual lists the directives a pool passes down and says of them “inherited by the member addresses”: max-smtp-msg-rate 100/m in a pool of five addresses means a hundred for each, that is, up to five hundred a minute from the pool, not a hundred for all. A value written in the address itself overrides the pool one.
What the Hub does. It does not write it — neither in the address nor in the pool: in the pool it has only the member list. During warm-up the Hub keeps the daily volume itself, with its own scheduler, and gives the engine the queue rate — max-msg-rate 1/h in a <domain> block inside the address. This is deliberate: the warm-up plan can stop on the spam rate and swap in an address from the reserve pool, while the engine limit knows nothing about this and simply slows things down.

If you set it by hand, keep in mind that 1/h in a receiver block and 1/h here are different quantities: the first is multiplied by the number of receivers, the second is not.

Recommended values

Baseline first, then the limit. This is not our saying but a direct recommendation of the manual: as long as it is unknown how much the address sends without a limit, any number will turn out either unreachable or slowing things down for nothing.

How to calculate. Take the daily volume you plan from this address and spread it over the sending window, not over the whole day: three thousand messages from eight in the morning to eight in the evening is 250/h, not 125/h. The number here is not multiplied by anything, so it is easier to calculate than a queue rate.

The denominator accepts a multiplier. N/[M]unit: 100/15m means a hundred messages in fifteen minutes, 83/5s — eighty-three in five seconds. The multiplier appeared in PowerMTA 5; earlier versions only allow 100/m. It is useful when the natural window does not fit a minute or an hour.

About 0. The syntax allows it as a separate value, but what exactly it does the manual does not explain — by the grammar it is a zero rate, that is, sending from the address stops. Try it on a test bench, not on a production address.

The calculation order is our recommendation. From the manual here come the value grammar, the unlimited default, attempts counting the same as deliveries, the monitor message text and the advice to measure a baseline.
Example configuration
# two limits in one block — they are about different things
<virtual-mta mta-news-1>
    smtp-source-host 1.2.3.4 news1.example.com
    max-smtp-msg-rate 3000/h    <domain *>
        max-msg-rate 500/h
    </domain>
</virtual-mta>
The bottom line is per receiver: with ten receivers it will allow five thousand messages an hour. The top line is for the whole address, and it is the one that becomes the actual ceiling: three thousand.
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 ends3 mistakes▶

Setting the address rate the same way as a queue rate

§ 3.3.12.2

What it costsA number taken from a receiver block means something entirely different here: there it was multiplied by the number of receivers, here it is not multiplied by anything. The address gets a limit as many times lower than intended as the number of receivers it works with.
How to spot itSending is noticeably slower than estimated, yet no single queue looks held back.
How to do it rightCalculate from the address’s daily volume and sending window instead of carrying the number over from a receiver block. Verify the result with the command that shows the address’s effective settings.

Setting the limit in a pool and considering it shared

§ 3.3.13

What it costsThe pool hands the value to each member rather than dividing it among them. A pool of five addresses at 100/m lets out up to five hundred messages a minute. Add a sixth address and it becomes six hundred, even though nobody touched the configuration.
How to spot itThe total rate from a group of addresses grows with every addition and is a multiple of the number of members.
How to do it rightDivide the group’s intended rate by the number of addresses and write the result, or set the limit for each address separately. A real limit for the whole node is provided by total-max-smtp-out — but it is about connections, not the rate.

Limiting without taking a baseline

§ 3.3.12.2

What it costsThe manual advises the opposite: first measure sending without a limit. Otherwise the number is pulled out of thin air and usually turns out either higher than the actual rate — then it affects nothing — or lower, and then it slows sending down without improving deliverability at all.
How to spot itAfter the limit was introduced the bounce rate did not change, while the queue started draining more slowly.
How to do it rightMeasure the address’s rate without a limit for at least a day, and only then set a value — below the measured one if receivers complain, and leave it alone if they do not.
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-msg-rate { unlimited | 0 | N/[M]{d|day|h|hr|m|min|s|sec} }
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.12.2
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<virtual-mta>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The pool gives the value to each member as its own; a value in the address itself overrides the pool one. Above the pool there is nothing to inherit from: the directive is not described at the node level, it lives only in <virtual-mta> and <virtual-mta-pool>. It is picked up by pmta reload; a service restart is not needed.
⇄

Related directives

2 relations

Applies to

The sending address — what it is made ofOne of the settings that make up a sending address. § 3.3.12.2Four ways to say “slower”The same rate mechanism, only at the address level rather than the queue level. § 3.3.12.2

Referenced from

max-smtp-data-volume-rate<virtual-mta>The same address ceiling, only in messages. § 3.3.12.2max-smtp-msg-rate<virtual-mta-pool>The directive’s definition: what it does and how it is counted is there. Here is only what writing it at the group level changes. § 3.3.12.2

How to check on the node
The effective value — already merged with the pool — is printed by a separate command. It is also how you check what a pool member has received:
pmta show vmta-settings mta-news-1
pmta show vmtas
The first prints max-smtp-msg-rate for a specific address, the second a summary for all of them: how many recipients and connections each has right now. The triggering itself is visible in the web monitor as the line message rate limit reached (based on max-smtp-msg-rate in configuration). The Hub collects the per-address summary but not the effective limits — those have to be checked on the node.
◇

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
Cost of a mistake
reversible: harms only while it is set
Scenarios
Address warm-up · Tune the pace for a provider
Neighboring settings of the block <virtual-mta>:max-smtp-outmax-smtp-data-volume-ratehost-namedomain-keysmtp-source-hostAll 15 directives of the block →