Section

PowerMTA max-smtp-out Tuning

Understanding max-smtp-out: What It Controls and What It Doesn't

max-smtp-out sets the maximum number of simultaneous outbound SMTP connections PowerMTA maintains to a destination domain (or MX host group, with mx-rollup). This is not a throughput setting — it is a concurrency limit. Higher max-smtp-out means more parallel connections, which allows more messages to be in delivery simultaneously. But ISPs enforce connection limits based on your sender reputation, and exceeding those limits produces 421 deferral responses that reduce effective throughput.

Section

Per-ISP Connection Limit Reference

ISP	Safe max-smtp-out (HIGH reputation)	Safe max-smtp-out (MEDIUM)	Safe max-smtp-out (Warming)	Notes
Gmail	6–10	3–5	1–3	421 4.7.0 = reputation-based limit exceeded
Outlook.com	4–6	2–4	1–2	RP-002 = connection rate exceeded
Yahoo	5–8	3–5	1–3	TSS04 = throttle, reduce connections
GMX/Web.de	2–4	1–2	1	Very conservative — German ISPs strict
Orange.fr	2–3	1–2	1	Low tolerance for new/unknown senders
Generic (unknown)	2–4	1–2	1	Default: conservative until reputation established

# max-smtp-out configuration per ISP reputation tier
# HIGH reputation pool:

    virtual-mta-pool high-rep-pool
    max-smtp-out 8
    mx-rollup gmail.com


# MEDIUM reputation — recovering from incident:

    virtual-mta-pool recovering-pool
    max-smtp-out 4         # Reduced until reputation recovers
    retry-after 20m
    mx-rollup gmail.com


# Warming pool — brand new IPs:

    virtual-mta-pool warming-pool
    max-smtp-out 2         # Very low — no reputation history
    max-msg-rate 50/h      # ~1,200/day in week 1
    retry-after 30m
    mx-rollup gmail.com

Section

max-smtp-out vs max-conn-rate: Combined Effect

max-smtp-out controls steady-state concurrency; max-conn-rate controls how fast new connections open. Both are needed. Setting max-smtp-out=10 without a max-conn-rate limit can cause PowerMTA to open all 10 connections simultaneously, which looks like a connection storm to the receiving ISP. Setting max-conn-rate=1/s with max-smtp-out=10 means connections open at 1 per second, reaching steady state of 10 over 10 seconds — a much healthier pattern.

# Combined configuration for controlled connection behavior

    max-smtp-out        8      # Max concurrent connections
    max-conn-rate       1/s    # Open 1 new connection per second
    max-msg-rate        300/h  # Messages per hour (optional cap)
    max-msg-per-conn    100    # Messages per connection before reconnect


# Effective throughput calculation:
# 8 connections × 100 msgs/connection × reconnect every ~60s
# = 8 × 100 / 60 ≈ 13 msgs/second = ~47,000 msgs/hour per pool
# With 10 IPs in pool: ~470,000 msgs/hour to Gmail

Section

Diagnosing Connection Limit Violations

# Signs that max-smtp-out is too high for current reputation:
# 1. 421 4.7.0 (Gmail) or 421 RP-002 (Microsoft) in dsnDiag
grep "421 4.7.0\|421 RP-002" /var/log/pmta/accounting.csv | \
  awk -F, '{count[$7]++} END {for(d in count) print count[d], d}' | sort -rn | head -5

# 2. High deferral rate that increases when volume increases
# (indicates hitting ISP connection limits proportionally to volume)

# Response: reduce max-smtp-out by 30-50%
# Verify: deferral rate should decrease within 1-2 hours
# Resume: increase max-smtp-out gradually (10-15% per week) as reputation improves

# Monitor connection count in real-time:
pmta show vmta gmail-ip-1 | grep "connections"
# Compare to your max-smtp-out setting

Calibrating max-smtp-out to Reputation Tier

The correct max-smtp-out value depends on your current Postmaster Tools reputation tier, not on a fixed "best practice" number. HIGH reputation at Gmail: 6-10. MEDIUM: 3-5. LOW: 1-2. New/warming IPs: 1-3. Exceeding ISP-appropriate limits at your current reputation tier produces 421 4.7.0 responses that compound reputation damage. Increase max-smtp-out incrementally: add 1-2 connections per week as reputation remains stable, not in large jumps.

Accounting Log Analysis for This Configuration

Monitor this configuration area through the PowerMTA accounting log's dsnDiag field. Filter accounting records for the specific ISP domains affected by this configuration and group dsnDiag responses by first 60 characters to identify the dominant error patterns. A deferral rate above 5% at any single ISP warrants investigation; above 15% requires immediate volume reduction and configuration review.

The dlvSourceIp field in the accounting log enables per-IP analysis within this configuration context. Comparing per-IP deferral rates identifies whether a configuration issue affects all IPs in a pool uniformly (configuration problem) or just specific IPs (reputation or IP-specific problem). This distinction determines the correct remediation path.

Calibrating to Your Current Environment

The parameter values documented in this reference are appropriate for established, warmed IPs with HIGH reputation at the target ISP. New or warming IPs, and IPs with MEDIUM or LOW reputation, require more conservative values. Move up incrementally as reputation signals confirm the infrastructure can sustain additional throughput. Review ISP-specific configuration monthly — Postmaster Tools reputation tier changes and SNDS status changes are the primary triggers.

Production Deployment Summary

Implementing this PowerMTA configuration correctly in production requires testing the specific parameter values against your actual IP reputation history, ISP distribution, and sending volume. The values documented here represent proven starting points, not fixed constants — your optimal configuration may differ based on your infrastructure's operational history.

After applying any configuration change, monitor the accounting log for the first 2-4 hours to verify the change produced the expected effect on deferral rates. A configuration change that was expected to reduce deferrals but shows no change (or increased deferrals) indicates either: the change addressed the wrong variable, or there is a confounding factor that needs investigation before continuing.

The Cloud Server for Email infrastructure team manages PowerMTA environments daily, applying the configuration principles documented in this reference series across clients with varied volume levels, ISP distributions, and reputation histories. Contact us at infrastructure@cloudserverforemail.com for a technical assessment of your specific PowerMTA configuration requirements.