What Operators Get Wrong About SMTP Connection Reuse

• August 2022
• Engineering Memo · External Release

SMTP connection reuse — sending multiple messages within the same SMTP session rather than opening a new connection for each message — is a fundamental throughput optimisation that every production email MTA implements. When correctly configured, connection reuse significantly reduces the per-message overhead of TCP connection establishment, TLS handshake, EHLO exchange, and session teardown, allowing the MTA to deliver more messages per unit time through fewer network operations. When incorrectly configured, connection reuse produces subtle delivery problems that are difficult to diagnose because they appear as generic connection errors rather than SMTP protocol failures.

This note documents the specific configuration mistakes that operators most commonly make with SMTP connection reuse, the delivery consequences each mistake produces, and the correct configuration approach for each scenario.

Mistake 1: Setting max-msg-per-connection Too High

The max-msg-per-connection directive in PowerMTA (and equivalent settings in other MTAs) controls how many messages are delivered per SMTP session before the connection is closed and a new one is opened. Setting this value too high — above the receiving server's limit — causes the receiving server to terminate the connection in the middle of a session, producing a connection reset that appears in the accounting log as an abrupt session end without a final SMTP response code.

ISPs have per-session message limits that they do not publish. Gmail typically accepts 100-200 messages per connection at Medium reputation and up to 500+ at High reputation. Yahoo accepts 100-200 messages per connection. Microsoft accepts 50-100 messages per connection. When PowerMTA is configured with max-msg-per-connection 500 for Gmail at Medium reputation, approximately every 200th message in a session will encounter a connection termination — producing a delivery failure for that message, a retry that delivers the message but at the cost of a new connection, and accounting log entries showing unexplained connection resets at regular intervals.

The diagnostic signature of a too-high max-msg-per-connection: accounting log shows delivery failures clustering at regular intervals (every ~N messages) with connection reset errors, where N corresponds to the receiving server's actual per-session limit. The messages fail on first attempt but succeed on retry (because the retry opens a fresh session that reuses messages from the beginning of the new session limit). Reducing max-msg-per-connection to 80% of the observed N value (80-160 for Gmail Medium, 40-80 for Microsoft) eliminates the pattern.

Mistake 2: Setting max-msg-per-connection Too Low

The opposite mistake — setting max-msg-per-connection too low — wastes throughput through excessive session establishment overhead. A configuration with max-msg-per-connection 1 (one message per connection, equivalent to no connection reuse) opens a new SMTP session for each message: TCP connection, TLS handshake, EHLO, MAIL FROM, RCPT TO, DATA, message body, 250 response, QUIT, TCP teardown — approximately 8-12 round trips per message vs 3-4 with connection reuse. At high volume, this additional per-message overhead reduces throughput by 30-50% compared to efficient connection reuse.

The throughput cost of max-msg-per-connection 1 is directly visible in the accounting log as a low messages-per-connection ratio. If the average session delivers only 1-2 messages, the session establishment overhead is dominating the delivery capacity. The correct setting is not a single universal value but a per-ISP calibrated value based on the ISP's observed per-session limit: set max-msg-per-connection to 70-80% of the limit that the ISP enforces, which maximises messages per session without hitting the limit that causes session termination.

Many operators set max-msg-per-connection conservatively (5-20) out of caution about ISP session limits, without realising that this conservative setting is imposing a significant throughput penalty. The correct approach: start with max-msg-per-connection 50 for consumer ISPs and monitor the accounting log for session reset patterns. If no session resets appear, incrementally increase to 100, then 150, until session resets begin appearing. The value just below the first reset is the practical maximum for that ISP. This calibration takes 2-3 campaign cycles to complete but produces the optimal throughput for the programme's current reputation level at each ISP.

Mistake 3: Not Accounting for ISP Per-Session Limit Changes

ISP per-session limits are not fixed — they change as the sender's reputation changes. A programme that calibrated max-msg-per-connection to 150 for Gmail at High reputation, then experienced a reputation event that reduced domain reputation to Medium, may now be setting max-msg-per-connection above the Medium-reputation limit (which may be 80-100 rather than 150-200). The session reset pattern reappears in the accounting log after the reputation change, and the connection reuse configuration needs to be recalibrated for the new reputation tier.

The operational implication: max-msg-per-connection settings are not permanently fixed at the values that worked during warmup or at peak reputation. They are parameters that should be reviewed whenever the per-ISP deferral rate or session reset pattern in the accounting log changes significantly — which typically corresponds to a reputation change. The quarterly domain block calibration review should include checking whether session reset patterns have appeared or changed since the last review, and recalibrating max-msg-per-connection values for any ISP where the pattern has changed.

The quarterly review is not the only trigger for recalibration. Any significant accounting log pattern change — sudden appearance of session resets at a specific ISP, or disappearance of session resets that had previously been present — should trigger an immediate check of max-msg-per-connection for that ISP to determine whether the limit has changed (either because the ISP changed its policy, or because the sender's reputation tier changed). Reactive recalibration, triggered by accounting log pattern changes, keeps the connection reuse configuration aligned with the current ISP-reputation reality rather than a historical calibration that may no longer apply.

Mistake 4: Using the Same Connection Reuse Settings for Different Traffic Types

Transactional email and bulk promotional email have fundamentally different optimal max-msg-per-connection settings. Transactional email — password resets, order confirmations — is typically lower volume (a few thousand messages per day from a specific source) and is time-sensitive. Setting max-msg-per-connection too low for transactional traffic unnecessarily increases per-message session overhead; setting it too high is unlikely to hit ISP session limits at transactional volume levels. For transactional email, max-msg-per-connection 20-50 is a reasonable starting point that provides connection reuse benefit without any meaningful risk of hitting session limits.

Bulk promotional email is higher volume and less time-sensitive. The session limit matters more at bulk volume because the total number of sessions is higher and the per-session message count directly affects total session count (and therefore total session establishment overhead). For bulk promotional email, max-msg-per-connection should be calibrated to the ISP-specific limit for the current reputation tier, as documented above — closer to 100-200 for consumer ISPs at good reputation.

Using VMTA separation between transactional and promotional traffic allows per-traffic-type max-msg-per-connection configuration. The transactional VMTA can use a lower, more conservative value appropriate for time-sensitive low-volume traffic; the promotional VMTA can use a higher, calibrated value appropriate for high-volume bulk sending. Without VMTA separation, a single max-msg-per-connection setting must serve both traffic types — which means either compromising bulk throughput (by using a conservative transactional-appropriate value) or running transactional traffic through the same session size that bulk traffic uses (which is unnecessary for transactional volume levels).

SMTP connection reuse is a detail that most operators set once and never revisit. When set correctly and recalibrated as reputation changes, it provides a consistent throughput improvement that compresses campaign delivery windows and maximises the productive use of each connection the MTA opens. When set incorrectly — too high, too low, or at a stale calibration that no longer matches the current ISP-reputation reality — it produces either wasted throughput or session reset delivery failures that appear as mysterious connection errors in the accounting log. Review it quarterly; recalibrate it when accounting log patterns change; and connection reuse will remain an invisible efficiency that the programme benefits from without ever needing to think about actively.

Diagnosing Connection Reuse Problems from the Accounting Log

The accounting log signature of max-msg-per-connection set too high: look for delivery failures where the deferral_reason field shows a connection error (TCP reset, connection dropped, timeout) but NOT a 4xx or 5xx SMTP response code — the session ended without an SMTP response, meaning the receiving server terminated the TCP connection rather than issuing an SMTP error. Count how many messages were delivered in the session before the connection drop: if the number is consistently around a specific value (e.g., almost always at message 101-110 of a session), the receiving server has a per-session limit near 100 messages and the max-msg-per-connection of 120 is exceeding it.

The accounting log signature of max-msg-per-connection set too low: compare the average messages-per-session ratio across all sessions in a campaign to the max-msg-per-connection setting. If the average messages-per-session is consistently near the max-msg-per-connection value (meaning most sessions reach their configured limit before closing), the setting may be calibrated correctly. If the average messages-per-session is significantly below the max-msg-per-connection (meaning sessions are frequently closed by the receiving server before reaching the configured limit), either the ISP's per-session limit is lower than the configured maximum, or sessions are being closed for other reasons (idle timeout, TLS error, connection limit exceeded). Distinguishing these cases requires checking whether sessions close at a consistent message count (indicating an ISP per-session limit) or at variable message counts (indicating another cause).

A useful accounting log query for connection reuse diagnostics: group delivery events by SMTP session ID and count the messages per session. The distribution of messages-per-session reveals: sessions that consistently max out at the configured limit (correctly configured), sessions that end at a consistent lower number (ISP per-session limit below the configured max), and sessions with highly variable message counts (other connection factors determining session length). This per-session analysis requires that the accounting log captures a session identifier field — which PowerMTA supports in its accounting log configuration via the session-id macro.

The Session Reuse Rate Metric

The session reuse rate — the percentage of messages delivered without opening a new session — is the operational metric that quantifies how efficiently connection reuse is working. A configuration where 90% of messages are delivered within a continuing session (not the session's first message) and only 10% require a new session to be opened is achieving 90% session reuse. A configuration where 50% of messages require new sessions is achieving 50% session reuse and paying the overhead cost for all those new sessions.

For a high-volume programme delivering 2 million messages per day to Gmail, the difference between 50% and 90% session reuse is approximately 800,000 additional session establishment operations per day — each consuming 3-6 round trips of TCP connection, TLS handshake, and EHLO exchange that would not be required with efficient connection reuse. At 50ms average round trip to Gmail's servers, 800,000 × 5 round trips × 50ms = approximately 200,000 seconds of unnecessary overhead — the equivalent of connection establishment time for 4,500 additional seconds of delivery capacity consumed in pure overhead. The session reuse rate metric converts the abstract concept of connection reuse efficiency into a concrete throughput impact calculation.

Tracking the session reuse rate per ISP, per VMTA, and over time — via the per-session accounting log analysis described above — provides the data to manage connection reuse configuration as a continuous operational discipline rather than a one-time configuration decision. An ISP where the session reuse rate has dropped from 90% to 70% over the past 4 weeks may have changed its per-session limit (requiring recalibration of max-msg-per-connection) or may be applying more aggressive throttle (causing more sessions to be terminated early by throttle responses rather than message limit). The session reuse rate trend distinguishes these two causes: a sudden drop to a new stable level suggests a configuration or policy change; a gradual decline suggests increasing throttle pressure from reputation signals.

SMTP connection reuse, configured correctly and monitored continuously, is infrastructure efficiency that pays for itself in delivery throughput every day the infrastructure operates. It does not require active management under normal conditions — it is a background efficiency that just works. It requires attention only when accounting log patterns show session reset anomalies or when the session reuse rate metric shows a declining trend. Building the monitoring to detect these signals, and the operational process to recalibrate when they appear, keeps connection reuse providing its full throughput benefit permanently. Ignore it, and the infrastructure gradually loses throughput efficiency as ISP limits or reputation tiers change without corresponding recalibration of the connection reuse configuration. Monitor it, and connection reuse remains the reliable, invisible throughput optimisation it is designed to be.

The Connection Pool and Session Reuse Interaction

max-msg-per-connection does not operate in isolation — it interacts with max-smtp-out (the number of concurrent connections per IP) and the queue depth per ISP to produce the actual message delivery rate. A configuration with max-smtp-out 20 and max-msg-per-connection 100 can deliver up to 2,000 messages per connection cycle: 20 simultaneous sessions, each delivering 100 messages before closing and reopening. The actual throughput is this theoretical maximum discounted by session establishment overhead (which the high max-msg-per-connection minimises), ISP response latency (which is fixed), and TLS handshake time (which is amortised over the 100 messages in the session).

Understanding this interaction allows operators to estimate theoretical throughput from the PowerMTA configuration and compare it against observed throughput in the accounting log. If the theoretical maximum is 2,000 messages per cycle and the observed throughput per cycle is 1,400, the 30% gap may be explained by ISP response latency (unavoidable), session establishment overhead on session reopen cycles (reducible by increasing max-msg-per-connection), or throttle responses that slow specific sessions without terminating them (reducible by adjusting max-msg-rate). Identifying which factor is causing the gap requires the per-session accounting log analysis described above.

The throughput optimisation exercise — maximising the messages-per-session ratio within ISP per-session limits, while maintaining the per-IP connection count within ISP connection limits — is a system-level optimisation that requires understanding both max-smtp-out and max-msg-per-connection together. Optimising one without the other produces suboptimal results: high max-smtp-out with low max-msg-per-connection results in many short sessions with high session establishment overhead; high max-msg-per-connection with low max-smtp-out results in a few long sessions that underutilise the available connection slots. The optimal configuration balances both parameters to produce the highest messages-per-unit-time for the current ISP reputation tier.

SMTP connection reuse, understood as the interaction between max-smtp-out, max-msg-per-connection, ISP per-session limits, and reputation tier, is a continuous optimisation problem with a different optimal solution for each ISP at each reputation tier. The quarterly calibration review is the operational mechanism that keeps the solution current; the accounting log is the data source that makes the optimisation evidence-based; and the PowerMTA domain block configuration is the tool that implements the solution. Configure it correctly; review it quarterly; and SMTP connection reuse will deliver its full throughput benefit indefinitely, without session resets or throughput waste, across every ISP destination the programme serves.

The Complete Connection Reuse Configuration Checklist

The connection reuse configuration checklist for a new PowerMTA deployment or a quarterly recalibration: (1) Set per-ISP max-msg-per-connection starting values based on the current reputation tier (High: 150-200 for consumer ISPs; Medium: 80-120; Low: 30-50). (2) Set per-traffic-type values in each VMTA's domain block — transactional at 20-50, promotional at the ISP-specific reputation-tier value. (3) Run the first 2-3 campaigns after configuration and review the accounting log for session reset patterns (connection errors at consistent message counts within sessions). (4) If session resets appear at specific message counts, reduce max-msg-per-connection to 80% of the observed reset message count and re-run. (5) If no session resets appear and throughput seems below expectations, calculate the theoretical maximum vs observed throughput and investigate whether low max-msg-per-connection is limiting it. (6) Document the final calibrated values per ISP per VMTA in the infrastructure configuration notes, with the date calibrated and the reputation tier at the time of calibration.

Step 6 — documentation — is the step that most operators skip, and its absence is why recalibration is needed more frequently than it should be. When the reputation tier changes and the connection reuse configuration needs updating, the operator who has documented the current values, the reputation tier at calibration, and the calibration date has a clear starting point for recalibration. The operator who has not documented these values must repeat the full calibration process from scratch rather than making targeted adjustments from a known baseline. The 10 minutes of documentation at calibration time saves an hour of recalibration investigation when the next update is needed.

Connection reuse is foundational MTA configuration — set at deployment, recalibrated as reputation changes, and otherwise invisible in normal operations. When correctly configured, it delivers consistent throughput improvement without active management. The only time it requires attention is when accounting log patterns reveal that the configuration has drifted from the optimal value for the current ISP-reputation state. Build the monitoring to detect that drift, maintain the documentation to understand the baseline, and connection reuse will deliver its throughput benefit reliably across the programme's full operational lifetime.

Connection reuse is the infrastructure configuration that works quietly when correct and produces subtle mysteries when wrong. The mysteries resolve immediately when the accounting log is read correctly and the configuration is recalibrated appropriately. That combination -- correct monitoring and correct configuration -- is the complete solution to the connection reuse problems that this note documents. Apply it consistently, and connection reuse will never be a source of unexplained delivery anomalies again.

The most common infrastructure configuration mistakes are the invisible ones -- the ones that produce subtle throughput losses or intermittent session resets that appear as generic errors rather than identifiable configuration problems. SMTP connection reuse misconfiguration is one of the most common and most invisible. Calibrate it correctly; document the calibration; monitor the session reuse patterns quarterly; and this particular source of invisible throughput loss will permanently stay solved.

Calibrate once. Document. Review quarterly. The throughput improvement compounds with every campaign. The session reset mysteries never appear. That is the operational outcome of connection reuse done correctly.

The SMTP session is the basic unit of email delivery. How many messages ride each session — and how that number is calibrated against ISP limits and reputation tiers — determines whether the infrastructure delivers at its full potential or leaves throughput capacity on the table. Get it right. Review it regularly. Let it do its job invisibly.