Contents
Bounce processing is not an operational afterthought — it is a core deliverability function. Invalid addresses that are not suppressed generate repeated hard bounces, which ISPs use as a negative reputation signal. Unprocessed bounce data means list quality degrades silently, complaint rates rise as non-existent addresses are recycled as spam traps, and sender reputation deteriorates before operators identify the cause. PowerMTA's bounce classification system provides the data needed to maintain a clean sending list — but only if correctly configured and integrated into the suppression workflow.
Bounce Types and Classification
PowerMTA classifies bounced messages based on the SMTP response code and diagnostic text from the receiving MTA. Each classification maps to a recommended suppression or retry action. Understanding this taxonomy is essential for building an effective bounce management workflow.
| Bounce Type | SMTP Codes | Meaning | Action |
|---|---|---|---|
| bad-mailbox | 5.1.1, 5.1.2 | Invalid or non-existent recipient address | Suppress immediately — permanent failure |
| bad-domain | 5.1.2 | Recipient domain doesn't exist or has no MX | Suppress domain — permanent failure |
| quota | 4.2.2, 5.2.2 | Recipient mailbox full | Retry for 2-3 days, then suppress |
| spam | 5.7.1 | Content or sender IP filtered as spam | Review content; check IP reputation |
| policy | 5.7.x | Policy rejection (DMARC, authentication, etc.) | Fix authentication; do not retry until resolved |
| administrative | 5.7.5xx | Administrative block (IP ban, domain block) | Address underlying issue; do not retry blindly |
| timeout | Connection timeout | Destination unreachable / network issue | Retry with longer retry-after interval |
Bounce Processing Configuration
# Global bounce configuration in /etc/pmta/config # Envelope sender for bounces (Return-Path) bounce-address bounces@mail.yourdomain.com # Default automatic bounce handling by type default-bounce-handling bad-mailbox=block default-bounce-handling bad-domain=block default-bounce-handling quota=retry default-bounce-handling spam=unsubscribe default-bounce-handling administrative=block default-bounce-handling timeout=retry # Per-domain override (e.g., faster suppression at Gmail)bounce-handling bad-mailbox=block bounce-handling quota=block # Gmail quota bounces usually mean dead account expire-after 2d # Transactional — expire fasterexpire-after 5d # Global: 5 days before bounce
Bounce Address Setup and VERP
The bounce address (Return-Path) must be at a domain you control so that DSN messages return to a mailbox or pipe you can process. VERP (Variable Envelope Return Path) encodes the original recipient in the bounce address, making it possible to identify which recipient bounced even if the DSN body is malformed.
# Standard bounce address bounce-address bounces@mail.yourdomain.com # VERP — encode recipient in bounce address # Enables recipient identification from bounce Return-Path header alone # PowerMTA VERP configuration: <virtual MTA pool configuration-ip-1> smtp-source-host 185.x.x.10 mail1.yourdomain.com # VERP not natively built into PowerMTA — implement at injection layer # Your application sets Return-Path per message: # Return-Path: bounces+recipient=domain.com@mail.yourdomain.com # DNS MX record for bounce processing domain # bounces.yourdomain.com MX 10 bounce-processor.yourdomain.com # Bounce processor parses incoming DSNs and adds recipients to suppression list
Automatic Bounce Handling Directives
# Bounce handling values: # block — immediately suppress; no further delivery attempts # retry — retry delivery per retry-after schedule # unsubscribe — mark as unsubscribed; no further marketing sends # ignore — log but take no automatic action (use with care) # Production-recommended global defaults: default-bounce-handling bad-mailbox=block default-bounce-handling bad-domain=block default-bounce-handling quota=retry default-bounce-handling spam=block default-bounce-handling policy=block default-bounce-handling administrative=block default-bounce-handling timeout=retry # Results are logged in accounting log format with otype=b (bounce) # dsnStatus field contains the SMTP response code # dsnDiag field contains the diagnostic text from the receiving MTA
Bounce Data in Accounting Logs
# Accounting log fields for bounce analysis:
# otype — record type: 'b' for bounce
# dsnStatus — SMTP status code (e.g., 5.1.1)
# dsnDiag — diagnostic text from remote MTA
# rcpt — recipient address that bounced
# vmta — virtual MTA that sent the message
# Query bounce rate by domain:
awk -F, '$1=="b" {split($10,a,"@"); domain[a[2]]++; total++} END {
for(d in domain) printf "%s: %.2f%%\n", d, domain[d]/total*100
}' /var/log/pmta/accounting-YYYYMMDD.csv | sort -t: -k2 -rn | head -20
# High bounce rate (>2%) at a specific ISP = list quality problem at that ISP
# Investigate source of invalid addresses for that domain segment
DSN Processing and Suppression Integration
# PowerMTA can pipe bounce notifications to an external script:path /usr/local/bin/process_bounces.py format pipe records bounced # process_bounces.py should: # 1. Parse recipient address from 'rcpt' field # 2. Parse bounce type from 'dsnStatus' field # 3. For hard bounces (5xx): add to suppression list immediately # 4. For soft bounces (4xx quota): track count; suppress after N retries # 5. Update your CRM or email platform suppression list # 6. Log event with timestamp, recipient, campaign ID, and bounce code
Custom Bounce Pattern Classification
# PowerMTA includes built-in bounce pattern classification
# Custom patterns extend this for ISP-specific diagnostic messages
smtp-pattern-list custom-bounce-patterns {
# ISP-specific patterns that map to bounce types
"mailbox unavailable" bounce type=bad-mailbox
"does not exist" bounce type=bad-mailbox
"user unknown" bounce type=bad-mailbox
"invalid address" bounce type=bad-mailbox
"spam message rejected" bounce type=spam
"blocked" bounce type=administrative
"quota exceeded" bounce type=quota
"greylisted" retry-after=30m # Greylisting — retry
}
smtp-pattern-list custom-bounce-patterns
Frequently Asked Questions
Operating PowerMTA at production volume?
We manage PowerMTA environments for high-volume senders — configuration, IP warming schedule, daily reputation monitoring, and operational response. Fully managed. No self-service.
