PowerMTA's default configuration is designed for broad compatibility and conservative delivery behaviour — it will work reasonably well out of the box for most sending programmes. Production tuning extracts significantly more throughput from the same hardware and IP pool by optimising the system-level configuration, connection pool parameters, queue management settings, and per-ISP domain block calibration. This guide documents the production tuning practices that consistently produce measurable throughput improvements without sacrificing deliverability quality.
Tuning Philosophy: Throughput vs Deliverability
Production tuning optimises for the maximum throughput that the current ISP rate limits and reputation tier will support — not the absolute maximum throughput that the hardware and network can deliver. Pushing beyond the ISP rate limits generates throttle responses that reduce effective throughput, trigger reputation signals from aggressive retry behaviour, and extend delivery windows. The optimally tuned PowerMTA configuration delivers messages at exactly the rate each ISP currently authorises, with efficient session reuse that minimises overhead per message.
The tuning data source is the accounting log. Before making any tuning change, establish the baseline: what is the current per-ISP deferral rate? What is the average messages-per-session ratio at each major ISP? What is the campaign delivery window (time from first injection to last delivered message)? These baseline metrics, measured from the accounting log before any tuning, provide the comparison point for evaluating whether each tuning change produces the expected improvement.
System-Level Optimisation: OS and Network
PowerMTA's throughput is constrained by the underlying operating system's networking stack when sending at high volume. Linux kernel network tuning improves throughput for high-connection-count sending:
# /etc/sysctl.conf — network tuning for PowerMTA # Increase TCP buffer sizes net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 # Increase connection tracking limits net.ipv4.tcp_max_syn_backlog = 8192 net.core.somaxconn = 65535 # Reduce TIME_WAIT socket accumulation net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 15 # Increase local port range for outbound connections net.ipv4.ip_local_port_range = 1024 65000 # Increase file descriptor limit fs.file-max = 200000
Apply these settings with sysctl -p and verify with sysctl net.ipv4.ip_local_port_range. The port range and TIME_WAIT settings are particularly important for high-throughput sending where many concurrent SMTP connections exhaust the default port range.
Also set PowerMTA's process file descriptor limit in /etc/security/limits.conf:
pmta soft nofile 100000 pmta hard nofile 200000
At high connection counts (500+ concurrent SMTP sessions), the default file descriptor limit (1024) becomes a binding constraint. Increasing it to 100,000-200,000 removes this constraint for all realistic sending volumes.
Connection Pool and Session Configuration
The PowerMTA connection pool is configured per-domain in the domain block configuration. The key parameters:
<domain gmail.com> max-smtp-out 20 # concurrent connections per source IP — calibrate to reputation tier max-msg-per-connection 200 # messages per session — calibrate below ISP per-session limit max-msg-rate 250/min # message rate per IP per minute — prevents burst throttle retry-after 10m 30m 1h 2h 4h 8h # retry backoff sequence require-tls true # enforce TLS for all Gmail connections </domain>
max-smtp-out is the highest-impact tuning parameter. At Gmail High reputation, values of 20-25 per IP consistently achieve maximum effective throughput without generating throttle. At Medium reputation, reduce to 12-15. At Low reputation, reduce further to 5-8. Empirically calibrate by starting at the lower end of the range, increasing in increments of 3-5, and monitoring the per-ISP deferral rate from the accounting log — the correct value is the highest setting that keeps the deferral rate below 5%.
max-msg-per-connection should be set to 70-80% of the ISP's observed per-session limit. For Gmail at High reputation: 150-200. For Yahoo: 80-120. For Microsoft: 50-80. For GMX/Web.de: 20-40. Exceeding the ISP's per-session limit causes mid-session connection resets visible as connection errors in the accounting log.
max-msg-rate prevents burst injection from generating throttle responses that appear when all connections attempt to deliver at maximum rate simultaneously. A per-minute rate limit smooths the delivery burst into a consistent rate that ISPs accommodate more reliably than irregular bursts.
Queue Management: Priority, Retry, and Expiry
PowerMTA's queue management determines how messages wait for delivery and how the MTA responds to deferral events. Tuning queue management improves delivery window predictability and prevents queue buildup during throttle periods.
Priority configuration: Assign different queue priorities to different traffic types using the priority directive in VMTA configuration. Transactional email (priority 1, highest) should always have queue access ahead of promotional campaigns (priority 3). This prevents promotional campaign throttle events from delaying transactional email delivery during congestion periods.
Retry sequence optimisation: The default retry sequence (retry every 1 hour) is appropriate for general soft bounces but too conservative for ISP throttle events (421 responses) that typically clear within 15-30 minutes. Configure a faster initial retry for throttle-specific responses:
<domain yahoo.com> # Fast retry for 421 throttle — Yahoo throttle typically clears in 5-15 minutes retry-after 5m 10m 30m 1h 2h 4h 8h # Maximum queue age — 72 hours for promotional, 24 hours for transactional queue-life 72h </domain>
Queue-life calibration: Promotional email can wait 72 hours in the queue — a message delayed by ISP throttle will eventually deliver. Transactional email (password resets, order confirmations) should have a 24-hour queue-life maximum — a password reset that has not delivered in 24 hours has likely been superseded by a new request and the queued message is no longer relevant. Set queue-life per-VMTA to match the traffic type's commercial relevance window.
Per-ISP Domain Block Calibration
The most effective throughput tuning is per-ISP domain block calibration — setting max-smtp-out, max-msg-per-connection, and max-msg-rate specifically for each major ISP destination based on that ISP's current rate limit behaviour. Generic global settings produce sub-optimal throughput at every ISP because no single setting is optimal for all ISPs simultaneously.
The calibration process for each major ISP:
▶ Per-ISP Calibration Workflow
The calibration workflow, applied quarterly across all major ISP domain blocks, consistently produces 15-40% throughput improvement over the default configuration for programmes that have never performed deliberate per-ISP calibration.
TLS Performance Optimisation
TLS handshake overhead is a measurable component of SMTP connection establishment latency. At high connection counts, TLS handshake time accumulates across the connection pool. Two TLS configuration optimisations reduce this overhead:
TLS session resumption: TLS 1.3 includes session tickets by default, allowing resumed TLS sessions to skip the full handshake for reconnections to the same server within the session ticket validity window (typically 24 hours). Ensure TLS 1.3 is preferred in PowerMTA's TLS configuration to benefit from TLS session resumption automatically.
ECDHE cipher preference: Elliptic Curve Diffie-Hellman (ECDHE) cipher suites are both more secure and faster than RSA key exchange ciphers. Configure PowerMTA to prefer ECDHE-based ciphers:
# In PowerMTA config smtp-tls-mode require smtp-tls-protocols TLSv1.2 TLSv1.3 smtp-tls-ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305
The TLS performance improvement from these settings is modest per connection (3-8ms per handshake saved), but at 500 concurrent connections, the cumulative improvement is measurable in campaign delivery windows.
Monitoring and Benchmarking Throughput
The accounting log provides the data for throughput benchmarking. Key metrics to monitor:
Messages per hour per IP: Group accounting log delivery events by source IP and hour, count successful deliveries (smtp_code=250). This metric, compared against the theoretical maximum (max-smtp-out × max-msg-per-connection ÷ average session time), reveals what fraction of theoretical capacity is being achieved. Values below 60% of theoretical indicate significant optimisation opportunity.
Session efficiency (messages per connection): Average messages delivered per SMTP session per ISP, compared against max-msg-per-connection. Session efficiency below 70% of max-msg-per-connection indicates that sessions are being terminated early — by ISP per-session limits (reduce max-msg-per-connection), by TLS errors (investigate certificate or cipher issues), or by connection timeouts (reduce idle connection hold time).
Campaign delivery window: Time from first message injection to last delivery event for each campaign. Tracking this metric per ISP reveals which ISP's rate limits are the binding constraint on overall campaign delivery time. The ISP with the longest per-ISP delivery window is the constraint that tuning should address first.
Building a weekly throughput benchmark report from the accounting log — covering messages per hour per IP, session efficiency, and per-ISP delivery windows for the previous week's campaigns — provides the trend data that identifies when throughput is improving (following tuning changes) or degrading (following reputation changes or ISP policy updates).
When to Add IPs vs Tune Configuration
The scaling decision — tune existing configuration vs add more IPs — depends on whether the throughput constraint is configuration-based or capacity-based. A configuration-based constraint exists when the current IPs can deliver at higher rates than the current configuration allows (evidenced by low deferral rates but long delivery windows). A capacity-based constraint exists when the current configuration is already at or near the ISP's rate limit and adding more IPs is the only way to increase throughput.
Diagnostic question: if max-smtp-out is increased for the binding-constraint ISP, does deferral rate increase (capacity constraint — ISP rate limit already reached) or stay low (configuration constraint — ISP rate limit not yet reached)? If deferral rate stays low when max-smtp-out is increased, the existing IPs have more capacity — tune the configuration. If deferral rate increases when max-smtp-out is increased, the ISP's rate limit for the current IP pool is already reached — adding IPs expands the total pool capacity.
Production tuning is the investment that extracts the full value from the existing IP infrastructure before committing to the 8-10 week lead time and ongoing hosting cost of additional IP capacity. Programmes that tune aggressively before scaling consistently achieve 2-4x the throughput on the same IP count as programmes that default to adding IPs at the first sign of throughput limitation. Tune first; scale when tuning has reached its limit; and the infrastructure will deliver at its full potential at every stage of the programme's growth.
The Tuning-Deliverability Balance
Every throughput optimisation carries a deliverability risk if miscalibrated. Increasing max-smtp-out beyond the ISP's actual rate limit generates the throttle pressure that produces both delivery delays (as messages queue behind throttle responses) and reputation signals (aggressive retry after throttle can appear as flood behaviour to ISP rate limit systems). The correctly tuned configuration walks the line between maximum throughput and zero throttle — and the accounting log is the instrument that shows whether the current settings are on the right side of that line.
The operational practice that keeps tuning on the right side of that line: after any tuning change, monitor the per-ISP deferral rate for 3 campaigns before considering the setting stable. A deferral rate that spikes on the first campaign after a max-smtp-out increase and then settles may indicate that the new setting pushes past the ISP's burst limit but not its sustained limit. A deferral rate that rises and stays elevated indicates the setting has exceeded the sustained rate limit and must be reduced.
Production tuning is an ongoing practice, not a one-time configuration event. ISP rate limits change as reputation changes; reputation changes as list quality and complaint rates evolve; programme volume changes as the business grows. The quarterly calibration review keeps the configuration aligned with the current reality of the programme's ISP relationships — ensuring the infrastructure always delivers at the full potential its reputation level and IP pool capacity support. Tune systematically; measure the effects carefully; and PowerMTA will consistently deliver at the performance level the programme's commercial objectives require.
The highest-performing PowerMTA deployments are not the ones with the most IPs — they are the ones that extract the most throughput per IP through disciplined, data-driven configuration tuning. That discipline is the operational investment that separates production-grade infrastructure from default-configuration deployments. Apply it quarterly; measure its effects from the accounting log; and the infrastructure will consistently deliver more with less than any alternative approach.