Knowledge base

Merging domains into one queue by hand, by naming it

queue-to
Merging by declaration, not by match

The second way to merge domains into one queue — and the complete opposite of the first in character. Merging by MX derives the group from DNS records: it picks up new domains by itself and stops matching by itself when the provider changes gateways. Here the group is declared: queue-to with the name of the shared queue is written in each domain’s block.

From then on everything “per receiver” is counted by the group: rate, connection ceiling, connection frequency, backoff mode.

The queue name does not have to be a real domain — which means the node does not know where to connect by it. So together with the declaration a smtp-hosts line is mandatory: the manual makes it a requirement, not advice.

The main trap is that warm-up is counted after merging. The daily warm-up quota for a new address is taken from the merged queue, not from individual domains. A schedule written per domain stops working once the group is declared: instead of five quotas by the number of domains there will be one for the whole group.
What the Hub does. It does not use it: the Hub’s configuration is per domain, and it writes no merge declarations. This is the mechanism to turn to where a provider’s grouping is known but its MX records are unstable: a declaration does not stop matching by itself. The price is that the domain list and the delivery hosts have to be maintained by hand.
Example configuration
# a shared queue: the name is made up, so the hosts are set explicitly
<virtual-mta hotmail-queue>
    <domain hotmail.queue>
        max-smtp-out 10
        smtp-hosts lookup-mx:hotmail.com    </domain>
    <domain hotmail.com>
        queue-to "hotmail.queue"    </domain>
    <domain live.com>
        queue-to "hotmail.queue"    </domain>
</virtual-mta>
The lookup-mx:hotmail.com entry means “take another domain’s MX records”: the queue name does not exist in DNS, yet the node has to connect somewhere.
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▶

Declaring a group and forgetting the delivery hosts

§ 11.8

What it costsThe queue name does not exist in DNS, the node does not know where to connect, and messages sit. The manual calls smtp-hosts a requirement for such a queue.
How to spot itThe shared queue is in the list, messages pile up in it, there are no connections.
How to do it rightSet the hosts in the shared queue’s block — as a list or via lookup-mx: with a real domain’s name.

Merging domains whose warm-up schedules are written separately

§ 11.8

What it costsThe warm-up quota is counted by the shared queue. Five domains, each with a quota, give one quota for all after merging — the volume for the new address drops fivefold without a single schedule edit.
How to spot itAfter merging, the daily warm-up volume fell by a factor equal to the number of domains in the group.
How to do it rightRewrite the warm-up schedule for the shared queue’s name, or do not merge domains while an address is warming up.
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
Merging is visible in the queue list: domains disappear from it one by one and appear under the shared name:
pmta show queues | grep -i hotmail.queue
pmta show settings hotmail.com/vmta1 | grep -i queue-to
If the second command’s line is empty while the domain is still visible in the queue list under its own name, the declaration did not take effect. The Hub does not set up merging.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Tune the pace for a provider