Knowledge base

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

smtp-421-means-mx-unavailable

<domain>set by the Hub

Whether to move on to the next MX server after receiving a 421 response
in the configuration this is a linesmtp-421-means-mx-unavailable noinside the block <domain>
What “the server is closing” means — for one message or for all

Code 421 means the receiver’s server is closing the connection: it is overloaded, going into maintenance or does not want to continue. The question is whether this applies to the connection or to the whole server.

The vendor default no treats it as applying to the connection. The node drops it and opens a new one to the same server, continuing to hand out recipients. yes treats it as applying to the whole server: the connection is broken, and the node moves on to the next MX record in the receiver’s list.

The difference shows not in one message but in the queue. With no the queue keeps working with the primary server, even if it really is going away. With yes it moves to a backup at the very first 421.

The main trap. Large receivers’ backup MX servers are weaker than the primary ones, and at small ones they are often spam traps: they are deliberately kept last in the list, and whoever knocks there is watched closely. Enabling it sends the whole queue there at the very first 421 — that is, exactly when caution is needed most.
What the Hub does. In the receiver policy template yes is set for fourteen well-known mailbox providers — their MX list is flat, all servers are equivalent, and 421 really means this host is going away. In the general <domain *> it is no, as the entry below advises; until Sep 15, 2026 it was yes there too.
Recommended values

Large mailbox providers — yes. Their MX records are equivalent, moving to the next one makes nothing worse, and 421 from them honestly means the server is going away.

Unfamiliar domains — no. It is unknown what stands behind the last MX record; landing there on every 421 is not worth it.

Look at the response text. A 421 marked as a rate overrun means “slow down,” not “go to the neighbor” — such a response is better handled with backoff mode through smtp-pattern-list than by switching servers.

The caution about backup MX records and the advice to read the response text are ours. From the manual here come the no default and both behaviors: dropping and reusing the connection versus moving to the next MX record.
Example configuration
# a large mailbox provider: MX records are equivalent
<domain gmail.com>
    smtp-421-means-mx-unavailable true</domain>

# unfamiliar domains: do not go to a backup server on the first 421
<domain *>
    smtp-421-means-mx-unavailable false</domain>
With false the node stays on the same server and keeps handing it recipients — for an unfamiliar receiver that is safer than moving deeper into its MX list.
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▶

Enabling it in the asterisk block

§ 3.3.10.67

What it costsA queue to an unfamiliar domain goes deep into its MX list at the very first 421. The last records in the list are often kept as bait for mailings, and landing there spoils the address’s reputation.
How to spot itIn accounting, delivery to unfamiliar domains goes to addresses that are not among the primary MX records.
How to do it rightKeep no in the general block, enable it only for well-known mailbox providers.

Reacting to a request to slow down by switching servers

our experience

What it costsA 421 with text about an exceeded rate means “slow down.” Moving to a neighboring server of the same receiver does not lower the rate — the same pressure reaches it from another side.
How to spot itAfter the line was enabled, rate refusals did not decrease but spread across all of the receiver’s MX records.
How to do it rightParse the response text through smtp-pattern-list and move such a queue into backoff mode instead of switching servers.
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
smtp-421-means-mx-unavailable <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
no § 3.3.10.67
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. It is picked up by pmta reload; it does not affect open connections — the new behavior starts with the next one.
How to check on the node
The value is printed by the queue settings command; where exactly the messages go is visible from the receiver address in accounting:
pmta show settings gmail.com/vmta1 | grep -i smtp-421
dig +short MX example.com | sort -n
The second command shows the MX list in ascending order of priority: the last records are the ones an enabled line will lead to. The Hub does not yet show which MX servers delivery spreads across.
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