Send-Time Distribution and ISP Acceptance Rate Optimisation

  • March 2022
  • Engineering Memo · External Release

Most email programmes think about send time in terms of recipient engagement: which day and hour produces the best open rate? This engagement-focused perspective ignores a second, operationally important dimension of send timing: how the distribution of sends across the delivery window interacts with ISP rate limits, queue depth management, and acceptance rate patterns. Send-time distribution affects not just when recipients see the message, but whether and how quickly it is delivered at all.

This note documents the relationship between send-time distribution and ISP acceptance rates, the queue dynamics that concentrated send-time distributions produce, and the configuration approaches that allow programmes to achieve both business-optimal send timing and infrastructure-optimal delivery performance.

The Queue Depth Problem with Concentrated Send Windows

When a marketing platform injects an entire campaign's message volume into the MTA within a few minutes — a common behaviour for "send now" campaign execution — the MTA's queue for each major ISP destination receives the full campaign volume simultaneously. For a 500,000-message campaign to a list with 40% Gmail recipients, this means 200,000 messages entering the Gmail destination queue within 5 minutes of campaign send.

PowerMTA's per-ISP connection limits then determine how quickly this queue can be delivered. With a Gmail domain block configuration of 20 concurrent connections, each delivering one message every 2 seconds, the theoretical maximum delivery rate to Gmail is 600 messages per minute. At that rate, 200,000 messages require approximately 333 minutes — 5.5 hours — to deliver. If the campaign window requires delivery within 2 hours for time-sensitive content (a flash sale, a time-limited offer), concentrated queue loading produces a structural delivery timeline problem regardless of IP reputation or list quality.

This is the queue depth problem with concentrated send windows: perfectly good infrastructure with excellent reputation can still fail to deliver a time-sensitive campaign within the required window if the send distribution creates queue depth that exceeds the connection capacity to drain it within the required timeframe. The solution is send-time distribution — spreading injection across the delivery window to keep queue depth manageable rather than creating a spike that must drain within the ISP rate limit ceiling.

Figure 1 — Concentrated vs Distributed Send: Queue Depth and Delivery Rate

Concentrated Send (all at once) 200K T+0 5.5hr delivery window Queue drains at ISP rate limit Distributed Send (over 2h) Queue depth manageable throughout Delivery completes on time

ISP Acceptance Rate Patterns by Time of Day

ISP acceptance rates — the proportion of SMTP connections that result in 250 OK delivery rather than a 4xx deferral — are not constant across the day. Most major consumer ISPs show lower acceptance rates during their peak incoming mail processing windows (typically 08:00–10:00 local time in each ISP's primary geographic area) and higher acceptance rates during off-peak periods (evenings and early mornings). This pattern reflects the queueing theory principle: when many senders are competing for the same ISP's SMTP connection capacity simultaneously, the rejection and throttle response rate increases as the ISP's processing systems approach capacity.

The practical implication: a campaign sent at 09:00 EST to a list with significant US-based Outlook recipients may encounter higher deferral rates than the same campaign sent at 07:00 EST, because 09:00 EST is peak incoming volume for US-based ISPs while 07:00 EST is pre-peak. The accounting log will show this as a higher 4xx response rate from Outlook during the 09:00 window and a lower 4xx response rate at 07:00 — same infrastructure, same list, different acceptance rate due to ISP load patterns.

Exploiting ISP acceptance rate patterns: analyse the accounting log to identify, for each major ISP destination, the hours of day with the lowest deferral rates over the previous 30 days. This per-ISP timing data provides an evidence-based foundation for send-time decisions that accounts for both engagement optimisation (the marketing team's preference) and delivery performance optimisation (the infrastructure team's preference). The optimal send time is the overlap between high-engagement hours and low-deferral hours — which varies by ISP and requires accounting log analysis to identify rather than generic best-practice rules.

Configuring Send-Time Distribution in PowerMTA

PowerMTA does not directly control send-time distribution — that is a function of when the sending application injects messages. However, PowerMTA's max-msg-rate setting in domain blocks provides an effective injection throttle that distributes delivery across a longer window even when the application injects all messages simultaneously. Setting max-msg-rate to a value that limits delivery to the planned completion rate forces the queue to drain gradually rather than as fast as connection limits allow.

For a campaign requiring delivery over 2 hours to 200,000 Gmail recipients: set max-msg-rate in the Gmail domain block to 1,667 messages per minute (200,000 / 120 minutes). PowerMTA will deliver at this rate regardless of how quickly the application injects messages, spreading the delivery window without requiring the application to manage injection timing. The queue depth remains predictable (messages enter faster than they deliver, building a manageable queue that drains at the configured rate), and the delivery completion time matches the planned window.

The max-msg-rate approach distributes delivery but does not address the reputation signal distribution concern: all 200,000 messages are in the queue from the start, and ISPs see the volume arriving over the rate-limited period. For large volume sends to ISPs with reputation-sensitive volume thresholds, additional injection-rate limiting in the sending application may be preferable to MTA-level rate limiting, because application-level control means messages enter the MTA queue more gradually rather than sitting in a large MTA queue waiting for the rate limiter.

Table 1 — ISP acceptance rate optimisation: configuration approaches

Approach Implementation Best for
MTA rate limiting (max-msg-rate)Domain block setting in PowerMTAConsistent delivery rate, easy to configure
Application injection schedulingMailWizz scheduled campaign deliveryReduces MTA queue depth; best overall
ISP-based send timingSchedule sends during ISP off-peak hoursMaximises acceptance rate per ISP
Segment-based distributionSend to ISP segments sequentiallyFine-grained control over per-ISP timing

Send-time distribution is one of the few deliverability levers that costs nothing to pull — it requires only configuration and scheduling discipline, not additional IP capacity, list quality investment, or infrastructure spending. The accounting log analysis that identifies per-ISP optimal send windows is a 30-minute analytical exercise on existing data. The configuration changes in PowerMTA that implement rate-limited delivery are a 15-minute configuration update. The delivery performance improvement from sending at ISP off-peak hours with managed queue depth is measurable in the next campaign's accounting log deferral rate comparison. Low cost, high impact, and directly measurable: send-time distribution optimisation belongs in every email programme's operational toolkit regardless of its scale or sophistication.

Per-ISP Timing Analysis from the Accounting Log

The accounting log contains the data needed to identify each ISP's optimal delivery window: the timestamp of each delivery attempt, the destination ISP (derived from the recipient domain MX record), and the SMTP response code (250 for successful delivery, 4xx for deferral). Aggregating this data by ISP and hour of day over a 30-day window reveals the per-ISP deferral rate pattern across the day.

The SQL query that produces this analysis: group delivery events by destination ISP and hour of delivery attempt, calculate the deferral rate (count of 4xx responses / total attempts) for each ISP-hour combination, and rank the hours by lowest deferral rate. The result is a per-ISP optimal send window table that shows, for example, that Gmail deferral rates are lowest between 04:00 and 07:00 EST, Yahoo deferral rates are lowest between 05:00 and 08:00 EST, and GMX deferral rates are lowest between 22:00 and 02:00 CET.

This per-ISP timing data is specific to the programme's sending IP pool and reputation level -- the optimal window for a High-reputation Gmail sender is different from the optimal window for a Medium-reputation sender, because High-reputation senders face less ISP throttling at peak hours. The accounting log analysis produces the correct optimal window for the programme's specific reputation level rather than a generic industry average that may not apply to its specific situation.

Running this analysis quarterly keeps the timing recommendations current. ISP load patterns can shift seasonally (more morning email during summer holiday periods, different patterns around major global events), and the optimal send window for the programme's specific reputation level may change as its reputation improves. The quarterly analysis is a 30-minute investment that keeps the send-time configuration current with current ISP behaviour patterns.

The Weekend vs Weekday Pattern

ISP acceptance rates show consistent weekday vs weekend patterns that are worth incorporating into campaign scheduling. Consumer ISPs (Gmail, Yahoo, Outlook for personal addresses) typically show lower deferral rates on weekends -- fewer senders competing for ISP connection capacity during Saturday and Sunday means more available capacity per sender. B2B-oriented ISPs (corporate Microsoft 365 domains, Google Workspace for business) show the opposite pattern: lower deferral rates on weekdays when corporate infrastructure is more actively managed and better resourced for incoming volume.

For programmes with mixed consumer and B2B recipient bases, the weekend vs weekday trade-off depends on the audience composition. A predominantly consumer list benefits from weekend sends for delivery efficiency; a predominantly B2B list delivers more efficiently on weekdays. The accounting log analysis reveals this pattern per programme: compare Saturday-Sunday deferral rates against Monday-Friday deferral rates for each major ISP destination, and the data shows whether the weekend timing advantage is real for the specific programme's sending pattern.

The business engagement case for weekend sends is separate from the delivery efficiency case: some programmes find that weekend email produces lower engagement rates because recipients are less likely to act on marketing email during personal time, even if the email is delivered efficiently. The delivery efficiency and engagement efficiency analyses may point to different optimal timing, requiring the programme to make a deliberate trade-off decision. Having both analyses -- from the accounting log for delivery efficiency and from the campaign analytics for engagement efficiency -- makes the trade-off decision evidence-based rather than instinctive.

Send-Time Distribution and Reputation Signal Concentration

There is a reputation signal dimension to send-time distribution beyond the queue depth and acceptance rate considerations. ISP spam filters look at the rate of complaint generation over time: a campaign that generates 500 complaints over 5 hours produces a lower peak complaint rate signal than the same campaign generating 500 complaints over 30 minutes. The concentrated send produces a complaint spike that may trigger automated spam filtering responses; the distributed send produces a complaint rate that is absorbed within the ISP's normal complaint processing without triggering spike-response actions.

This reputation signal concentration effect is most significant for campaigns that generate complaint rates near the ISP's automated response threshold (typically 0.08-0.10% for Gmail). A campaign at 0.07% complaint rate sent over 2 hours generates a complaint rate signal that stays just below the threshold throughout the send window. The same campaign sent in 15 minutes generates a complaint rate signal that spikes 8x higher for those 15 minutes, potentially triggering an automated spam filter response even though the overall complaint rate is identical. Distributed sending protects the programme from spike-response automated actions even when the aggregate complaint rate is within acceptable range.

The combination of queue depth management, ISP acceptance rate timing, and complaint rate signal smoothing makes send-time distribution one of the lowest-cost, highest-impact deliverability practices available. It requires no additional infrastructure, no list quality investment, and no authentication configuration changes -- only scheduling discipline and rate limiting configuration that prevents concentrated injection from producing the queue depth and signal spikes that harm delivery performance. For any programme sending campaigns of more than 50,000 messages, send-time distribution should be a default operational practice rather than an optional optimisation.

Seasonal and Event-Driven Timing Adjustments

Beyond daily and weekly patterns, ISP acceptance rates show seasonal and event-driven variations that affect send-time optimisation. During high-volume email periods — pre-Christmas retail season, major promotional events like Black Friday — ISP connection capacity is under higher competitive pressure from all senders simultaneously. The optimal send window during these periods may shift: early morning sends that avoided competition at 06:00 EST in September may encounter significantly more competition at the same time in November as retailers all attempt to capture the pre-market morning window.

Monitoring the accounting log deferral rate more frequently during high-volume periods — daily rather than quarterly analysis of per-ISP deferral rate by hour — allows the programme to detect when the previously optimal send window is no longer delivering the same acceptance rate improvement. When the data shows that the historically low-deferral morning window is now showing elevated deferral rates (because competition for that window has increased), adjusting to an even earlier window or a later off-peak window is the data-driven response.

Event-driven volume spikes also affect ISP capacity. A major news event that drives high email notification volume, a platform outage that triggers mass account notifications, or a financial event that produces high-volume bank and brokerage notifications can temporarily increase overall email volume to specific ISPs, raising deferral rates across all senders in that ISP's reception queue. These events are unpredictable and affect the optimal send window temporarily. The accounting log deferral rate data detects these temporary capacity constraints in real time, allowing the operator to decide whether to delay the campaign or accept the elevated deferral rate during the event period.

Send-time optimisation is not a set-and-forget configuration — it is a data-driven operational practice that requires periodic recalibration as ISP capacity patterns, competitive sending volumes, and seasonal factors change. The investment in maintaining this calibration — quarterly analysis reviews, increased monitoring during peak periods, and real-time deferral rate awareness during campaign sends — is modest relative to the delivery performance improvement it produces. Programmes that treat send-time distribution as an active operational lever rather than a static configuration consistently deliver campaigns more efficiently and with fewer ISP-triggered delays than those that ignore the timing dimension of deliverability management.

Integration with Campaign Planning

Send-time distribution optimisation is most effective when integrated into campaign planning from the beginning rather than applied as a last-minute adjustment. The campaign planning workflow that incorporates send-time optimisation: identify the delivery window the campaign requires (based on the content's time-sensitivity and the audience's expected engagement pattern), calculate the required injection rate based on campaign volume and the delivery window, compare the required injection rate against the ISP-specific optimal timing data, and schedule the campaign injection to begin at the optimal ISP timing for the primary ISP destinations.

For a campaign where the optimal delivery window conflicts with the business-preferred send time (the marketing team wants sends at 10am but the ISP data shows peak acceptance at 7am), the resolution requires an explicit trade-off decision: accept the 10am send time with elevated deferral rates, use the 7am send time for delivery efficiency, or use a split approach (inject starting at 7am so that Gmail recipients receive at 7am and the campaign continues delivering as more recipients' ISPs become available). The split approach is often the best compromise: it captures the early-morning delivery efficiency advantage while allowing recipients who are online later in the morning to receive the message during their active hours.

The campaign planning integration also considers the queue capacity constraint: if the programme's IP pool capacity (connection limit × delivery rate per connection × send window duration) is less than the campaign volume, the campaign cannot complete within the required window regardless of timing. This capacity calculation is a necessary prerequisite for any campaign that is time-sensitive. If the calculation reveals insufficient capacity, the solution is either IP pool expansion (8-10 weeks lead time), a longer delivery window (often acceptable for non-time-sensitive campaigns), or list segmentation (sending the campaign in two or more sends over multiple days).

Send-time distribution and ISP acceptance rate optimisation are dimensions of deliverability management that reward systematic attention but cost very little to implement well. The accounting log data provides the analytical foundation; the PowerMTA domain block configuration provides the rate limiting controls; the campaign scheduling system provides the injection timing control. All three are already present in a well-configured email infrastructure -- the optimisation is in using them together deliberately rather than accepting whatever timing and rate the default configuration produces. That deliberate, data-driven approach to send timing is what distinguishes operationally sophisticated email programmes from those that treat send-time as a fixed parameter rather than a configurable optimisation lever.

Measuring the Impact of Send-Time Optimisation

The impact of send-time optimisation is directly measurable from the accounting log: compare the per-ISP deferral rate and average delivery time for campaigns sent at the optimised time vs campaigns sent at non-optimised times. A before-and-after comparison across 10-20 campaigns shows whether the optimised timing produces lower deferral rates and faster completion of delivery, confirming that the optimisation is producing real performance improvement rather than theoretical improvement.

For programmes just beginning send-time optimisation, the A/B comparison approach: split the subscriber list into two equal segments (random selection), send to one segment at the historically optimal ISP timing and the other at the programme's previous default send time, and compare the delivery metrics for each segment from the accounting log. The comparison reveals the per-ISP deferral rate difference between the two timing approaches for the specific programme's IP pool and reputation level. If the optimised timing produces materially lower deferral rates (more than 2-3 percentage points at any major ISP), the optimisation is worth incorporating as the default send-time approach going forward.

The engagement impact of send-time changes should be measured simultaneously: do recipients who receive the message at the optimised delivery time engage at the same rate as those who receive at the traditional send time? This engagement comparison separates the delivery efficiency benefit (lower deferral rate, faster completion) from any engagement efficiency impact (recipients may engage differently based on when in their day they receive the message). If engagement is equivalent, the optimised timing is clearly better. If engagement is lower at the optimal delivery time, the trade-off between delivery efficiency and engagement efficiency requires an explicit programme-specific decision.

Send-time distribution is ultimately about respecting both the ISP's capacity constraints and the recipient's time. A campaign delivered at the ISP's lowest-deferral window arrives in the inbox efficiently; a campaign delivered when the recipient is most likely to engage produces the commercial outcome the campaign is intended to generate. Optimising both simultaneously -- through the accounting log analysis for ISP timing and the campaign analytics for engagement timing -- is the data-driven send-time management approach that consistently produces better delivery and engagement outcomes than relying on either dimension alone.

Infrastructure Assessment

Our managed infrastructure includes per-ISP send-time analysis from the accounting log, domain block max-msg-rate configuration calibrated to each programme's delivery window requirements, and campaign scheduling support through MailWizz's scheduled delivery feature. Request assessment →