Knowledge base

Two priorities, and which of them wins

queue and recipient priority
One picks the queue, the other the order inside it

There are two levers, and they differ in coarseness.

Queue priority — queue-priority in the receiver block. It decides which queues get connections and delivery attempts first. The scale is numeric, the default in the middle.

Recipient priority is assigned by a pattern rule in <pattern-list> — by recipient address or by sender. It reorders recipients within a queue.

Precedence is stated plainly: where both apply, queue priority decides. Recipient priority cannot let one destination overtake another — only reorder messages within one.

The manual’s example explains the intent better than a definition: password-reset messages ahead of the weekly newsletter. If both go to the same domain, recipient priority works. If to different ones, queue priority.

There is also a third path, not a setting: the set-priority command can reorder messages already sitting in a queue.

The main trap is expecting recipient priority to do what it does not do. A pattern rule looks like a precise tool: the address is named, the number is set. But it cannot overtake another queue — only reorder messages within its own. An urgent message to a busy domain will leave ahead of other messages to the same domain, and no sooner.

The second half is the scale. The manual states it twice and differently: the directive section says 0 to 100, the priorities section — 1 to 100. The difference is one value, and in practice it means: do not use zero if you want predictability.

What the Hub does. It uses neither of the two: queue priorities are not set in receiver rules, and there are no pattern rules with recipient priority either.

We separate urgent from bulk another way — with separate sending addresses: warm-up has its own stream, mailings have theirs, and they compete not by priorities but by limits, each in its own queue.

Example configuration
# two levers: queue priority and recipient priority within it
<domain someplace.com>
    queue-priority 75</domain>

<pattern-list myList>
    rcpt-to /password-reset@customer.com/ recipient-priority=100
    mail-from /newsletter/ recipient-priority=25
</pattern-list>
The first decides which domain is served first. The second reorders messages within a domain — it cannot overtake another domain.
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▶

Expecting recipient priority to overtake another queue

§ 11.9

What it costsIt reorders messages only within its own queue. An urgent message to a busy domain will leave ahead of other messages to the same domain — and not ahead of messages to other domains.
How to spot itRecipient priority is set, yet urgent messages still wait for connections to free up.
How to do it rightFor different domains use queue priority; recipient priority only for the order within one.

Relying on the zero value of the scale

§ 11.9

What it costsThe manual states the range twice and differently: the directive section from zero, the priorities section from one. The behavior of zero cannot be derived from this.
How to spot itA queue with zero priority behaves differently than expected.
How to do it rightDo not use zero: one is just as low and unambiguous.
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.
How to check on the node
Priorities are visible in the configuration, the order in a queue — with the listing command:
grep -n 'queue-priority\|recipient-priority' /etc/pmta/config /etc/pmta/virtualhost.txt
pmta list --priority --maxitems=20
The second command shows the priority of each recipient in the queue. If it is the same for all, recipient priority is not assigned by anything — there are no pattern rules.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Address warm-up