Home
Features
Modules
Integrations
PowerMTA Docs
MailerQ Docs
Pricing
Blog
D
e
m
o
Home
Features
Modules
Integrations
PowerMTA Docs
MailerQ Docs
Pricing
Blog
D
e
m
o
Home
Features
Modules
Integrations
PowerMTA Docs
MailerQ Docs
Pricing
Blog
Home
Knowledge base
Knowledge base
PMTA knowledge base
›
Scenario
Bounce classification
entries in this scenario: 58
bounce-after
<domain>
critical
set by the Hub
Directive
Until this point the message lives in the queue and takes up disk space.
records
<acct-file>
critical
set by the Hub
Directive
A list of eight possible accounting record types; the default is deliveries and local bounces.
bounce-upon-5xx-greeting
<domain>
set by the Hub
Directive
The vendor default is yes, and one misconfigured server in the MX list is enough to burn the queue.
bounce-upon-no-mx
<domain>
set by the Hub
Directive
It accepts more than yes and no: an interval gives the domain time during which the node can try the address directly.
enable-tq-record-for-proxy-failure
<domain>
Directive
Records proxy connection failures in tq accounting records; off by default and ignored without this record type.
html-edit-error-mode
<signals>
Directive
Refuse delivery or send as is when HTML parsing failed; the default is to refuse.
mail-from
<rewrite-list>
set by the Hub
Directive
Changes the address from the SMTP MAIL FROM command — the one a bounce returns to and the one SPF checks; this rule does not touch the From header.
reject-spf-check-fail
<source>
Directive
The most unambiguous of the three outcomes: the domain owner said that mail must not be sent from this address.
reject-spf-check-permerror
<source>
Directive
The sender forbade nothing — it made a syntax mistake; the default rejects anyway.
reject-spf-check-temperror
<source>
Directive
The only one of the three outcomes where the refusal is temporary: the sender is invited to retry.
suppression-lists
<source>
Directive
Attaches one or more named address lists; a recipient on a list is rejected at submission or bounced later, depending on how invalid recipients are accepted.
verp-default
<source>
Directive
Enabling on the submission side: it applies to everything submitted through this source.
assume-delivery-upon-data-termination-timeout
<domain>
set by the Hub
Directive
A bet that the message got through: there will be no duplicates, but no truth in accounting either.
body-pattern-file
<email-patterns>
Directive
A regular expression with named groups that pulls accounting fields out of the body of a non-standard report; the line is repeatable.
bounce-upon-transfer-failure
<domain>
Directive
A choice between the risk of a duplicate at the recipient and the risk of not delivering the message at all.
disable-mx-rollup
<domain>
Directive
Turns off both kinds of combining for the domain at once — both the manual list and the automatic one.
pattern-list
<source>
set by the Hub
Directive
Attaches a named rule list to the source; the list must be declared earlier in the file, and only one can be attached.
retry-upon-new-mail
<domain>
Directive
Bypasses the retry schedule: every new message in the queue schedules an attempt immediately.
verp-default
<domain>
Directive
The same enabling, but targeted: only for messages to this domain.
bounce-upon-pix-transfer-failure
<domain>
Directive
A narrow case of the general line: it fires if the receiver’s greeting contains at least ten asterisks.
log-match-info
<email-patterns>
Directive
Writes to the log the name of the pattern file that matched the parsed report; off by default.
pix-bug-workaround
<domain>
Directive
On by default: a workaround for a known fault that causes messages to be duplicated.
track-jobs
<domain>
Directive
Enables counting jobs per receiver and showing them on its page in the web monitor; off by default.
The bounce category in accounting — configurable, not vendor-fixed
critical
Mechanism
The bounceCat string in every accounting record comes from a pattern list that can be extended with your own rules and your own category names.
Parsing bounces that arrive as messages
critical
Mechanism
Bounce reports that arrive as messages are parsed by a separate processor — and it runs before the complaint processor.
Two inbound report processors and what to do with them
Mechanism
Bounces 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.
What to do with an accepted message
Mechanism
What the node does with an accepted inbound message: forwards it, writes it to a file, discards it, passes it to a program or parses it as a bounce or complaint.
The complaint format of one large receiver
Mechanism
Hotmail complaints do not come in standard ARF: for the engine to recognize them and record the recipient, you need the variant with an RFC attachment and the
X-HmXmrOriginalRecipient
header.
The regular expression dialect
Mechanism
Configuration regular expressions are Perl-compatible, based on the PCRE library: that is how sending address selection, reply rules, bounce categories, address lists and signing headers are written.
The second complaint report format
Mechanism
XARF complaints are JSON instead of ARF: the engine fills the main fields itself, and the rest are extracted with the
xarf.<path>
form.
Reports the engine does not understand by itself
Mechanism
Receivers that send bounces and complaints in a non-standard form are parsed with custom patterns; the extracted fields go into accounting on a par with the usual ones.
Which outcomes produce a report — each recipient decides
Mechanism
For each recipient separately a report on success, failure, delay, any combination of them or nothing is requested; the default is failure only.
What to return in a bounce report
Mechanism
What to enclose in a bounce report: the whole message or only its headers.
A return address with the recipient written into it
Mechanism
The bounce arrives at a unique address, and there is no need to parse its content.
National alphabets
Mechanism
Configuration files are UTF-8, so internationalized domains and addresses are written as is; a message with an internationalized address in the envelope goes out only if the receiver supports SMTPUTF8.
Removing a sending address — and what happens to its queue
critical
Procedure
The definition is removed with an edit and a reload; messages still tied to the removed address bounce with their own code.
<smtp-pattern-list>
Configuration block
Patterns matched against receiver responses — the very trigger that backoff mode reacts to.
Permanently bounced
critical
Accounting record
The recipient permanently did not receive the message — either the receiving server refused for good, or the node itself bounced the message when the deadline expired.
Parsed bounce from outside
Accounting record
A bounce report email arrived at the configured processor and was parsed.
The name lookup did not complete — and no conclusion is drawn
Error code
The name service query failed, usually on timeout; the engine deliberately does not bounce the message on such a failure.
The receiver is misconfigured
Error code
The bounce is caused by the remote side’s configuration, not ours.
Connection problem
Error code
The connection to the receiver failed or was broken.
The domain does not exist
Error code
The recipient’s domain was not found or does not exist. The bounce is about the right-hand part of the address, not the left.
The address does not exist
Error code
The receiver said it has no such recipient. The most unambiguous of bounces: it is about the address, not about the message, not about us and not about the network.
Held back over content
Error code
Rejected because of what is inside the message: a link, an attachment, markup.
The mailbox is disabled or expired
Error code
The mailbox once existed, but it was closed, frozen or expired. Formally the address exists, practically it is dead.
A problem with the sender domain
Error code
The bounce is caused by our domain’s records: they are missing or wrong.
The bounce deadline has expired
Error code
The message was not delivered within the allotted time and was bounced on deadline.
The host connected and stays silent
Error code
The connection was established, no reply followed.
Other
Error code
A bounce that did not fit any category.
Rejected by the receiver's rules
Error code
The receiver refused by its own rules — not over content and not over the address.
A breach of the conversation order
Error code
A syntax error or a wrong command sequence.
The mailbox is full
Error code
The recipient has run out of space. The mailbox is alive, there is just nowhere to put the message.
The receiver refused to relay
Error code
The remote server refused to accept the message for further relaying.
A route could not be built
Error code
Mail to the recipient’s domain cannot be routed.
Held back as spam
Error code
The message was rejected on spam signals. The bounce is not about the address — it is about us and about the content.
A virus was found
Error code
The receiver considered an attachment or a link malicious.
Bounces according to the service
Monitor screen
The SparkPost Signals report on bounces for a selected period — in SparkPost’s classification, not in the engine’s categories.