Infrastructure Changes to Make Before a Major Deliverability Event

• February 2022
• Engineering Memo · External Release

A major deliverability event — a product launch campaign to the full list, a reactivation campaign to dormant contacts, a major list acquisition that doubles sending volume — is the moment when email infrastructure is under maximum stress and when delivery failures are most commercially consequential. Operators who prepare infrastructure adequately in advance consistently outperform those who initiate preparation in the days before the event. This note documents the infrastructure preparation checklist and the timing requirements for each step.

The 8-Week Preparation Window

Eight weeks before a major sending event is the outer boundary for beginning infrastructure preparation. Several preparation steps have irreducible time requirements — IP warming cannot be compressed, DNS propagation takes time, and reputation signals need time to accumulate. Attempting to compress these steps produces either incomplete preparation or the specific problems (retry storms, throttling from volume spikes) that preparation is designed to prevent.

W-8: IP Provisioning and Warmup Initiation

If the event requires additional IP capacity — a volume 2× or more above the current pool's sustainable throughput — provisioning must begin 8 weeks before the event. This is the minimum warmup period for IPs to reach sufficient reputation to handle the event's volume without severe ISP throttling. The provisioning checklist at W-8:

Provision the additional IPs. Verify PTR records are set and FCrDNS resolves correctly. Check the new IPs against Spamhaus ZEN and Barracuda before any sends — if any IP is listed, request a replacement. Register the new IPs with Gmail Postmaster Tools. Add the new IP addresses to the SPF record and verify SPF lookup count is still within 10. Publish DKIM public keys for the new virtual MTAs.

Begin the warmup schedule on day 1 of W-8 with the highest-engagement segment of the list. Follow the standard warmup ramp — starting at 2,000–5,000 messages per day and increasing 50–100% per week as delivery rate data confirms the IP is performing at the current volume. Document the per-IP delivery rate at Gmail and Yahoo for each warmup week as baseline data for the event-period monitoring.

W-6 to W-5: Authentication and Configuration Audit

Six weeks before the event, conduct a full authentication audit: SPF lookup count verification, DKIM key validity for all active selectors, DMARC pass rate from the past 30 days of aggregate reports, FCrDNS verification for all sending IPs (including newly provisioned ones). Any authentication gaps found at W-6 have adequate time to be resolved and propagated before the event. Authentication gaps found at W-2 may not propagate in time, leaving the event to proceed with authentication failures.

PowerMTA configuration audit at W-5: review all domain blocks for the major ISPs that will receive the event volume. Verify retry-after intervals are using exponential backoff. Verify max-smtp-out limits are set appropriately for each ISP. If the event involves higher-than-normal volume to specific ISPs (a product launch targeted at US consumers will be heavily Gmail and Yahoo), confirm the domain blocks for those ISPs have appropriate connection limits for the expected volume. Add any missing ISP domain blocks for ISPs that represent a significant portion of the event's target audience but don't currently have specific domain blocks.

Check the MailWizz campaign configuration for the event: delivery server assignment (is the event campaign assigned to the correct pool?), sending speed settings (does the sending speed limit align with the pool's sustainable throughput?), bounce server configuration (is the bounce server IMAP connection functional?), and unsubscribe configuration (is the unsubscribe link functional and pointing to the correct endpoint?).

W-4 to W-2: List Hygiene and Segmentation Preparation

Four weeks before the event is the right timing for the pre-event list hygiene pass. Earlier is impractical because contacts continue to become invalid between the hygiene pass and the event; closer to the event risks not completing the hygiene work before the event date.

The pre-event list hygiene checklist: run the event's target list through the global suppression list and remove any addresses that have been suppressed since the last send to this segment. Check the hard bounce rate from the last 3 campaigns to this segment — if it's above 0.3%, run a validation pass on the segment before the event. Review the engagement age distribution of the event's target segment: if more than 20% of the segment has not opened or clicked in 90+ days, reconsider whether the full segment is appropriate for the event or whether the lower-engagement cohort should be excluded from the event campaign and sent a separate, more conservative re-engagement campaign instead.

If the event involves a new list acquisition (contacts acquired specifically for this event through a list purchase, co-registration, or partner data share), quarantine the acquired list for a validation and test send phase before the event. Send to a random 5% sample of the acquired list first, measure the bounce rate and complaint rate in the 48 hours after the test send, and make the decision about the full acquired list based on this sample data. Acquired lists that produce more than 1% bounce rate or 0.08% complaint rate in the test send should not be included in the main event campaign without a remediation pass.

W-2: Monitoring Infrastructure Ready

Two weeks before the event, confirm the monitoring infrastructure is configured and operational. The monitoring checklist at W-2:

DNSBL monitoring is running for all sending IPs with automated alerting configured. Postmaster Tools is registered and displaying data for all sending domains and IPs. SNDS is registered for all sending IPs. FBL complaint processing is running and complaint rates are at baseline levels. The accounting log monitoring dashboard is showing current data and alert thresholds are configured for the event's expected volume (adjust alert thresholds upward if the event volume significantly exceeds normal — a 10% deferral rate during a volume spike may be normal; alerting at 5% would produce false positives).

Document the current baseline metrics that will be compared against during the event: current Gmail domain reputation tier, current spam rate (7-day average), SNDS status for all IPs, hard bounce rate from the last 3 campaigns, FBL complaint rate from the last 3 campaigns. These baseline values are the reference point for interpreting event-period metrics. A 0.06% complaint rate during the event is concerning if the baseline was 0.03%; it is normal if the baseline was 0.05%.

W-1: Final Verification and Go/No-Go Decision

One week before the event, conduct a final verification run: send a full test campaign — using real event content, to the real event list segment (or a representative 1% sample) — through the production infrastructure. Retrieve test messages from Gmail and Yahoo test inboxes and verify authentication headers (dkim=pass, spf=pass, dmarc=pass). Verify List-Unsubscribe is present and functional. Verify physical address and unsubscribe link are in the footer. Check that the sending statistics from the test campaign show normal delivery rates at both Gmail and Yahoo.

The go/no-go decision at W-1: if all of the following are true, the event is cleared to proceed: all new IPs are showing Medium or High reputation in Postmaster Tools after 7 weeks of warmup; authentication audit was completed at W-6 with no unresolved issues; list hygiene pass completed at W-4 with event segment bounce rate below 0.3% on last 3 campaigns; test send at W-1 showed dkim=pass and spf=pass with normal delivery rates. If any of these conditions is not met, the event should be delayed until the condition is resolved, rather than proceeding with known infrastructure gaps.

Event-Day Operations

On the day of the event, the operator should designate someone specifically for infrastructure monitoring during the injection and delivery window. This person is not doing other tasks — they are watching the accounting log dashboard, Postmaster Tools (checking every 30 minutes during the send), DNSBL status, and the FBL complaint queue. The monitoring cadence during a major send is more frequent than the daily standard: check every 15–30 minutes during active injection, every hour for 4 hours after injection completes, and daily for 3 days post-event.

The event-day response protocol for common incidents: DNSBL listing during injection — pause injection from the affected IP immediately, re-route through other pool IPs, initiate delisting while the send continues through other IPs; sudden deferral rate spike above 25% at a major ISP — reduce max-smtp-out for that ISP's domain block, investigate the specific SMTP response codes, check whether a reputation event or policy change is causing the spike; FBL complaint rate spike above 0.07% — investigate which list segment is driving complaints, consider pausing the segment and continuing the event with the lower-complaint segments only.

Post-event debrief: within 48 hours of the event send completing, document the event metrics (delivery rate, deferral rate by ISP, hard bounce rate, FBL complaint rate, Postmaster Tools domain reputation tier before and after) and compare to the pre-event baseline. Were there any infrastructure incidents? What caused them? What would have prevented them? Update the preparation checklist with lessons learned. This post-event documentation is the institutional memory that makes the next major event's preparation better than this one.

Infrastructure preparation for major deliverability events is a planning discipline that separates programmes that execute major sends smoothly from those that experience preventable delivery incidents during their most commercially important campaigns. The 8-week timeline and the weekly preparation checklist are not bureaucratic overhead — they are the sequenced technical requirements for event-ready infrastructure, presented as a calendar because their timing is as important as their content. The preparation cannot be compressed without accepting specific risks; it can be executed efficiently within the required timeline with appropriate planning and team coordination.

Why Most Event Preparation Fails: The Compression Trap

The most common failure mode in major event preparation is compression — beginning preparation too late and attempting to fit the full checklist into a shorter window. Compression fails for two structural reasons: IP warming cannot be accelerated without reputational consequences, and DNS changes have propagation delays that cannot be shortened. A programme that begins IP warmup at W-3 instead of W-8 either sends the event from insufficiently warmed IPs (risking throttling and poor inbox placement at the worst possible moment) or delays the event until warmup is complete.

The compression trap often begins with a planning decision — "we'll start preparing three weeks out" — that doesn't account for the specific technical requirements of each preparation step. The preparation steps are not arbitrary; they exist because specific technical constraints require specific lead times. Authentication changes need time to propagate through DNS resolvers (up to 48 hours). IP warming needs time to accumulate reputation signals in ISP models (typically 4–8 weeks for a meaningful reputation level). List hygiene needs time to run the reengagement campaign, wait for responses, and update the suppression list before the event send.

The solution is planning backwards from the event date: place the event on the calendar, then mark W-8, W-6, W-5, W-4, W-2, and W-1 as specific action dates with assigned owners and completion criteria. This makes the preparation timeline explicit and reveals immediately whether the current date is within the W-8 window. If the event is less than 8 weeks away and the checklist has not been started, escalation to leadership is required to either extend the timeline or accept specific risks from compressed preparation.

The Reactivation Campaign: A Special Case

Reactivation campaigns — sending to dormant contacts who have not received email in 6+ months — have specific infrastructure requirements that differ from standard campaigns to the active list. Dormant contacts have higher rates of invalid addresses (addresses become invalid during dormancy), higher complaint rates (contacts who haven't received email in months may not recognise the sender), and lower engagement rates (which generate weaker positive reputation signals). These characteristics require that reactivation campaigns route through infrastructure specifically configured to contain their reputation impact.

The recommended infrastructure approach for reactivation campaigns: use a separate, isolated IP pool for the reactivation send rather than the primary promotional pool. This prevents the reactivation campaign's elevated bounce rates and complaint rates from contaminating the primary pool's reputation. The isolated pool should be warmed using a sample of the dormant list in the weeks before the full reactivation send — this warmup validates the quality of the dormant list before committing the full volume to the isolated pool.

Volume segmentation within the reactivation campaign: send to the most recently dormant contacts first (those who have not engaged in 6–9 months rather than those inactive for 18+ months). The recently dormant segment has better address validity and higher engagement probability than the very long-dormant segment. Monitor bounce rates and complaint rates from the first segment before proceeding to the next. If the first segment's metrics are acceptable (bounce rate under 0.5%, complaint rate under 0.05%), proceed to the next segment. If they are elevated, pause and investigate before proceeding.

Post-reactivation hygiene: after the reactivation campaign completes, immediately run the full bounce and complaint output through the global suppression list. The reactivation campaign will identify addresses that have become invalid during dormancy — these must be suppressed before any subsequent campaign inadvertently sends to them. Similarly, contacts who complain during the reactivation campaign have clearly not re-engaged and should be permanently suppressed rather than included in subsequent campaigns targeting the same dormant segment.

Seasonal Volume Events: Black Friday, Cyber Monday, and Holiday Campaigns

For e-commerce programmes, the October–December peak season represents the most commercially important sending period of the year and the period of highest sending volume. Infrastructure preparation for this period requires planning beginning in August — the 8-week preparation window places the latest acceptable start date for Black Friday (the last Friday in November) in early October.

The seasonal volume challenge: sending volume during the October–December period may be 2–5× normal monthly volume, concentrated into weeks rather than distributed across months. The additional IP capacity required to handle peak-season volume must be provisioned and warmed before the season begins — not when the first high-volume campaign is ready to send. Warm IPs provisioned in October support the November and December peak campaigns with 6–8 weeks of warmup behind them.

The list hygiene consideration for seasonal campaigns is particularly important because many e-commerce programmes add contacts throughout the year from customers who purchase but may not engage with marketing email regularly. The October list hygiene pass — removing dormant contacts and validating new contacts acquired since the last major clean — ensures that the peak-season campaigns send to the highest-quality slice of the list rather than the full accumulated database including low-engagement cohorts that will generate complaint rates during the most commercially sensitive campaigns of the year.

Seasonal preparation also requires coordinating with content and marketing teams well in advance — the campaign content for Black Friday and Cyber Monday events should be developed, tested, and approved before the infrastructure preparation is complete. A fully prepared infrastructure waiting for campaign content approval in the week before Black Friday is a timing failure on the content side that reduces the value of the infrastructure preparation. Aligning infrastructure preparation timelines with content development timelines requires cross-functional coordination that is most effective when the infrastructure preparation calendar is shared with the marketing team at the beginning of the preparation window, not after it completes.

When to Call Off or Delay a Major Send

The go/no-go assessment at W-1 should be a genuine decision point, not a formality. The conditions that should trigger a delay or scope reduction of the planned event send:

Any new Spamhaus listing on a primary sending IP that has not been resolved before the planned send date. Authentication failures (DMARC pass rate below 95%) that have not been diagnosed and resolved. Hard bounce rate from the pre-event test send above 1% (indicating a list quality problem that will generate significant negative signals during the event). Gmail domain reputation that has declined since the preparation began and is now at Medium or below (suggesting the warmup or recent campaign practices have damaged reputation rather than built it). FBL complaint rates in the week before the event that are significantly above baseline (suggesting a recent campaign has generated elevated complaints that will compound during the event).

Any of these conditions individually may not be disqualifying — context matters. A minor reputation softening in a programme with strong historical High reputation may recover quickly. A new DNSBL listing that is resolved within hours may not affect the send. The W-1 assessment is a judgment call that weighs the infrastructure condition against the commercial urgency of the event. What the assessment must not be is a rubber stamp that proceeds regardless of the infrastructure condition because the marketing calendar is fixed and the campaign is already approved.

The commercial cost of proceeding with a compromised infrastructure — poor inbox placement during the event's send window, elevated complaint rates that damage domain reputation for weeks after the event — consistently exceeds the cost of a 1–2 week delay to resolve the infrastructure issue. Making this case to marketing and leadership requires the specific data that the W-1 assessment provides: "domain reputation is at Medium rather than the expected High, which will produce approximately X percentage point lower inbox placement, reducing event revenue by approximately €Y." Concrete numbers make the delay case more persuasive than general statements about infrastructure readiness.

The infrastructure preparation framework in this note converts major deliverability events from stressful last-minute scrambles into planned, structured operations. The investment in 8 weeks of preparation produces events that run through their delivery window with controlled metrics and manageable incidents — if they occur at all. The alternative is discovering infrastructure gaps during the event itself, when the cost of every delayed message and every spam-folder routing is measured in real-time commercial loss rather than a line item in a preparation budget. Infrastructure preparation is not overhead; it is the difference between an event that performs as planned and one that underperforms its commercial potential at the moment when that performance matters most.