How Retry Storms Occur and Why They Damage Sender Reputation

• June 2019
• Engineering Memo · External Release

A retry storm is one of the most damaging deliverability events a high-volume sender can experience, and one of the least understood. When an ISP begins deferring messages — returning 4XX temporary failure codes — the sending MTA queues the messages for retry. If the retry interval is too short and the deferred volume is large, the retries themselves generate additional deferral events, which generate more retries, which generate more deferrals. The loop feeds itself. Within hours, the MTA may be generating thousands of SMTP connection attempts per minute to an ISP that is returning 4XX responses to almost all of them — which the ISP interprets as spam behaviour, further damaging the sender's reputation.

This note explains the mechanics of retry storm formation, the specific configuration errors that make them likely, how to detect an emerging retry storm from the accounting log before it becomes severe, and the PowerMTA configuration practices that prevent them.

The Mechanics: How a Retry Storm Forms

A retry storm begins with a triggering event: an ISP starts returning 4XX responses to delivery attempts, typically because of a reputation-based throttle (the sender's complaint rate has risen above a threshold), a temporary ISP-side overload, or a sending volume spike that exceeds the established rate limit for the sender's reputation tier.

With 4XX responses arriving, the MTA queues all affected messages for retry. The first retry wave hits 5 minutes later (or whatever the initial retry interval is configured to be). Most of these retries receive 4XX responses again — the ISP-side condition that caused the initial deferrals has not resolved in 5 minutes. A second wave of retries is now queued. Meanwhile, new messages continue being injected into the queue and also receive 4XX responses on their first attempt. The queue is growing faster than it is clearing.

By the time the second retry wave fires, the queue may be twice the size of the first. The ISP receives twice as many connection attempts per minute as it did initially. Many ISPs interpret rapidly increasing connection attempt rates as aggressive spam behaviour — a sender that dramatically increases its SMTP connection rate in response to throttling is doing exactly what poorly configured spam sending software does. The ISP may respond by lowering the per-IP connection limit further or by issuing temporary IP blocks, which produces more 4XX responses, which produces more retries, which produces the fully-formed retry storm.

Configuration Errors That Cause Retry Storms

Retry storms are not inevitable — they are the predictable result of specific configuration choices that are common in default or naively configured MTA deployments. The three primary configuration errors:

Fixed short retry intervals. A retry configuration of "retry every 5 minutes" means that at T+5, T+10, T+15, T+20 minutes, the MTA attempts delivery of every deferred message simultaneously. Each wave is exactly the same size as the previous wave. The ISP receives consistent high-volume connection attempts with no relief period. Most ISPs interpret this pattern as aggressive bulk sending behaviour and apply progressively stricter throttling.

No maximum connection limit per domain. Without a max-smtp-out limit on domain blocks, the MTA may open as many concurrent connections as it has messages to deliver. During a retry storm, the unconstrained connection count can reach hundreds of simultaneous SMTP connections to a single ISP — which ISPs universally reject as abusive. The max-smtp-out limit is the primary control that prevents connection count spikes from developing.

Aggressive campaign injection during a deferral period. Injecting a new campaign's 500,000 messages while the previous campaign's deferred messages are still in the retry queue doubles the retry queue depth immediately. The combined load of previous retries plus new injection exceeds the ISP's acceptance rate even more severely, deepening the deferral cycle. In a well-configured environment, operators pause new campaign injection when a deferral rate exceeds a threshold — but without monitoring, new campaigns are injected without visibility into the existing deferral state.

PowerMTA Configuration That Prevents Retry Storms

The retry storm prevention configuration in PowerMTA uses exponential backoff — progressively longer intervals between retry attempts — combined with connection limits that prevent connection count spikes:

# Gmail domain block — retry storm prevention
<domain gmail.com>
  # Progressive retry intervals (exponential backoff)
  retry-after       5m 15m 30m 1h 2h 4h 8h
  
  # Connection limit — prevents connection count spikes
  max-smtp-out      20   # Max simultaneous connections
  
  # Maximum failures before extending backoff further
  max-failures-before-backoff  3
  
  # Message rate limit — prevents volume spikes from injection
  max-msg-rate      800/hour
  
  # Queue time limit — don't retry forever
  queue-life        5d
</domain>

<domain googlemail.com>
  use-domain gmail.com   # Same config for both Gmail domains
</domain>

The retry-after sequence — 5m, 15m, 30m, 1h, 2h, 4h, 8h — implements exponential backoff. The first retry comes 5 minutes after the initial failure (fast enough to catch transient ISP issues that resolve quickly). The second retry comes 15 minutes later. Each subsequent retry interval doubles or increases significantly. By the time the seventh retry is attempted (8 hours after the 6th), the ISP has had substantial time to resolve whatever triggered the initial deferral, and the retry volume is dramatically lower than a fixed-interval configuration would produce at the same point in time.

The max-smtp-out limit of 20 means the MTA will never open more than 20 simultaneous SMTP connections to Gmail, regardless of how many messages are queued. During a deferral period, the retry queue may have 100,000 messages waiting — but they will be retried through at most 20 concurrent connections, producing an orderly delivery rate rather than a connection spike. ISPs see the stable connection count as controlled, legitimate sending behaviour rather than the frantic connection attempts of a misconfigured or malicious sender.

Detecting an Emerging Retry Storm from the Accounting Log

A retry storm in formation is detectable from the accounting log before it becomes severe, if the operator knows what to look for. The early warning signs in the accounting log:

Rising 4XX response rate. Under normal operation, the 4XX response rate for a high-reputation sender to Gmail should be below 5%. When it rises above 10% and continues increasing over successive 15-minute accounting log windows, an emerging deferral accumulation is underway. The rising 4XX rate triggers queue growth; if the rate isn't addressed, the queue will grow until retry connection count escalates the deferral rate further.

Queue depth increasing between campaign sends. During a send window, queue depth growing is normal — campaign injection adds messages faster than they are delivered. But after injection stops, the queue should decline as retries clear. If queue depth continues growing after injection stops, or declines much more slowly than expected, the retry rate is insufficient to clear the deferred load — a sign that the ISP is throttling retries more aggressively than normal, which is the early stage of storm formation.

SMTP attempts per delivered message rising above 1.5. Under normal operation, each delivered message requires approximately 1.0–1.2 SMTP attempts (accounting for occasional greylisting retries). When this ratio rises above 1.5, the retry overhead is becoming significant. Above 2.0, a material portion of throughput is being consumed by retry attempts for deferred messages rather than new deliveries. Above 3.0, a retry storm is likely in progress — the majority of SMTP connection attempts are retries, not initial deliveries.

Breaking a Retry Storm in Progress

If a retry storm is already underway when detected, the first action is stopping new injection immediately. Adding new messages to an already-overwhelmed retry queue makes the situation worse — the ISP sees the connection rate continue rising even after it increases throttling pressure. With injection stopped, the existing queued messages continue retrying but the queue is no longer growing from new additions.

The second action is manually increasing the retry interval through PowerMTA's management interface or by modifying the domain block configuration and reloading. Changing the retry-after from "5m 15m" to "30m 1h 2h 4h" during a storm reduces the rate at which the MTA hammers the throttling ISP with retry attempts. The ISP sees the connection rate drop, which is the correct signal — it tells the ISP's throttle logic that the sender has responded to the throttling by reducing its connection rate, which is the legitimate-sender response. Spam senders maintain high connection rates through throttling; legitimate senders back off.

The third action is diagnosing the cause of the initial throttling. The accounting log SMTP response messages contain the ISP's reason for the 4XX: a reputation-based throttle (referencing spam rate or complaint rate), a volume-based throttle (connection rate exceeded), or an authentication-based throttle (rare, but possible if DKIM verification is failing). Each cause has a different remediation path: reputation throttles require reducing complaint rate and waiting for reputation recovery; volume throttles require reducing injection rate and connection limits; authentication throttles require immediate authentication configuration investigation.

Recovery from a reputation-triggered throttle that has escalated into a retry storm typically takes 12–36 hours after the configuration corrections are in place and injection has been paused. The ISP's reputation model needs time to observe that the connection rate has moderated and that new sends (when injection resumes at reduced volume with high-quality list segments) produce better engagement signals than the pre-storm sends. Resuming full-volume injection immediately after the storm appears to clear produces a second storm — the underlying reputation condition has not recovered. Gradual volume resumption (25% of normal, then 50%, then 75%, then full over 3–5 days) allows the reputation signals to rebuild before full sending load is applied.

The Reputation Cost of a Retry Storm

Beyond the immediate throughput impact, a retry storm produces lasting reputation damage. The ISP has observed two things: first, the sender's complaint rate or sending behaviour triggered the initial throttle; second, the sender's MTA responded to throttling by increasing its connection rate rather than backing off. This combination — poor reputation signals plus aggressive retry behaviour — is the signature of spam infrastructure. The ISP's reputation model assigns lower trust to sources that exhibit this pattern, which extends the period of throttling beyond what the initial triggering condition alone would have caused.

Post-storm reputation recovery requires demonstrating the opposite of what the storm demonstrated: low complaint rates (not just lower than during the storm, but lower than before it), controlled connection behaviour (the exponential backoff configuration that should have been in place before the storm), and gradual volume increase (showing the ISP that the sender responds to rate signals appropriately). This recovery period is typically 2–4 weeks of careful sending before delivery rates return to pre-storm levels and another 4–8 weeks before domain reputation metrics fully recover.

The total cost of a retry storm — throughput loss during the storm, post-storm reputation recovery period, degraded inbox placement during recovery — is substantially larger than the cost of implementing the preventive configuration that would have avoided it. The retry-after exponential backoff and max-smtp-out limit are configuration parameters that take 30 minutes to implement correctly and prevent an event that costs 6–12 weeks of recovery. This asymmetry is why experienced email infrastructure operators treat retry storm prevention as a foundational configuration requirement rather than an optional optimisation.

ISP-Specific Retry Behaviour: Why One Config Doesn't Fit All

Different ISPs respond to retry behaviour differently, which is why per-ISP domain block configuration in PowerMTA is the correct approach rather than a single global retry setting. Gmail, Yahoo, and Microsoft each have different retry rate tolerances, different throttle mechanisms, and different recovery timelines that require ISP-specific configuration to manage optimally.

Gmail is relatively tolerant of structured retry behaviour but very sensitive to sustained high connection rates during throttle events. Gmail's throttling tends to be reputation-triggered rather than volume-triggered for senders with established high-reputation IPs. The retry storm risk at Gmail is primarily from aggressive retry intervals amplifying a reputation-triggered deferral into a connection rate problem. The exponential backoff configuration with max-smtp-out capping connection count prevents this amplification. Gmail's reputation recovery after a storm is typically 2–4 weeks for a High-reputation sender who returns to clean sending practices.

Yahoo is more volume-sensitive than Gmail and more likely to return temporary 421 throttles in response to volume spikes even from high-reputation senders. Yahoo's retry behaviour tolerance is lower — a sender that retries 421 responses at 5-minute fixed intervals will accumulate connection pressure at Yahoo faster than at Gmail under the same circumstances. Yahoo domain blocks should use longer initial retry intervals (15–30 minutes instead of 5 minutes) and more conservative connection limits. Yahoo's throttling tends to resolve faster than Gmail's reputation-based throttles once the sending rate is moderated.

Microsoft (Outlook/Hotmail) uses rate limiting that is primarily IP-reputation-driven through SNDS signals. A Green SNDS status IP receives generous rate limits; Yellow status IPs receive tighter limits. When Microsoft begins returning 4XX responses, reading the SMTP response message text is particularly important because Microsoft's response codes often include specific guidance (referencing SNDS status, referencing specific policies). The retry interval for Microsoft domains should be 15–60 minutes depending on the SNDS status of the sending IP. A Yellow-status IP retrying aggressively during a Microsoft throttle event will trigger further throttle escalation more quickly than a Green-status IP doing the same.

Monitoring for Pre-Storm Conditions

The most valuable deliverability protection is catching pre-storm conditions before they escalate. The pre-storm indicators that appear in the accounting log before a storm forms are reliably predictable — the 4XX rate begins rising, the SMTP attempts-to-delivery ratio begins increasing, and queue depth begins growing faster than it clears. These trends appear 30–60 minutes before a full storm develops, providing a remediation window that doesn't exist once the storm is in progress.

The monitoring implementation for pre-storm detection: a process that reads new accounting log entries every 15 minutes, calculates the per-ISP 4XX rate for that window, calculates the SMTP attempts-to-delivery ratio for that window, and compares both values to the thresholds in Table 1. When either metric crosses the Warning threshold for two consecutive 15-minute windows — confirming a trend rather than a transient spike — the monitoring alerts the operator and triggers the pre-storm protocol: pause new injection, review current ISP SMTP response texts for cause identification, consider extending retry intervals.

This monitoring prevents the scenario where a retry storm develops entirely during off-hours or while the operations team is focused on campaign metrics rather than infrastructure metrics. Email campaigns often inject large volumes during business hours and then leave the infrastructure unmonitored overnight — precisely when a retry storm that started at campaign launch can compound over hours into a severe event that is discovered the next morning when delivery rates are dramatically degraded and thousands of messages are backlogged in the retry queue.

The Relationship Between Retry Pressure and Reputation

The ISP's reputation model for a sender accounts not only for engagement signals and complaint rates, but also for the sender's SMTP-layer behaviour — specifically how it responds to throttle signals. A sender that consistently backs off when throttled (exponential backoff, reduced connection count) is behaving like a legitimate bulk sender who respects ISP rate limits. A sender that maintains or increases its connection rate when throttled is behaving like spam infrastructure designed to overwhelm throttles.

Over time, this SMTP-layer behaviour pattern accumulates in the ISP's model. Senders with a history of appropriate backoff behaviour receive the benefit of the doubt during brief throttle events — the ISP's model "knows" this sender backs off, so a brief 4XX period is more likely to be met with a return to normal acceptance once the rate moderates. Senders with a history of aggressive retry behaviour face more persistent throttling because the ISP's model has learned that throttling signals alone don't produce the moderation of sending rate that legitimate senders exhibit.

This long-term behavioural reputation dimension is less discussed than engagement-based reputation, but it is real and measurable in the ISP-specific retry tolerance that experienced operators observe over years of operating infrastructure for the same sending domains. Domains with long histories of correct retry behaviour consistently experience shorter and less severe throttle events than domains with histories of aggressive retry. The correct retry configuration is therefore not only a technical choice — it is a reputation investment that pays compound returns over the lifetime of the sending programme.

Retry storm prevention is a foundational infrastructure concern because a single retry storm can damage reputation accumulated over months of clean sending, require weeks of recovery, and cost the programme revenue from degraded inbox placement during the recovery period. The configuration that prevents storms — exponential backoff, max-smtp-out limits, monitoring with pre-storm thresholds — is simple to implement and maintain. The programmes that implement it correctly never experience the compounding costs of the retry storms they prevent. The programmes that don't implement it experience at least one retry storm, invariably at the worst possible time, with costs that dwarf the configuration investment that would have prevented it.

The retry storm is ultimately a systems problem: a feedback loop where the MTA's response to ISP throttling makes the throttling worse, which makes the response more aggressive, which makes the throttling worse still. Breaking the feedback loop requires rate-limiting the response — exponential backoff and connection caps that ensure the MTA's retry behaviour is proportional to what the ISP will accept rather than proportional to the backlog of messages waiting to be delivered. Any MTA can be configured to generate retry storms; only correctly configured MTAs avoid them. In high-volume email infrastructure, this distinction is the difference between a stable, professionally managed sending environment and one that periodically generates reputation-damaging events that require weeks to remediate.

Exponential backoff, combined with per-ISP connection limits and proactive monitoring, transforms retry behaviour from a potential storm amplifier into a self-regulating system that naturally moderates its own load during throttle events. This is the configuration that professional email infrastructure operators implement as standard and maintain through every configuration update and ISP relationship change — because the alternative is a system that, under the wrong conditions, amplifies its own problems rather than limiting them.