Demo
Demo

Knowledge base

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

backoff-reroute-to-virtual-mta

<domain>set by the Hub

Which address or pool to move messages to while the queue is in backoff
in the configuration this is a linebackoff-reroute-to-virtual-mtainside the block <domain>
Not slow down, but move to another address

All the other directives in the family answer the question “how much slower.” This one answers another: maybe not from here at all. While the queue is in backoff mode, its messages are moved to the specified sending address or pool — and new ones arriving in the queue too, as long as the mode holds.

It is the queue that moves, not the message. The manual describes it like this: messages from example.com/vmta1, when rerouted to vmta2, end up in the example.com/vmta2 queue. The receiver is the same — what changes is the address they go to it from.

The move can be delayed. The optional after= delays the reroute until a message has sat in the queue for the specified time; the minimum is one minute. It is the difference between “move right away” and “move what has been sitting around.”

The engine catches loops itself. The manual warns separately: when a loop is detected, the reroute is silently ignored, and messages stay in the original queue. Rerouting an address to itself is a loop too. When rerouting to a pool, messages go along the paths where there is no loop.

The main trap. A reroute does not cure, it transfers. If the queue went into backoff because of message content or list quality, the second address will get exactly the same refusals — and go into backoff next. This is how the whole fleet gets burned one by one, starting with the address that was healthier than the rest. Moving makes sense when the problem is in the address: reputation, a listing, a mismatched PTR.
What the Hub does. It writes it — but not in the general block, rather on a specific sending address, and only when there is somewhere to move to: the reroute is set only if a backup address is defined for the node. The rule is simple and intentional — the engine should either move the queue to a usable address or not move it at all; a line leading nowhere is worse than no line.

The Hub gives the backup address its own smtp-source-host and, if the address has a reverse record, its own greeting name.

Recommended values

Move to an address, not into a void. The second address must be fully configured: its own source, its own greeting name, its own signing keys. A reroute to a half-configured address replaces one problem with another.

after= is almost always better than without it. An instant reroute also moves messages that would have gone out anyway — the queue could have entered backoff on a single reply. Ten to fifteen minutes filter out the accidental.

A pool instead of an address, if there are several backups: the engine will distribute messages along loop-free paths itself.

Do not set it for everyone in the general block. A reroute makes sense for specific “receiver — address” pairs, not as a general policy: otherwise the first bad day moves all traffic to one address.

The advice about a delayed reroute and the warning about burning the fleet are ours. From the manual here are the syntax, the one-minute minimum, the behavior with new messages, clearing with an empty string and the loop rule.
Example configuration
# we move only what has been sitting around, and only where the address is configured
<virtual-mta vmta1>
    smtp-source-host 1.2.3.4 mail1.example.com
    <domain *>
        backoff-reroute-to-virtual-mta vmta2, after=10m    </domain>
</virtual-mta>
The reroute is set on the sending address, not in the general block: it makes sense to move one specific address’s messages, not all of the node’s traffic. Ten minutes filter out an accidental entry into backoff mode.
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▶

Moving messages when the address is not the problem

our experience

What it costsIf the queue was slowed down because of content or list quality, the backup address will get the same refusals and go into backoff next. This is how the whole fleet gets burned one by one, starting with the healthiest address.
How to spot itA few hours after the reroute, the second address ends up in backoff mode too, then the third.
How to do it rightMove only when the problem is in the address itself. If the refusals are the same for different addresses, the addresses are not the issue, and the reroute should be removed.

Setting a reroute to itself or in a circle

§ 3.3.10.59

What it costsThe engine finds the loop and silently cancels the reroute: messages stay in the original queue. There is no error in the log, the configuration is accepted, and the setting looks like it works.
How to spot itThe queue is in backoff, the reroute is set, and messages do not move.
How to do it rightCheck the whole chain: an address must refer neither to itself nor to one that refers back.

Moving instantly, without after=

our experience

What it costsA queue can enter backoff mode on a single reply from the receiving server and leave a minute later. An instant reroute manages to move all traffic to the backup address — and loads it for no reason.
How to spot itThe backup address gets traffic spikes during the main address’s short spells in backoff.
How to do it rightSet after=10m or more: move what has really been sitting around.
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
backoff-reroute-to-virtual-mta <name>
Values
a sending address or pool name; optionally , after=interval — at least one minute; an empty string clears the inherited value
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
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. An empty string “” clears the inherited value. The manual advises setting the directive precisely on the sending address — in a <domain> block inside <virtual-mta>. It is picked up by pmta reload.
⇄

Related directives

4 relations

Does not work without

Sending addressWhere messages are moved to: the block of another sending address — or a pool. § 3.3.10.59

Conflicts with

invalid-virtual-mta-fallbackGlobalThey compete for the same thing: the node’s fallback address catches messages that named a nonexistent address, while the reroute moves messages of a live queue. Two substitutions in a row make analysis confusing. § 3.3.1.55.2

Same name in other blocks

reroute-to-virtual-mta<domain>The same line with the same syntax and the same loop rules, only it applies while the queue is in backoff mode. § 3.3.10.59

Applies to

Backoff mode — the queue's second personalityThe mode for the duration of which messages leave from another address. § 3.3.10.59

Referenced from

Reputation monitoring inside the nodeThe directive that enables this mechanism. § 11.5.2

How to check on the node
A reroute shows in where the messages sit: the original address’s queue empties, the target’s queue grows for the same receiver.
pmta show queues --mode=backoff --maxitems=20
pmta show queues --maxitems=20 'example.com/*'
The second command shows all queues of one receiver — they show where the messages moved. If the queue is in backoff but the messages have not moved, loop protection most likely fired: the engine cancels the reroute silently, and there will be no error.
◇

What else to read

3 articles

◇Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.

In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
disruptive: applying it interrupts the node
Scenarios
Sending address rotation · Tune the pace for a provider
Neighboring settings of the block <domain>:reroute-to-virtual-mtasmtp-hostsqueue-todisable-mx-rolluprouteAll 135 directives of the block →