Contents
A high deferral rate at a specific ISP is one of the clearest operational signals in high-volume sending. It indicates that the ISP is actively throttling or restricting delivery from your infrastructure, and that the default retry behavior will not resolve the situation without operational intervention. Understanding how to quickly isolate which ISP, which IP, and which sending stream is generating the deferral spike determines whether you can respond in minutes or hours — a critical difference for time-sensitive campaigns and reputation recovery.
Section 1
Identifying High Deferral Rate in Real Time
# Real-time deferral rate by ISP (last 60 minutes)
awk -F, -v cutoff="$(date -d '60 minutes ago' '+%Y-%m-%dT%H:%M')" '
NR>1 && $2 >= cutoff {
split($6, a, "@"); domain=a[2]
if($1=="t") deferred[domain]++
if($1=="d") delivered[domain]++
} END {
for(d in deferred) {
total = deferred[d] + delivered[d]
if(total >= 50) {
printf "%-25s: %d%% deferral (%d deferred / %d total)\n",
d, deferred[d]/total*100, deferred[d], total
}
}
}' /var/log/pmta/accounting.csv | sort -t: -k2 -rn | head -15
# Quick check via pmta commands:
pmta show queue --all | sort -k3 -rn | head -10
# Rising queue for a specific domain = increasing deferral rate
Section 2
Isolating Deferral by IP and ISP
# Which source IP has the highest deferral rate at Gmail?
awk -F, 'NR>1 && $7~/gmail/' /var/log/pmta/accounting-YYYYMMDD.csv | \
awk -F, '{
ip=$15
if($1=="t") def[ip]++
if($1=="d") del[ip]++
} END {
for(ip in def) printf "%s: %.1f%% deferral (%d deferred)\n",
ip, def[ip]/(def[ip]+del[ip]+0.01)*100, def[ip]
}' | sort -t: -k2 -rn
# Which virtual MTA is most affected?
pmta show vmta gmail-ip-1 # Check per-virtual-MTA queue
pmta show vmta gmail-ip-2
pmta show vmta gmail-ip-3
# What are the specific deferral messages at that ISP?
awk -F, 'NR>1 && $1=="t" && $7~/gmail/ && $15=="185.x.x.10"' \
/var/log/pmta/accounting.csv | \
awk -F, '{print substr($10,1,60)}' | sort | uniq -c | sort -rn | head -10
Section 3
Common Root Causes of ISP-Specific Deferral Spikes
| Root Cause | Indicators | Resolution |
|---|---|---|
| IP reputation degraded | 421 4.7.0 (Gmail), RP-001 (Microsoft) in dsnDiag | Reduce volume; check Google Postmaster Tools integration / Microsoft SNDS |
| Spam rate spike | 421 4.7.0 at Gmail + Postmaster Tools spam rate elevated | Pause affected campaign; investigate complaint source |
| Connection limits exceeded | 421 RP-002 (Microsoft), 421 4.2.1 (Gmail) — high volume | Reduce max-smtp-out tuning; increase retry-after |
| Authentication failure | 421 4.7.28 (Gmail), 5.7.26 at scale | Fix DKIM/DMARC; check all sending paths |
| IP added to blacklist detection and delisting | 550 5.7.606, 550 5.7.1 IP blocked — increasing | Check MXToolbox blacklists; request delisting |
| Content triggering filters | 550 5.7.1 spam across all IPs simultaneously | Review message content; test with mail-tester.com |
Section 4
Gmail-Specific Deferral Diagnosis
# Step 1: Check the specific 421 code pattern
grep "gmail.com" /var/log/pmta/accounting.csv | \
awk -F, '$1=="t" {print substr($10,1,60)}' | sort | uniq -c | sort -rn | head -5
# If "421 4.7.0" is dominant: reputation issue
# → Check Google Postmaster Tools spam rate immediately
# → Reduce max-smtp-out by 50%
# → Increase retry-after to 30m
# If "421 4.2.1" is dominant: normal Gmail throttle
# → No action needed; Google is managing rate
# → Do not increase connections
# Step 2: Check Postmaster Tools spam rate (24-72h lag)
# Step 3: Check IP reputation tab for each sending IP
# Step 4: If spam rate is above 0.07%, identify which campaign/segment
grep "2026-01-15" /var/log/pmta/accounting.csv | \
awk -F, '$1=="d" && $7~/gmail/ {campaigns[$9]++} END {
for(c in campaigns) print campaigns[c], c
}' | sort -rn | head -10 # Which campaigns ran today?
Section 5
Microsoft-Specific Deferral Diagnosis
# Check SNDS for each sending IP
# https://sendersupport.olc.protection.outlook.com/snds/data.aspx
# Check specific Microsoft 421 code pattern
grep "outlook.com\|hotmail" /var/log/pmta/accounting.csv | \
awk -F, '$1=="t" {print substr($10,1,60)}' | sort | uniq -c | sort -rn | head -5
# RP-001 in results: reputation policy block
# → Stop sending from that IP for minimum 4 hours
# → Check SNDS — likely showing YELLOW or RED
# → Do not retry aggressively
# RP-002 in results: connection rate exceeded
# → Reduce max-conn-rate (e.g., from 1/s to 0.3/s)
# → Increase retry-after to 30m
# → This is a configuration issue, not a reputation issue
Section 6
Operational Response Protocol
| Deferral Rate at ISP | Error Type | Immediate Action | Investigation |
|---|---|---|---|
| 5-15% | Normal throttle (421 4.2.1) | No change — monitor | None needed |
| 15-25% | Mixed throttle + reputation | Reduce max-smtp-out 30% | Check spam rate; review complaints |
| 25-50% | Reputation-based (421 4.7.0) | Reduce volume 50%; increase retry-after | Postmaster Tools; SNDS; campaign analysis |
| 50%+ | Policy block or IP reputation | Pause sending from affected IPs | Full investigation before resuming |
FAQ
Frequently Asked Questions
What deferral rate is considered high for Gmail?
How do I isolate which IP is causing high deferral at a specific ISP?
Can a high deferral rate at one ISP indicate a cross-ISP reputation problem?
Should I pause sending to an ISP when I see high deferral rates?
What is the relationship between bounce rate and deferral rate?
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.
