Demo
Demo

Knowledge base

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

bounce-upon-no-mx

<domain>set by the Hub

Whether to bounce right away when the receiver has no MX record
in the configuration this is a linebounce-upon-no-mx falseinside the block <domain>
What to do with a domain that has no mail server in DNS

The recipient’s domain exists, but it has no MX record. Formally mail to such a domain is still possible: mail standards allow contacting the domain’s own address in this case — the A or AAAA records. This line decides whether it is worth trying.

There are four values, not two. false is the vendor default: messages stay in the queue and go out on the general deadline. true — this receiver’s entire queue bounces immediately. An interval is the most useful kind: only messages that have sat in the queue longer than the specified time bounce, and until then the node tries to reach the domain’s address. never — never bounce for this reason.

The line works only where the node asks for MX at all. If the receiver has an explicit list of servers set via smtp-hosts, no MX query happens, and there is nothing to decide here.

The main trap. true in the asterisk block is a quick way to lose live mail. Small domains, corporate mail nodes and hastily set up addresses often live on a single A record with no MX at all. For large mailbox providers true is safe: gmail.com always has MX, and its absence means a failure, not such a configuration.
What the Hub does. In the receiver policy template yes is set for fourteen well-known mailbox providers, and in the general <domain *> it is 30m, as in the manual’s example: a domain without an MX record gets attempts on its address record for half an hour and only then a bounce. Until Sep 15, 2026 the general block also had yes, and such a domain got a bounce right away.
Recommended values

Well-known mailbox providers — yes. A large provider always has MX; its disappearance means a DNS failure, not a domain without a mail server. There is no point keeping messages in the queue for three days for such a case.

Everyone else — an interval. Half an hour gives the node time to try the domain’s address directly without dragging obviously dead mail along for the whole deadline. This is also the value the manual’s example shows for the asterisk block.

true on the asterisk — only if you know your base for sure. For a campaign to collected addresses this is a guaranteed loss of some live recipients.

The split “yes for well-known mailbox providers, an interval for everyone else” is ours. From the manual here are all four allowed values, the false default, the example with 30m and the caveat about smtp-hosts.
Example configuration
# a large mailbox provider always has MX — its absence is a failure
<domain gmail.com>
    bounce-upon-no-mx yes</domain>

# everyone else gets half an hour to try the domain's address
<domain *>
    bounce-upon-no-mx 30m</domain>
The second block does not cancel the first: the value merges from general to specific, and for gmail.com it is yes that applies.
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▶

Setting true in the asterisk block

§ 3.3.10.69

What it costsDomains living on a single A record without MX are lost entirely. Mail standards allow such delivery, but a node with this setting does not even try.
How to spot itThe bounces include many small domains marked as having no MX, even though mail used to go to them.
How to do it rightIn the asterisk block set an interval — 30m, for example — and keep true for the blocks of well-known mailbox providers.

Setting it for a receiver with an explicit server list

§ 3.3.10.69

What it costsWith smtp-hosts set, no MX query happens, and the line does nothing. The setting is assumed to be in effect, and the cause of bounces is sought in the wrong place.
How to spot itThe line is set, yet messages behave as if it were not there.
How to do it rightRemove it from blocks with an explicit server list so as not to mislead anyone reading the configuration.
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
bounce-upon-no-mx ( <boolean> | <time-interval> | never )
Values
true, false, a time interval like 30m or the word never
Default
false § 3.3.10.69
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 line has no effect where smtp-hosts is set: an explicit server list cancels the MX query, and with it the reason for this decision. It is picked up by pmta reload; for messages already queued the new value takes effect from the next attempt.
⇄

Related directives

1 relation

Conflicts with

smtp-hosts<domain>An explicit server list cancels the MX query — and without the query this line does not fire at all. § 3.3.10.69

Referenced from

bounce-after<domain>A condition that bounces the message early, without waiting for the deadline. § 3.3.10.69

How to check on the node
The queue settings command prints the value; whether the record itself exists is checked with a regular DNS query:
pmta show settings example.com/vmta1 | grep -i bounce-upon-no-mx
dig +short MX example.com
An empty answer from the second command with yes means this receiver’s entire queue will bounce on the next attempt. The Hub does not track missing MX records for receivers.
◇

What else to read

3 articles

◇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.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇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.

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
Bounce classification · Tune the pace for a provider
Neighboring settings of the block <domain>:smtp-pattern-listsmtp-553-means-invalid-mailboxbounce-category-patternsbounce-upon-5xx-greetingbounce-upon-transfer-failureAll 135 directives of the block →