PowerMTA Bounce Handling Configuration – Keep Bounces Under 2% (2026)

Why Bounce Handling Is Critical in 2026

Gmail, Yahoo, and Microsoft now enforce strict bulk sender rules. If your bounce rate exceeds 2%, your sending IP gets throttled or blocked entirely. PowerMTA gives you granular control over how bounces are processed — but only if you configure it properly.

Most senders install PowerMTA and leave bounce handling at defaults. That's a fast track to blacklisting. Here's how to set it up right.

Types of Bounces You Need to Handle

Hard bounces — permanent failures (invalid address, domain doesn't exist). These must be suppressed immediately and never retried.

Soft bounces — temporary failures (mailbox full, server busy, greylisting). PowerMTA should retry these with backoff, but give up after a threshold.

Policy bounces — the receiver rejected you based on reputation, content, or authentication failure. These need investigation, not just retry.

Step 1: Categorize Bounces by Response Code

Add bounce category patterns to your PowerMTA config (/etc/pmta/config):

<bounce-category-patterns>
  /^5\.1\.1/  bad-mailbox
  /^5\.1\.2/  bad-domain
  /^5\.2\.1/  inactive-mailbox
  /^5\.2\.2/  mailbox-full
  /^5\.7\./   policy-related
  /^4\.2\.2/  mailbox-full
  /^4\.7\./   rate-limited
</bounce-category-patterns>

This tells PowerMTA to tag each bounce so you can handle them differently in your automation scripts.

Step 2: Set Retry Limits for Soft Bounces

Don't hammer a server that's temporarily rejecting you. Use escalating retry intervals:


  retry-after             10m
  retry-after             30m
  retry-after             1h
  retry-after             4h
  max-retry-time          24h
  max-msg-rate            100/h
  max-connect-rate        10/min


This retries soft bounces at increasing intervals but gives up after 24 hours. After that, the message is logged as a permanent failure.

Step 3: Enable Bounce Accounting Logs
You need data to build your suppression list. Enable detailed bounce logging:

  records b
  record-fields b timeQueued,bounceCat,vmta,orig,rcpt,srcMta,dlvSourceIp,jobId,dsnStatus,dsnDiag

This creates a CSV with every bounce event, including the category, recipient, and diagnostic message from the receiving server.

Step 4: Automate Suppression of Hard Bounces
Create a cron job that extracts hard-bounced addresses and adds them to your suppression list:
#!/bin/bash
# /opt/scripts/update-suppression.sh
# Run daily via cron: 0 2 * * * /opt/scripts/update-suppression.sh

BOUNCE_LOG="/var/log/pmta/bounce.csv"
SUPPRESS_FILE="/etc/pmta/suppression.txt"

# Extract hard bounce recipients
grep -E "bad-mailbox|bad-domain|inactive-mailbox" "$BOUNCE_LOG" | \
  awk -F',' '{print $6}' >> "$SUPPRESS_FILE"

# Remove duplicates
sort -u "$SUPPRESS_FILE" -o "$SUPPRESS_FILE"

# Reload PowerMTA to pick up changes
pmta reload
Then reference the suppression file in your config:

  suppress-list /etc/pmta/suppression.txt


Step 5: Set Up Feedback Loops (FBL)
When a recipient marks your email as spam, the ISP can notify you. Register your sending IPs with:

Microsoft SNDS — snds.microsoft.com
Yahoo Complaint Feedback Loop — via their postmaster tools
Google Postmaster Tools — postmaster.google.com

Add FBL-reported addresses to your suppression list immediately. One complaint is a warning — continued sending to that address destroys your reputation.

Step 6: Monitor Your Bounce Rate Daily
Parse your accounting logs to calculate daily bounce percentage:
#!/bin/bash
# Quick bounce rate check
TOTAL=$(grep -c "^d" /var/log/pmta/acct.csv)
BOUNCED=$(grep -c "^b" /var/log/pmta/bounce.csv)
RATE=$(echo "scale=2; $BOUNCED * 100 / $TOTAL" | bc)
echo "Bounce rate: ${RATE}%"

if (( $(echo "$RATE > 2.0" | bc -l) )); then
  echo "WARNING: Bounce rate exceeds 2% threshold!"
fi

The 2026 Thresholds You Must Stay Under


Metric Maximum Allowed Consequence If Exceeded


Bounce rate 2% Throttling, then IP blocking
Spam complaints 0.3% Immediate throttling by Gmail/Yahoo
Invalid addresses per campaign 5% Reputation damage, slower delivery



How PMTAcore Helps Prevent Bounces
PMTAcore's Bulk Email Validator catches invalid addresses before you send — checking MX records, SMTP connectivity, and disposable domains. Clean your list first, and your bounce rate stays near zero without complex post-send automation.
The built-in IP Blacklist Checker alerts you the moment an IP gets listed, so you can act before deliverability tanks.
Download PMTAcore and validate your lists before your next campaign.

Key Takeaways

Categorize bounces by SMTP response code — handle hard and soft differently
Suppress hard bounces immediately — never send to them again
Set escalating retry intervals for soft bounces (max 24 hours)
Automate suppression list updates with a daily cron job
Register for ISP feedback loops to catch spam complaints
Monitor bounce rate daily — stay under 2% at all times
Validate your list before sending to avoid bounces entirely

How to Configure PowerMTA Bounce Handling (Reduce Bounces Below 2%)

Why Bounce Handling Is Critical in 2026

Types of Bounces You Need to Handle

Step 1: Categorize Bounces by Response Code

Step 2: Set Retry Limits for Soft Bounces

Step 3: Enable Bounce Accounting Logs

Step 4: Automate Suppression of Hard Bounces

Step 5: Set Up Feedback Loops (FBL)

Step 6: Monitor Your Bounce Rate Daily

The 2026 Thresholds You Must Stay Under

How PMTAcore Helps Prevent Bounces

Key Takeaways

`Related Articles`

PowerMTA Virtual MTA Configuration – Isolate Domains & Protect Reputation

PowerMTA vs Postfix: Which Email Server Is Better?

How to Check if Your IP is Blacklisted (DNSBL Guide)

Metric	Maximum Allowed	Consequence If Exceeded
Bounce rate	2%	Throttling, then IP blocking
Spam complaints	0.3%	Immediate throttling by Gmail/Yahoo
Invalid addresses per campaign	5%	Reputation damage, slower delivery