- October 2022
- Engineering Memo · External Release
Volume spikes in email sending programmes are sometimes planned — a product launch, a major promotional event, a list acquisition that doubles the active contact count overnight — and sometimes accidental — a campaign that was sent twice, a scheduled send that triggered at 10× intended volume, a data import that queued millions of messages unexpectedly. Both types stress email infrastructure in similar ways: the sending volume exceeds what the current IP pool capacity and ISP rate limits can absorb at the sender's current reputation level, producing a cascade of deferrals, queue growth, and in the worst case, a retry storm.
This note documents how correctly configured infrastructure responds to volume spikes automatically, what additional intervention the operator should make when automatic responses are insufficient, and what actions make the situation worse despite seeming helpful in the moment.
What Happens to Infrastructure During a Volume Spike
When injection volume spikes beyond the pool's sustainable delivery rate, messages queue in PowerMTA's delivery queue. The queue grows at the rate of the difference between injection rate and delivery rate. If 100,000 messages are being injected per hour and the pool can sustain 60,000 deliveries per hour (given current ISP rate limits and IP count), the queue grows by 40,000 messages per hour.
As the queue grows, the messages already in the queue age. For time-sensitive transactional email, aging messages become useless before they deliver. For promotional campaigns, the aging produces messages that deliver hours after the campaign launched, reaching recipients outside the primary engagement window. The queue depth is also visible to ISPs through the retry patterns it produces — a large queue of deferred messages generates SMTP connection attempts at a rate that some ISPs interpret as spam-like behaviour, compounding the delivery rate problem.
ISPs respond to volume spikes in their own ways: Gmail may apply additional rate limiting on top of the sender's established rate; Yahoo may begin returning 421 temporary failures at higher rates; EU ISPs may increase greylisting frequency. These ISP responses are the system working as designed — they are designed to limit the throughput of senders whose volume exceeds what their reputation tier authorises. A sender with High reputation and 5 warm IPs can sustain much higher volume spikes than a sender with Medium reputation and 2 warm IPs before ISP throttling becomes significant.
Figure 1 — How Infrastructure Responds to Injection Volume Spike
Automatic Responses: What PowerMTA Does Without Operator Intervention
A correctly configured PowerMTA handles moderate volume spikes automatically through several mechanisms:
Queue depth management. Messages queue in PowerMTA's delivery queue and are processed according to the domain block retry configuration — the queue absorbs spike volume without loss, holding messages until they can be delivered within the ISP's rate limits. The queue is the buffer that prevents volume spikes from requiring immediate ISP-side acceptance of the full spike volume.
Connection limit enforcement. The max-smtp-out limit in domain blocks prevents PowerMTA from opening unlimited connections to ISPs during high queue depths. Even with 200,000 messages queued for Gmail, the max-smtp-out limit of 20 ensures PowerMTA opens at most 20 simultaneous connections. This controlled connection count prevents the connection rate spikes that trigger ISP-side additional throttling.
Exponential backoff during throttling. When ISPs return 4XX responses during volume spikes (applying additional throttling), PowerMTA's retry-after configuration with exponential backoff produces progressively longer retry intervals. This prevents the retry-storm amplification of throttled messages and gives ISPs time to clear their own queue processing before PowerMTA retries aggressively.
These automatic mechanisms handle moderate spikes (2–3× normal volume) gracefully — the queue builds temporarily, ISP delivery rate limits the throughput, and the queue clears over hours as the spike volume is delivered within sustainable rate limits. Operator intervention is not required for moderate spikes if the configuration is correct.
When Operator Intervention Is Required
Larger spikes (5–10× normal volume or higher) may require operator intervention to prevent queue accumulation from creating problems that automatic mechanisms cannot resolve. The intervention decision criteria: if the accounting log shows the queue depth growing consistently over 60 minutes without any sign of stabilisation, or if the deferral rate at major ISPs exceeds 30% (indicating significant throttling), manual intervention is appropriate.
Intervention 1: Pause new injection. The first and most important intervention is stopping new message injection into the spike-affected queue. This prevents the queue from continuing to grow while automatic mechanisms work to clear the existing backlog. In MailWizz, this means pausing the running campaign. For application-injected messages, this means pausing the sending application or rate-limiting its injection rate to match sustainable delivery capacity.
Intervention 2: Triage the queue. If the queue contains messages of different priority levels (for example, transactional messages that are time-sensitive mixed with promotional messages that can wait), use PowerMTA's priority queue features to ensure time-sensitive messages are processed first. Lower the priority of promotional messages in the queue so transactional messages are not delayed by the promotional backlog.
Intervention 3: Temporarily reduce connection limits. Counterintuitively, reducing max-smtp-out during a spike (rather than increasing it) can improve actual throughput by reducing the number of connections that ISPs are simultaneously throttling. Fewer, more productive connections that deliver a higher proportion of messages without throttle-induced retries can outperform many connections that are mostly receiving 4XX responses. Reduce max-smtp-out to 50–70% of normal during the spike response and restore after the queue stabilises.
Table 1 — Volume spike response: actions by spike severity
| Spike severity | Accounting log signals | Automatic handling | Operator action required |
|---|---|---|---|
| Mild (1.5–2× normal) | Slight queue depth increase; deferral <10% | Self-resolving via queue | Monitor; no action needed |
| Moderate (2–4× normal) | Queue growing; deferral 10–25% | Partially — may extend delivery window | Consider pausing new injection; monitor queue |
| Severe (4–10× normal) | Queue growing fast; deferral 25–50% | Insufficient — queue will compound | Pause injection immediately; triage queue |
| Catastrophic (10×+) | Queue growing uncontrolled; deferral 50%+ | None — retry storm risk | Stop all injection; drain queue; investigate before resuming |
What NOT to Do During a Volume Spike
Do not increase max-smtp-out. Adding more simultaneous connections to an ISP that is already throttling increases the connection rate that the ISP sees, which typically causes it to throttle more aggressively. The instinct to "push harder" against a throttle makes it worse. The correct response is to moderate the connection rate and allow the throttle to relax.
Do not reduce retry intervals to clear the queue faster. Shorter retry intervals during a throttle event produce retry storms — the specific anti-pattern described in the retry storms note. The queue will not clear faster if retries arrive more frequently; it will produce more 4XX responses, more queue growth from retry overhead, and a worsening throttle response from the ISP.
Do not inject new campaign volume on top of an existing spike queue. The temptation during a spike is to inject the next campaign as scheduled, trusting the queue to eventually process both. This compounds the queue depth and extends the time until both campaigns deliver. If the queue from the spike is significant (over 50,000 messages for a typical programme), hold the next campaign injection until the spike queue has cleared below 10,000 messages.
Do not ignore the Postmaster Tools spam rate during and after a spike. High-volume injection to lower-engagement contacts during a spike can produce elevated complaint rates that affect domain reputation. Check Postmaster Tools spam rate 24–48 hours after a spike send to confirm whether complaint rates were elevated. If they were, the spike send included lower-quality list segments that should be identified and handled with more conservative practices in future spikes.
Planned Volume Spikes: Infrastructure Preparation
For planned volume spikes — a product launch with a large acquisition list, a Black Friday campaign with 4× normal volume — the correct preparation is described in the capacity planning and seasonal volume notes. The key point: planned spikes require infrastructure preparation 6–8 weeks in advance, not in the days before the event.
When a planned spike is imminent (within 48 hours) and preparation has been completed correctly, the additional monitoring during the spike send is the primary operational requirement. Set up real-time accounting log monitoring for the campaign duration, check DNSBL status before injection, verify Postmaster Tools domain reputation baseline before send, have incident response protocols ready, and designate who is on-call during the campaign send window with authority to make rapid intervention decisions if monitoring alerts trigger.
The difference between a planned spike and an unplanned spike is entirely the preparation window. Planned spikes with correct preparation run through the additional volume with controlled delivery extension and manageable queue depths. Unplanned spikes — or planned spikes that did not include infrastructure preparation — produce the queue growth, deferral rate increases, and potential reputation impact described throughout this note. The operational lesson is simple: the only effective response to a volume spike is preparation before it occurs; response during the spike can only limit the damage, not prevent it.
Accidental Re-Send Incidents: The Worst-Case Volume Spike
The most stressful volume spike scenario is the accidental re-send: a campaign that was already delivered to 500,000 recipients is re-injected and begins sending again to all 500,000 addresses. This is a genuine emergency — the recipients are receiving duplicate emails, which will generate significantly elevated complaint rates from annoyed recipients, while the delivery infrastructure is simultaneously managing a 100% unexpected volume spike.
The correct response to a detected accidental re-send: stop injection within seconds of detection. The faster the injection is stopped, the fewer duplicates are sent and the lower the complaint rate impact. In MailWizz, campaign pause takes effect within seconds of clicking Pause — the injected but undelivered messages remain in the PowerMTA queue, but no new messages are injected. The messages already in the queue for delivery cannot be recalled from ISPs that have accepted them, but they can be dequeued from PowerMTA before delivery if the queue depth is caught quickly enough.
After stopping injection, the queue management decision: should the already-queued duplicate messages be allowed to deliver, or should they be removed from the queue? If the number of queued duplicates is small (under 10,000 messages) and removing them from the PowerMTA queue is more disruptive than letting them deliver, the correct choice is usually to allow delivery and prepare a follow-up apology communication. If the queue contains hundreds of thousands of duplicates, the operator must weigh the complaint rate impact of delivering duplicates against the operational complexity of removing messages from the active queue — PowerMTA supports queue management through its management API and web interface, but removing messages at scale requires careful execution.
The post-incident response: monitor complaint rates for 48 hours after the accidental re-send; expect elevated FBL complaint volume from annoyed recipients; check Postmaster Tools spam rate for spike; prepare a communication to the list apologising for the duplicate and acknowledging the error. The apology communication should be sent through the regular channels without adding further delivery pressure to a pool that is likely still processing elevated complaint signals.
Volume Spike Impact on Reputation: Quantifying the Cost
The reputation cost of a volume spike depends on the list quality used during the spike and the complaint rate it generates. A spike that sends to the programme's highest-engagement contacts — even at 5× normal volume — generates positive engagement signals at increased rate and has minimal negative reputation impact. A spike that sends to lower-engagement or unvalidated contacts at 5× normal volume generates complaint rates and bounce rates at 5× normal volume, accelerating reputation signal accumulation proportionally.
For this reason, the list quality decision for spike sends is the most important deliverability management decision associated with volume spikes. The standard recommendation for planned spike events: restrict the spike send to the 60-day engaged segment (contacts who have opened or clicked in the past 60 days). This segment has the lowest complaint propensity, the highest engagement signals, and produces the most positive reputation signals per message at spike volume. Including lower-engagement contacts in the spike send adds marginal revenue but disproportionate reputation risk.
The revenue calculation: a 60-day engaged segment represents approximately 40–60% of the total list but approximately 80–90% of email-attributed revenue, because engagement rates and conversion rates are vastly higher for this segment than for the 61–180 day segment. Excluding the lower-engagement segment from the spike send loses perhaps 5–8% of total campaign revenue while avoiding the complaint rate surge that could require 4–8 weeks of reputation recovery. The revenue preserved through reputation protection consistently exceeds the marginal revenue from including the lower-engagement segment in the spike.
Building Spike Resilience into Infrastructure Architecture
The most effective spike response is an infrastructure architecture that absorbs spikes without requiring operator intervention. The architectural elements that provide spike resilience: a warm reserve IP pool (IPs maintained at reduced volume that can be immediately promoted to full sending during spikes without additional warmup); a queue management configuration with sufficient queue-life settings that spike messages are retained long enough to deliver after the spike throughput constraint resolves; and monitoring automation that detects queue growth and alerts the operator within 15 minutes of a spike beginning.
The warm reserve IP pool is the most impactful architectural element for spike resilience. When a spike occurs and the current pool's throughput is insufficient, activating the warm reserve IPs immediately expands the pool's delivery capacity without the 6–8 week warmup that new IPs would require. The reserve IPs' warming investment — made during normal operations at 5–10% of their capacity — pays off immediately during spike events by providing instant additional throughput.
For programmes with predictable annual spike patterns (Black Friday, seasonal promotions, annual renewal campaigns), the warm reserve investment is straightforward to justify: the reserve IPs are warmed each year starting 8 weeks before the spike, used at full capacity during the spike, and then maintained at reduced volume through the remainder of the year. For programmes with unpredictable spikes, maintaining a permanent 1–2 IP warm reserve provides the resilience buffer that turns an unplanned spike from a crisis into a managed throughput expansion.
Infrastructure that is designed for spike resilience operates differently from infrastructure designed for stable volume. The distinction is not in the configuration complexity — it is in the operational intentionality: knowing which IPs are in reserve, how quickly they can be activated, what their current reputation status is, and what list quality should be used to warm them. Operators who maintain this awareness consistently handle spike events more smoothly than those who discover their infrastructure's constraints only at the moment the spike occurs.
Communication During and After a Spike Incident
When a volume spike produces a significant delivery incident — a retry storm, a DNSBL listing triggered by elevated complaint rates, or a Postmaster Tools domain reputation decline — internal communication and, in some cases, ISP postmaster communication are part of the response.
Internal communication: the email marketing team that scheduled the campaign (or caused the accidental re-send) needs to understand what happened and why the infrastructure responded as it did. The technical explanation — "we exceeded our sustainable delivery rate, ISPs throttled us, and the queue accumulated" — needs to be translated into business implications: "campaign delivery extended by 4 hours, inbox placement may be affected for 2–3 weeks." This translation is the infrastructure operator's responsibility, and it is most effective when delivered with specific data (accounting log deferral rates, Postmaster Tools spam rate spike) rather than general descriptions.
Postmaster communication: For severe spikes that produce DNSBL listings or significant reputation impacts, proactive communication with ISP postmaster teams can accelerate recovery. Microsoft's SNDS portal and Gmail's Postmaster Tools do not provide direct postmaster contact channels for general deliverability questions, but both have documented processes for addressing specific blocking or reputation issues. Barracuda provides a self-service delist form; Spamhaus provides a removal request process. Initiating these contacts with documentation of what caused the spike, what actions were taken to stop it, and what infrastructure changes have been made to prevent recurrence produces better outcomes than waiting for ISP-side conditions to resolve without communication.
Volume spike incidents are learning opportunities as much as operational challenges. The post-incident review — what triggered the spike, how quickly it was detected, what response actions were taken and in what sequence, what the outcome was — produces the institutional knowledge that improves future spike response. Programmes that conduct and document post-incident reviews after significant delivery events consistently improve their spike response capability over time, reducing both the frequency and severity of future incidents. The documentation of what worked and what didn't, maintained in a searchable incident log, is the institutional memory that transforms individual incidents into organisational capability improvement.
Volume spikes are an inherent feature of email programme operations, not an anomaly that can be eliminated. What distinguishes well-managed programmes is not the absence of spikes but the quality and speed of the infrastructure response when spikes occur — automatic mechanisms that prevent minor spikes from becoming incidents, operator awareness that catches developing incidents quickly, and documented response protocols that provide clear guidance under the time pressure that incident response involves. These capabilities are built during normal operations, not during the spike itself, which is why the infrastructure architecture and operational protocols described in this note represent standing investments rather than reactive measures.
The Rate-Limit Negotiation with ISPs: Understanding Why Spikes Are Throttled
Understanding why ISPs throttle volume spikes — not just that they do — provides the mental model that makes correct spike response intuitive rather than counter-intuitive. ISPs set per-sender rate limits based on the sender's reputation and historical sending patterns. These limits reflect the ISP's assessment of how much email from this sender their users actually want to receive per unit time. A sender with 50,000 Gmail recipients and a 30% open rate has demonstrated that approximately 15,000 of its Gmail recipients actively engage with each send. The Gmail rate limit for this sender calibrates to a volume that can be accepted and processed without overloading Gmail's inbox management for this sender's recipients.
A volume spike that suddenly sends 200,000 messages to Gmail from a pool that has established rate limits appropriate for 50,000 is not just a throughput problem — it is a mismatch between the established reputation signal (appropriate for 50,000 messages) and the actual volume (200,000 messages). Gmail's throttle is a signal that the established rate limit applies until the sender's reputation signals update to reflect the higher volume. The correct response to the throttle is to accept the rate limit, deliver within it over a longer window, and build the volume history at the higher rate that will eventually produce a higher rate limit. Attempting to circumvent the throttle through additional connections accelerates the reputation damage by generating behaviour patterns associated with spam infrastructure.
This is the fundamental insight behind the "don't increase connections, don't shorten retries" guidance for spike response: these actions are attempting to force a higher throughput rate than the reputation-based rate limit allows, which the ISP correctly interprets as non-compliant sending behaviour. The reputation-building approach — deliver at the allowed rate, generate positive engagement signals at higher volume, allow the rate limit to increase as the reputation history justifies it — is slower but produces durable throughput increases rather than temporary access followed by escalating throttling.
Infrastructure Assessment
Our managed infrastructure includes volume spike response protocols — real-time queue depth monitoring, automated alerts at threshold crossings, and documented intervention procedures. Planned spike events include pre-event infrastructure preparation and dedicated monitoring during the send window. Request assessment →