Demo
Demo

Knowledge base

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

retry-after

<domain>criticalset by the Hub

At what interval to retry delivery
in the configuration this is a lineretry-after 10minside the block <domain>
The retry step while a message waits in the queue

The second alarm clock of the pair. bounce-after sets the deadline, this one the frequency: how long to wait before trying again once the queue has gone into retry mode. It is set as a single interval or as a ladder — a comma-separated list of up to thirty rungs.

Each rung serves one attempt, then the next one takes over; the last one repeats until the bounce. The list 10m,10m,10m,1h,1h,4h means: three attempts ten minutes apart, two an hour apart, then every four hours until the deadline runs out. This way a single line serves both a receiving server that is simply busy and one that is backing off on purpose.

The ladder resets twice. After a successful delivery the count starts again from the first rung — the receiving server has answered, so the earlier caution is no longer needed. And on a node restart: the attempt counter lives in memory, so after a restart all queues knock again at the first, shortest pause.

The main trap. The vendor default 10m is not a ladder but a single rung that repeats until the deadline. With the bounce-after default that is 648 attempts to a receiver that has already asked to wait. The default looks harmless precisely because it is a single number: there is no ladder in it, and it cannot back off.
What the Hub does. The receiver policy template has 30m, the usual length of greylisting, in all fifteen blocks, including the general <domain *>; the backup reroute VirtualMTA has its own step — the backoff return time from the node preset, from half an hour to two hours. The Hub does not build a ladder yet: it will appear once the fleet has gathered statistics on which attempt a receiving server usually starts accepting from.
Recommended values

Half an hour is a sensible starting point. That is how long greylisting usually holds: the receiving server deliberately refuses the first attempt and waits to see whether the sender comes back. Coming back in ten minutes means hitting the same greylisting once more.

Not everyone needs a ladder. It pays off where the receiving server backs off deliberately: large mailbox providers, reputation refusals. For a receiving server that is simply overloaded, an even half-hour step works just as well and is easier to read.

The sum of the rungs must not exceed the deadline. Otherwise the tail of the ladder never runs even once: the message bounces before the far rungs are reached.

Half an hour as a starting point and the rule about the sum of the rungs are ours. From the manual here are the list syntax, the limit of 30 rungs, the 10m default and both resets — on delivery and on restart.
Example configuration
# an even step — the receiving server is simply busy
<domain example.net>
    retry-after 30m</domain>

# a ladder — the receiving server is backing off on purpose
<domain gmail.com>
    retry-after 10m,10m,10m,1h,1h,4h    bounce-after 3d
</domain>
In the second block 4h is the last rung, so from then on retries go every four hours until the three days run out.
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▶

Leaving the default and treating it as a schedule

§ 3.3.10.46

What it costs10m is a single rung, not a ladder. It repeats until the bounce, and the receiving server will see no backing off either on the tenth attempt or on the six-hundredth.
How to spot itThe queue knocks exactly every ten minutes regardless of how many times it has already been refused.
How to do it rightSet at least half an hour, and a ladder for large mailbox providers.

Counting on the long tail of the ladder

§ 11.14

What it costsThe ladder lives in memory and resets on a node restart. On a node that is restarted daily, the rungs beyond the first two or three simply never play out: after every restart the count starts over.
How to spot itThe schedule is laid out for a whole day, but the actual pauses never go beyond the first rung.
How to do it rightKeep the ladder short and do not plan a tail longer than the interval between restarts.

Editing the step and forgetting the neighbors

our experience

What it costsbackoff-retry-after and proxy-retry-after without values of their own take exactly this line. Shortening the step here speeds up retries both in backoff mode and on proxy failures — that is, exactly where there is no need to hurry.
How to spot itAfter the edit, a queue in backoff retries at the same frequency as before.
How to do it rightGive the neighbors values of their own instead of relying on the default.
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
retry-after <time-interval-list>
Values
a time interval or a comma-separated list of intervals, up to 30 rungs; each is a number and the letter d, h, m or s, without spaces
Default
10m § 3.3.10.46
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. Two neighbors take their default from this line — backoff-retry-after and proxy-retry-after; by changing it, you silently change them too. It is picked up by pmta reload, but it does not reset the current position on the ladder — the new schedule takes effect from the next attempt.
⇄

Related directives

1 relation

Depends on

bounce-after<domain>The second alarm clock of the same pair: this one sets the step, that one the deadline. Retries go on until the deadline, after which the message bounces. § 3.3.10.46

Referenced from

proxy-retry-after<domain>The regular retry step, which this line replaces on a proxy failure and which becomes its default. § 3.3.10.47backoff-retry-after<domain>The normal retry schedule that this directive replaces in backoff mode — and that becomes its default. § 3.3.10.48retry-recipients-after<domain>The schedule of the queue as a whole. The effective pause for an address is the larger of the two, not this one. § 3.3.10.49retry-after-dns-error<domain>The usual retry step, which this line replaces when the queue stalls on name resolution. Its default is its own — a minute, not the neighbor’s value. § 3.3.10.50retry-upon-new-mail<domain>The schedule this line bypasses: when enabled, a new message schedules an attempt without waiting for the pause. § 3.3.10.96A retry ladder of your ownThe directive that enables this mechanism. § 11.14

How to check on the node
The queue settings command prints the effective step; the actual pauses show in how often attempts appear for the queue:
pmta show settings gmail.com/vmta1 | grep -iE 'retry-after|bounce-after'
pmta show queues --mode=retry --maxitems=20
The command prints the effective value, but not which rung of the ladder the queue is on right now — PowerMTA does not show that anywhere. The Hub does not track the position on the ladder either.
◇

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
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
Priority
critical
Neighboring settings of the block <domain>:bounce-afterbackoff-to-normal-after-deliverybackoff-retry-afterbackoff-to-normal-afterbackoff-upon-all-sources-disabledAll 135 directives of the block →