ISP-Specific Throttle Behaviour: Why One Size Fits All Fails

• August 2022
• Engineering Memo · External Release

Every major ISP applies rate limits to inbound email delivery — limits on simultaneous connections, messages per minute, and messages per hour from any single sending IP. These limits are not uniform across ISPs. Gmail's limits for a High-reputation sender are more generous than Yahoo's limits for the same sender. T-Online's greylisting behaviour differs from GMX's. Microsoft's connection tolerance differs from both. A default PowerMTA configuration that applies the same domain block settings to every ISP is simultaneously too aggressive for some (triggering unnecessary throttling) and too conservative for others (leaving throughput capacity unused).

This note documents the specific throttle behaviour of major ISPs, what their acceptance rate signals mean in the accounting log, and the per-ISP domain block configuration that matches each ISP's actual behaviour rather than applying a generic default.

Why ISP Throttle Behaviour Differs

ISP throttle limits reflect the intersection of two factors: the ISP's infrastructure capacity (how many inbound connections and messages per second the receiving infrastructure can process) and the ISP's reputation-based policy (how many messages per unit time they are willing to accept from a sender at a specific reputation tier). The first factor varies by ISP size — Gmail can accept vastly more messages per second than a regional EU ISP. The second factor varies by sender reputation at each ISP — a sender with High Gmail domain reputation receives more generous rate limits than the same sender with Medium reputation.

The practical consequence: the correct max-smtp-out and retry-after configuration for Gmail differs from the correct configuration for Yahoo, which differs from GMX, which differs from Free.fr. Applying Gmail's settings to all ISPs produces connection rate pressure at smaller EU ISPs that treat aggressive connection rates as a negative signal. Applying EU ISP settings to Gmail wastes throughput capacity that Gmail's infrastructure would accept from a well-regarded sender.

Gmail: Generous Limits for High-Reputation Senders

Gmail is the most throughput-generous major ISP for senders with established High domain reputation. A High-reputation sender can sustain 20+ simultaneous SMTP connections per IP without triggering throttle responses under normal conditions. Gmail's throttle mechanism is primarily reputation-based: senders with lower reputation receive tighter per-connection and per-day limits. The accounting log signal for Gmail throttling is a 421 4.7.0 response with a message referencing rate limits or connection limits.

Gmail throttle events are typically brief — a 5–15 minute backoff is sufficient for most Gmail throttle events to clear, after which acceptance resumes at the sender's normal rate. The exponential backoff configuration with an initial retry of 5 minutes is well-matched to Gmail's throttle recovery pattern. max-smtp-out of 20 for High-reputation senders is appropriate; during warmup, starting at 5 and increasing as reputation builds is the correct progression.

Gmail's throttle response to volume spikes is more pronounced than its steady-state throttle. A sender who injects 5× normal volume in a short window will encounter throttle responses even at High reputation, because the volume spike exceeds the rate that the established reputation tier authorises. Gmail's throttle during spikes produces 4XX responses that require the exponential backoff configuration to handle correctly — without it, the retries amplify the spike, producing the retry storm pattern described elsewhere.

Yahoo: Volume-Sensitive with Tighter Connection Limits

Yahoo applies tighter connection limits than Gmail for equivalent reputation levels. A sender who uses 20 concurrent connections to Gmail without issue will often encounter throttling at Yahoo with the same connection count. The appropriate max-smtp-out for Yahoo is 10–15 for High-reputation senders, with more conservative limits (5–8) for senders still in warmup or at Medium reputation.

Yahoo's throttle response codes (421 4.7.0, 421 4.7.1) are similar to Gmail's in structure but different in recovery behaviour. Yahoo's throttle events often last longer than Gmail's — a throttle that clears in 10 minutes at Gmail may require 30–60 minutes to clear at Yahoo. The retry-after sequence for Yahoo should use a longer initial interval than Gmail: starting at 15 minutes rather than 5 minutes reflects Yahoo's slower throttle recovery and prevents the rapid retry rate that extends Yahoo throttle events rather than allowing them to resolve.

Yahoo is also more sensitive to sending volume consistency than Gmail. A sender who consistently delivers 50,000 messages per day to Yahoo and then sends 200,000 in a single day will encounter more aggressive throttling than a sender whose volume increases gradually over weeks. Planning volume increases to Yahoo audiences with gradual weekly ramps produces better delivery rates than weekend-to-Monday spikes that coincide with campaign launches.

Microsoft: SNDS-Driven Limits with Specific Error Codes

Microsoft's throttle behaviour is closely tied to SNDS IP status. Green-status IPs receive more generous connection and message rate limits than Yellow or Red status IPs. The specific throttle response codes at Microsoft often include policy references that make the cause identifiable directly from the accounting log: 421 RP-001 references a connection rate policy; 450 4.7.1 references a delivery policy; 550 5.7.1 references a reputation block.

Reading the specific response code from Microsoft throttle events is important for choosing the correct response. A 421 connection rate throttle resolves by reducing max-smtp-out; a 450 delivery policy throttle may require investigating the SNDS complaint rate; a 550 reputation block requires postmaster contact or SNDS Yellow/Red investigation. The correct configuration for Microsoft domain blocks uses 15–20 max-smtp-out for Green-status IPs, with retry-after starting at 10–15 minutes to accommodate Microsoft's typical throttle recovery timeline.

Reading Throttle Signals from the Accounting Log

The accounting log records the SMTP response code and message text for every delivery attempt. The throttle signal patterns in the accounting log are the primary diagnostic tool for ISP-specific configuration tuning. The key patterns to identify per ISP: a rising 4XX response rate from a specific ISP domain that correlates with campaign injection (indicates volume-triggered throttle); a constant low-level 4XX rate at a specific ISP that is independent of campaign volume (indicates reputation-triggered steady-state throttle); a 4XX pattern that only appears on the first delivery attempt to each recipient (greylisting, not throttle).

The 4XX message text distinguishes throttle from greylisting in cases where the response code alone is ambiguous (both use 4XX). Greylisting messages typically contain the word "greylist" or "try again later" with no reference to rate limits. Throttle messages typically reference "rate limit exceeded," "connection limit," "too many connections," or similar rate-referencing language. The specific text varies by ISP; building a lookup table of known throttle and greylisting message patterns for each major ISP in the environment allows automated classification rather than requiring manual log review for each event.

The per-ISP deferral rate in the accounting log is the operational metric that drives configuration tuning. A sustained deferral rate of 15% at Yahoo while Gmail shows 3% indicates Yahoo-specific throttle pressure that requires Yahoo-specific configuration adjustment — reducing max-smtp-out for Yahoo's domain blocks and extending retry-after intervals until the deferral rate returns to normal. Making these adjustments at the per-ISP domain block level rather than globally ensures that the configuration change corrects the Yahoo-specific throttle without reducing throughput at Gmail or other ISPs where the existing settings are producing optimal results.

Per-ISP configuration is an ongoing tuning process, not a one-time setup. ISPs change their throttle policies periodically, new ISPs enter the sending programme's audience mix as the list grows, and reputation tier changes at specific ISPs require configuration adjustments that match the new reputation level's rate limits. Quarterly review of per-ISP deferral rates from the accounting log, compared against the configured limits, reveals configuration drift that has accumulated since the last review — and prompts the specific adjustments that keep each ISP domain block calibrated to current conditions rather than the conditions that existed when the configuration was last set.

Reputation Tier Changes and Configuration Adjustment

A key operational implication of per-ISP throttle behaviour is that the correct configuration changes when IP or domain reputation tier changes. A sender who moves from Medium to High Gmail reputation should increase max-smtp-out for Gmail domain blocks from 10 to 20, because the High reputation tier supports higher connection rates than Medium. A sender whose Yahoo IP moves from Green to Yellow SNDS status should decrease max-smtp-out for Yahoo domain blocks and extend retry-after intervals to reduce the connection pressure that may have contributed to the status decline.

The configuration-reputation linkage requires that configuration changes track reputation changes. The monitoring practice that supports this: when Postmaster Tools shows a domain reputation tier change, or when SNDS shows an IP status change, the per-ISP domain block configuration for the affected ISP should be reviewed and adjusted to match the new reputation context. Moving up in reputation → increase limits. Moving down → reduce limits and investigate the cause before the next send.

This dynamic configuration management is the operational discipline that extracts maximum throughput from the pool's current reputation standing at each ISP. A pool whose configurations are set correctly for Medium reputation but whose Gmail domain reputation has moved to High is leaving Gmail throughput capacity on the table — the High reputation authorises higher rates, but the Medium configuration settings prevent the pool from using them. Quarterly configuration reviews that align settings with current reputation levels prevent this throughput gap from persisting indefinitely.

The Long Tail of ISPs: Configuration Strategy for Minor Destinations

Beyond the major ISPs covered in detail above, any sending programme delivers to dozens of minor ISPs — regional email providers, small corporate mail servers, specialist domains — that each have their own throttle behaviour. Configuring individual domain blocks for every ISP that appears in the accounting log is impractical. The solution: a tiered configuration strategy that provides specific settings for major ISPs (those accounting for more than 5% of total send volume) and uses calibrated default settings for all other ISPs.

The calibrated default configuration for unspecified ISPs should use conservative settings — lower max-smtp-out (5–8) and longer retry intervals (10m initial, exponential thereafter) — that avoid triggering throttle responses at smaller ISPs with tighter limits. The conservative default produces slightly lower throughput for the long-tail ISP set but prevents the connection rate abuse that small ISP mail servers penalise aggressively. For the 5% of volume going to diverse small ISPs, the conservative default produces acceptable results without requiring per-ISP configuration work.

New ISPs that grow to represent more than 5% of total volume should be promoted to explicit domain blocks with configuration calibrated to their specific observed behaviour. The accounting log per-domain analysis that surfaces this threshold — which domains are receiving the most volume and what their specific deferral rates are — should be part of the monthly configuration review process. Adding explicit domain blocks for newly significant ISPs is among the most impactful configuration improvements available for programmes whose audience mix has evolved since the initial configuration was set.

ISP-specific throttle behaviour is not a configuration puzzle to be solved once and forgotten. It is an operational dimension of email infrastructure management that requires the same ongoing attention as list hygiene, reputation monitoring, and authentication maintenance. The ISPs change their throttle policies. Sender reputation at each ISP changes. Audience composition changes as the list grows. Each of these changes potentially invalidates a previously correct per-ISP configuration. The quarterly review that keeps per-ISP configurations aligned with current conditions is the maintenance practice that prevents the gradual drift between what the configuration authorises and what each ISP will actually accept — the drift that produces unnecessary throttle events, extended delivery windows, and throughput capacity that the reputation has earned but the configuration prevents from being used.

PowerMTA Configuration Syntax for Per-ISP Domain Blocks

PowerMTA's domain block configuration syntax allows any combination of settings to be applied to a specific destination domain. The configuration uses <domain hostname.com> blocks that override the global defaults for messages destined to that domain. Multiple domains can share a configuration using use-domain references, which avoids duplicating identical settings for related domains (gmail.com and googlemail.com share the same configuration; yahoo.com, yahoo.co.uk, and yahoo.fr share the same configuration).

# Gmail — High reputation sender configuration
<domain gmail.com>
  max-smtp-out           20
  max-msg-per-connection 20
  retry-after            5m 15m 30m 1h 2h 4h
  max-msg-rate           800/hour
</domain>
<domain googlemail.com>
  use-domain gmail.com
</domain>

# Yahoo — tighter limits, slower retry
<domain yahoo.com>
  max-smtp-out           12
  max-msg-per-connection 10
  retry-after            15m 30m 1h 2h 4h
</domain>
<domain yahoo.co.uk>
  use-domain yahoo.com
</domain>

# Microsoft — SNDS-calibrated
<domain hotmail.com>
  max-smtp-out           15
  max-msg-per-connection 10
  retry-after            10m 20m 45m 1h 2h
</domain>
<domain outlook.com>
  use-domain hotmail.com
</domain>
<domain live.com>
  use-domain hotmail.com
</domain>

# GMX — greylisting-aware
<domain gmx.de>
  max-smtp-out           8
  max-msg-per-connection 8
  retry-after            5m 15m 30m 1h 2h
</domain>
<domain web.de>
  use-domain gmx.de
</domain>
<domain gmx.net>
  use-domain gmx.de
</domain>

The use-domain reference means that updating the gmx.de domain block automatically applies the changes to gmx.net and web.de as well, reducing the maintenance overhead of keeping related ISP domains in sync. For ISPs that have many country-specific domains (Yahoo has yahoo.com, yahoo.co.uk, yahoo.fr, yahoo.it, yahoo.de, and others), a single parent domain block with use-domain references for all variants ensures consistent configuration without requiring individual updates for each variant.

The Case for Configuration Customisation Over Platform Defaults

Default MTA configurations — whether from PowerMTA out-of-the-box settings or from managed service templates — are designed to be safe for a wide range of sending programmes and ISP contexts. Safe means conservative: lower connection limits, longer retry intervals, smaller message batches. These conservative defaults prevent the most damaging configurations (unlimited connections, fixed short retries) but leave significant throughput capacity on the table for High-reputation senders at major ISPs.

The throughput gap between conservative defaults and ISP-calibrated configuration can be substantial. A High-reputation sender delivering to Gmail at 8 simultaneous connections per IP (conservative default) is leaving 60% of the throughput that Gmail's High-reputation sender policy supports unused. For a pool of 5 IPs delivering 500,000 messages per campaign, this unused throughput translates to extended delivery windows — 6–8 hours instead of 3–4 hours — from configuration conservatism rather than any ISP or reputation constraint.

The ISP-calibrated configuration invests the additional configuration work (typically 2–3 hours for initial per-ISP setup, 30 minutes per quarter for maintenance) to recover this throughput. For programmes where campaign delivery window length affects commercial performance — time-sensitive promotions, event-triggered sends, competitive campaigns where first-mover advantage matters — the throughput recovery from per-ISP configuration is a direct commercial return on the configuration investment. The "one size fits all" default is not incorrect; it is just not optimal, and the gap between safe and optimal grows as the programme's reputation improves and the ISP's authorised rate limits increase in response.

Debugging ISP Throttle Events: A Systematic Protocol

When an ISP shows elevated deferral rates in the accounting log, a systematic investigation protocol produces faster resolution than ad-hoc investigation. The protocol: (1) extract all 4XX responses from the affected ISP domain in the accounting log for the past 24 hours, sorted by response code; (2) read the SMTP response message text for the most common response code to identify whether the event is greylisting, volume-based throttle, or reputation-based throttle; (3) calculate the current deferral rate for that ISP (4XX responses / total SMTP attempts); (4) check Postmaster Tools domain reputation and spam rate for Gmail, or SNDS IP status for Microsoft — any recent change may correlate with the throttle onset; (5) compare the current max-smtp-out and retry-after settings for the affected ISP domain block against the guidelines in this note.

The investigation typically resolves to one of four findings: correct configuration but temporary ISP-side event (wait with current config); max-smtp-out too high for current reputation tier (reduce it); retry interval too short for ISP's throttle recovery time (extend it); or reputation decline that is triggering reputation-based throttle requiring both configuration adjustment and programme quality investigation. Each finding has a specific response; the investigation identifies which applies before any configuration changes are made, preventing changes that might address the wrong cause and miss the actual problem.

ISP-specific throttle behaviour is ultimately a communication channel — the ISP is sending signals about what sending rate it will accept from the current sender at the current reputation level, using SMTP response codes as the communication medium. Reading those signals correctly, and responding to them with configuration changes that match the ISP's actual capacity and policy, is the operational skill that separates productive ISP relationships from the adversarial dynamic that poorly-configured senders create through aggressive connection behaviour. The ISP's throttle is not an obstacle; it is a rate signal that, correctly interpreted and responded to, produces the maximum throughput that the programme's reputation level authorises.

The investment in per-ISP domain block configuration -- the 2-3 hours of initial setup and 30 minutes of quarterly maintenance -- is among the highest-ROI configuration investments available in email infrastructure management. It extracts throughput that High-reputation senders have earned but default configurations leave unused, eliminates the unnecessary throttle events that over-aggressive defaults generate at smaller ISPs, and produces the calibrated SMTP behaviour that ISPs recognise as professional bulk sending rather than the undifferentiated connection pressure of default-configured infrastructure. Every ISP in the sending pool is different; the configuration should reflect those differences rather than pretending they do not exist.

Per-ISP throttle management is not a feature of elite email infrastructure -- it is the operational standard that any programme relying on email as a commercial channel should be maintaining. The data is in the accounting log. The configuration changes are straightforward. The return on investment is immediate and compounding. The programmes that do not implement it are not making a deliberate trade-off; they are typically unaware that the throughput gap between default and calibrated configuration exists, and that the gap is entirely remediable through configuration rather than hardware or IP investment.