Postfix bounce rate spike: 5xx failures, bad address lists, and reputation risk

A bounce rate spike is easy to miss. Postfix records a bounce as a completed transaction, so naive delivery metrics stay green while mail permanently fails. The status=bounced entries pile up in the logs, sender reputation degrades with every message, and sustained high bounce rates trigger blocklist listings at major destinations.

This guide covers how to identify a bounce rate spike, classify the 5xx failure codes driving it, and stop the bleeding before reputation damage compounds.

What this means

A status=bounced log entry means Postfix received a permanent failure (5xx SMTP response) from the destination and will not retry. The bounce(8) daemon generates a delivery status notification (DSN) to the original sender, and the message is removed from the queue permanently.

This is different from status=deferred, where the destination returned a 4xx temporary failure and Postfix schedules a retry with exponential backoff. A bounce rate spike means mail is permanently lost, not delayed. If you are seeing deferred messages pile up instead, that is a different problem: see Postfix deferred queue growing: why mail piles up and how to drain it.

Common bounce rate thresholds:

Common causes

Quick checks

Run these read-only commands to size the problem and start classification. The log file path differs by distribution: Debian and Ubuntu use /var/log/mail.log, while RHEL and CentOS use /var/log/maillog.

# Bounce count in the current hour (quick proxy for recent activity)
# For precise 5-minute windows on systemd hosts:
#   journalctl --since "5 min ago" --no-pager | grep -c 'status=bounced'
grep "$(date '+%b %e %H:')" /var/log/mail.log | grep -c 'status=bounced'

# Top bounce reasons (extract the reason text after status=bounced)
grep 'status=bounced' /var/log/mail.log | sed 's/.*status=bounced //' | sort | uniq -c | sort -rn | head -10

# Top destination hosts returning bounces
grep 'status=bounced' /var/log/mail.log | grep -oE 'host [^[]+' | sort | uniq -c | sort -rn

# Top sender addresses being bounced (check for forged or invalid senders)
grep 'status=bounced' /var/log/mail.log | grep -o 'from=<[^>]*>' | sort | uniq -c | sort -rn | head -20

# Check if MAILER-DAEMON or double-bounce messages dominate the queue
postqueue -p | grep -c 'MAILER-DAEMON'

# Check relevant bounce configuration
postconf soft_bounce notify_classes bounce_queue_lifetime maximal_queue_lifetime

# Test recipient validation map (if relay_recipient_maps configured)
postmap -q test@example.com hash:/etc/postfix/relay_recipients

The last command returns the lookup result for a test address. An empty result with no error means the address was not found in the map. If your relay or gateway accepts all recipients and bounces later, you have a backscatter risk.

How to diagnose it

Step 1: Confirm the bounce rate and establish a baseline

Count status=bounced entries over a recent window and compare against your injection rate. A useful ratio is bounces divided by total accepted messages in the same period. If you do not have a baseline, compare against the thresholds above: above 1% sustained warrants investigation.

Step 2: Extract and classify the 5xx codes

The enhanced status code in each bounce line tells you the rejection category. The most common patterns:

• 5.1.1: “User unknown” or “mailbox does not exist.” Points at a bad recipient list or missing recipient validation on your relay.
• 5.1.2: “Bad destination” or “domain not found.” Usually a DNS or routing problem.
• 5.7.1: “Delivery not authorized, message refused.” The broadest category: reputation blocks, content policy rejections, rate limiting, or authentication failures at the destination.
• 5.4.0: “Other or undefined network or routing problem.” Check transport maps and relayhost configuration.

flowchart TD
    A["status=bounced spike"] --> B["Extract top 5xx reasons from logs"]
    B --> C{"User unknown codes?"}
    C -->|Yes| D["Bad address list or missing recipient validation"]
    C -->|No| E{"Policy rejection codes?"}
    E -->|Yes| F["Reputation block or content rejection"]
    E -->|No| G["Routing or MX misconfiguration"]
    D --> H["Halt list upload, validate recipients"]
    F --> I["Check blocklists, throttle outbound"]
    G --> J["Verify DNS MX and transport_maps"]

Step 3: Group bounces by destination domain

Use the “top destination hosts” command from the quick checks. If bounces concentrate on one or two major destinations (Gmail, Outlook, Yahoo), the problem is likely reputation or rate-limiting at that destination. If bounces spread across many domains with the same 5.1.1 code, the problem is your recipient data.

Step 4: Check for backscatter signatures

If the from= addresses in your bounce log entries look forged (random strings, nonexistent local addresses, or the same domain as the recipient), you may be generating backscatter. This happens when Postfix accepts mail for invalid recipients and then bounces it to a forged sender. Check whether MAILER-DAEMON messages dominate your queue:

# Queue composition by sender
postqueue -p | awk '/^[A-F0-9]/{print $7}' | sort | uniq -c | sort -rn | head

A high count of MAILER-DAEMON entries in the queue means bounce messages themselves are piling up because the original senders are invalid.

Step 5: Verify recipient validation is working

If your Postfix instance is a relay or gateway, it should reject invalid recipients at SMTP time using relay_recipient_maps rather than accepting everything and bouncing later. Test the map:

# Should return a value for valid recipients, nothing for invalid
postmap -q knownuser@example.com hash:/etc/postfix/relay_recipients
postmap -q nonexistent@example.com hash:/etc/postfix/relay_recipients

If both return the same result (or both return nothing), your recipient validation is not working and you are accepting mail for invalid addresses.

Step 6: Check external reputation signals

If 5.7.1 rejections from major destinations dominate, check your IP or sending domain against public blocklists. Look up your sending IP at Spamhaus and Barracuda. Also check your sender score and complaint rates if you have feedback loops set up with major ISPs.

Metrics and signals to monitor

Fixes

Bad recipient list

If 5.1.1 “User unknown” dominates and the spike coincides with a list upload or campaign:

1. Halt the source. Stop the application or cron job pushing the bad list. Every additional message to invalid addresses worsens your bounce rate and reputation.
2. Validate recipients before injection. If you operate a relay or gateway, configure relay_recipient_maps to reject invalid recipients at SMTP time. This prevents Postfix from accepting and then bouncing mail to nonexistent addresses.
3. Remove queued bounces to that list. Identify and delete the affected messages from the queue using postsuper -d with a matching pattern. Verify the pattern carefully before deleting: this is a destructive operation.

# DANGEROUS: deletes messages matching a pattern. Verify matches first.
# Find matching queue IDs first, review, then delete.
postqueue -p | grep 'problematic-list@example.com' | awk '{print $1}' | sed 's/[*!]$//' | postsuper -d -

IP reputation block

If 5.7.1 policy rejections from major destinations dominate:

1. Check blocklists. Look up your sending IP at public DNSBL query services. If listed, follow the delisting process for that specific list.
2. Throttle outbound delivery. Reduce destination concurrency to avoid overwhelming the receiving server and generating more rejections. See Postfix destination concurrency limit: tuning per-destination delivery.
3. Review authentication alignment. Ensure SPF, DKIM, and DMARC are correctly configured for your sending domain. Misaligned DKIM signatures cause 5.7.1 rejections at strict destinations.
4. Consider warming up a new IP if the current one is severely listed. This is a multi-week process, not a quick fix.

MX or routing misconfiguration

If bounces concentrate on one domain with 5.1.2 or 5.4.0 errors:

1. Verify DNS MX records for the affected domain. Use dig MX example.com from the Postfix host to confirm the MX points to a live mail server.
2. Check transport_maps for stale or incorrect entries that route mail to the wrong host.
3. Test connectivity to the destination MX on port 25. A connection refused or timeout may indicate a network-level block rather than a DNS problem. See Postfix connection refused: blocked port 25 and rejected outbound delivery.

Backscatter or bounce storm

If bounces go to forged sender addresses and MAILER-DAEMON dominates the queue:

1. Tighten recipient restrictions. Configure relay_recipient_maps or enable recipient verification so Postfix rejects invalid recipients at SMTP time instead of accepting and bouncing.
2. Clear the bounce queue carefully. Remove MAILER-DAEMON and double-bounce messages from the queue. Double-bounces (bounces of bounces) are normally discarded by Postfix, but if they accumulate, manual cleanup is needed. See Postfix flushing and clearing the deferred queue: postqueue and postsuper.
3. Check for configuration errors that generate backscatter. A backup MX accepting mail for unknown recipients, a wildcard alias forwarding to nonexistent addresses, or a vacation auto-responder on a distribution list can all generate backscatter.

Emergency: stop the bleeding

If bounce rate exceeds 10% of injection, consider halting outbound mail entirely while you diagnose. You can hold all queued mail:

# Hold all mail in the queue (reversible with postsuper -H ALL)
postsuper -h ALL

This stops delivery attempts without losing messages. Once you identify and fix the cause, release the queue with postsuper -H ALL.

Prevention

• Monitor bounce rate explicitly. Bounces count as “successful” in naive delivery metrics. Parse status=bounced from logs and alert on the ratio against injection rate. Do not rely on delivery success rate alone.
• Add bounce to notify_classes. The default notify_classes value is resource, software and does not include bounce notifications. Add bounce and 2bounce so the postmaster receives DSN notifications for bounce activity. Caution: on high-volume servers, bounce notify generates a postmaster copy for every bounce, which can flood the postmaster mailbox during a spike.
• Validate recipients at SMTP time. Use relay_recipient_maps on relay or gateway deployments. Accepting mail for invalid recipients and bouncing later is the primary cause of backscatter.
• Keep soft_bounce disabled in production. The default soft_bounce = no is correct for production. Setting soft_bounce = yes converts 5xx to 4xx and masks permanent failures as temporary deferrals, causing queue buildup while hiding the real problem.
• Set up feedback loops with major ISPs. Complaint feedback from Gmail, Outlook, and Yahoo provides early warning before bounce rates spike. A rising complaint rate often precedes a reputation-driven bounce spike.
• Run regular list hygiene. Remove addresses that have bounced with permanent 5xx codes. Track the bounce reason per address so you can distinguish “user moved” from “domain does not exist.”
• Audit bounce_queue_lifetime versus maximal_queue_lifetime. Both default to 5d. bounce_queue_lifetime bounds the undeliverable bounce messages themselves, while maximal_queue_lifetime bounds regular mail, so keeping bounce_queue_lifetime above maximal_queue_lifetime lets MAILER-DAEMON messages outlive the mail that triggered them; keeping the two aligned (the default) avoids that. If bounce_queue_lifetime exceeds maximal_queue_lifetime, bounce messages may persist in the queue longer than the original messages that triggered them.

How Netdata helps

• Queue size metrics at per-second resolution. Netdata’s Postfix collector tracks the deferred, active, incoming, and maildrop queue sizes. A sudden change in deferred queue depth alongside a bounce spike helps distinguish 5xx permanent failures (mail leaves the queue) from 4xx temporary failures (mail stays and accumulates).
• Correlation with system-level signals. Disk I/O wait, CPU load, and network latency all affect delivery throughput. Netdata lets you overlay these alongside queue metrics to rule out infrastructure causes when investigating a bounce spike.
• Anomaly detection on queue patterns. A gradual bounce rate increase may not cross a static threshold but still represents a trend worth investigating. Netdata’s anomaly detection flags deviations from learned baselines without requiring manual threshold tuning.
• Alerting on queue growth velocity. Tracking the rate of change catches bounce-driven queue growth early. Netdata can alert when the deferred queue grows faster than the drain rate, which often coincides with a bounce spike.
• Multi-instance visibility. If you run separate Postfix instances for submission versus delivery, Netdata can monitor each independently so a bounce spike in one instance does not get masked by healthy metrics in another.

Related guides

• Postfix deferred queue growing: why mail piles up and how to drain it
• Postfix active queue saturation: hitting qmgr_message_active_limit
• Postfix connection timed out: delivery deferrals to unreachable destinations
• Postfix destination concurrency limit: tuning per-destination delivery
• Postfix flushing and clearing the deferred queue: postqueue and postsuper
• How Postfix actually works in production: a mental model for operators