Demo
Demo

Knowledge base

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

backoff-retry-after

<domain>set by the Hub

At what intervals to retry after a refusal
in the configuration this is a linebackoff-retry-after 1h,3h,6h,12hinside the block <domain>
The retry schedule in backoff mode

At what intervals to retry while the queue is in backoff. Set as a single value or as a sequence — 1h,3h,6h,12h means: the first retry after an hour, the second after three, the third after six, then every twelve.

The sequence is cut short by a node restart. The manual says so directly: the attempt counter lives in memory, and after a restart the schedule starts over. On a node that is restarted often, the long tail of the schedule simply never plays out.

The main trap. Retrying too often in backoff defeats the very point of the mode. The receiver answered “come back later,” and the node comes back in five minutes — from the receiving server’s point of view, that is the same pressure under a different name.
What the Hub does. The schedule grows and depends on the node preset: “Balanced” — an hour, three, six, twelve; “Careful” — twice as long, from two hours to a day; “Aggressive” — half an hour, an hour, three, six. The last interval repeats until the message’s lifetime runs out (bounce-after). The line is not written for addresses under warm-up.
Recommended values
Mode Per address (vMTA) In the provider rule When this is your case
Warm-up, cold address 2h,6h,12h,24h — An address younger than 4–6 weeks or back from a pause
Careful 2h,6h,12h,24h — Strict receivers, questionable reputation, the first weeks after warm-up
Balanced default 1h,3h,6h,12h — Normal operation of an established fleet
Aggressive 30m,1h,3h,6h — Warmed-up addresses, friendly receivers, urgent volumes
PowerMTA default the value of retry-after — If the directive is not written at all

As a ladder, not a single number. A list of intervals sets growing pauses: the first retry after an hour, the second after three, then less often. The receiving server sees that the sender is backing off — and that is exactly what is expected of backoff mode.

Count it together with the bounce deadline. The sum of the intervals should not noticeably exceed bounce-after: there is no point shuffling messages through the queue for days if they will bounce anyway.

The default takes retry-after — usually 10m. That is too frequent for backoff mode: the queue will hammer the receiving server every ten minutes, no different from normal mode.

The ladder and the rule to check against the bounce deadline are ours. From the manual here are the interval list syntax and the default “equal to retry-after.”
Example configuration
# in backoff mode we back off with a growing step
<domain hotmail.com>
    retry-after 10m
    backoff-retry-after 1h,3h,6h,12h</domain>
Without the second line, backoff mode would use the same ten minutes as normal mode — the default takes retry-after.
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▶

Leaving the default

§ 3.3.10.48

What it costsThe default takes retry-after, and that is usually 10m. A queue in backoff mode retries every ten minutes — that is, it behaves exactly as it did before the switch, and the receiving server sees no backing off at all.
How to spot itThe queue is in backoff, yet attempts come at the same frequency as before.
How to do it rightSet a growing ladder: an hour, three, six, twelve.

Stretching the schedule beyond the bounce deadline

our experience

What it costsIf the sum of the intervals is noticeably greater than bounce-after, the last rungs of the ladder never run: the message bounces earlier. The setting looks well thought out, but only the beginning of the list works.
How to spot itBounces arrive at a moment that matches none of the schedule’s rungs.
How to do it rightCompare the sum of the intervals with the bounce deadline and stay within it.
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-retry-after <time-interval-list>
Values
an interval or a comma-separated list of intervals — for example 1h,3h,6h,12h
Default
the value of retry-after § 3.3.10.48
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. The default depends on a neighboring line: without its own value, retry-after is used. It is picked up by pmta reload; for messages already deferred, the new schedule takes effect from the next attempt.
⇄

Related directives

3 relations

Depends on

bounce-after<domain>The upper bound: the message bounces even if the retry schedule has not run out yet. § 3.3.10.48

Same name in other blocks

retry-after<domain>The normal retry schedule that this directive replaces in backoff mode — and that becomes its default. § 3.3.10.48

Applies to

Backoff mode — the queue's second personalityThe mode in which this schedule applies instead of the normal one. § 3.3.10.48

How to check on the node
The queue settings command prints the effective schedule; the actual pauses show in how rarely connections appear for the queue:
pmta show settings hotmail.com/vmta1 | grep -i backoff-retry-after
pmta show queues --mode=backoff --maxitems=20
A match with retry-after means the line was not set. The Hub sets the schedule itself — 1h,3h,6h,12h by default.
◇

What else to read

3 articles

◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.◇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.◇Reputation monitoring inside the nodeThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.

In the Hub
Managed at
Configurations → Bounce behavior
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Tune the pace for a provider
Neighboring settings of the block <domain>:retry-afterbounce-afterbackoff-upon-all-sources-disabledbackoff-to-normal-afterbackoff-to-normal-after-deliveryAll 135 directives of the block →