A Copenhagen-based fashion e-commerce retailer attempted to reactivate 420,000 lapsed subscribers — addresses that had not engaged in 12-24 months — with an aggressive three-email reactivation sequence. The sequence offered a 40% discount and was designed to generate immediate revenue from dormant addresses before suppressing them.
The campaign generated a 1.8% complaint rate at Gmail. Google Postmaster Tools showed domain reputation dropping from HIGH to MEDIUM within 24 hours of the first send, and to LOW within 72 hours. Subsequent sends to the active subscriber list — 180,000 fully engaged customers — saw inbox placement collapse from 88% to 19%.
Why the campaign failedThe 12-24 month inactivity cohort contained a significant proportion of addresses that had been converted to spam traps — addresses that ISPs recycle from abandoned accounts specifically to identify senders who do not honour engagement signals. Sending to spam traps triggers immediate reputation damage independent of complaint rates.
Additionally, recipients who had not engaged with the brand in 12-24 months had a much higher propensity to mark email as spam rather than unsubscribe — they often had no memory of the relationship or had actively forgotten about the brand.
RecoveryThe immediate response was complete suppression of all lapsed addresses. The structural response was implementing proper FBL (Feedback Loop) integration for all major mailbox providers, which had not been operational before the incident.
Gmail reputation recovered from LOW to MEDIUM at day 14, and from MEDIUM to HIGH at day 35. Inbox placement for the active subscriber list reached 86% at day 42 — approaching (but not yet at) the pre-incident level of 88%. Full recovery to pre-incident inbox rates was achieved at approximately 60 days.
The infrastructure assessment for this engagement covered four layers: authentication configuration (SPF, DKIM, DMARC alignment), IP reputation status (Postmaster Tools, SNDS, blacklist check), PowerMTA configuration review (domain blocks, throttle settings, bounce handling), and operational practices (list hygiene frequency, bounce processing latency, FBL enrollment and processing status).
Authentication issues were the highest-priority finding. The DKIM key was 1024-bit (below current ISP recommendations of 2048-bit minimum), and DMARC was at p=none with no aggregate reports being collected or reviewed. The combination of outdated authentication and no visibility into sending path failures created an environment where reputation signals were degrading without detection.
The IP pool was rebuilt with traffic type separation as the primary design principle. Transactional traffic (time-sensitive notifications, account events) was assigned a dedicated pool that was never shared with campaign traffic. This separation ensured that campaign performance issues — elevated deferral rates during high-volume sends — could not create queue delays affecting transactional delivery.
| Pool | Traffic Type | IPs | max-smtp-out | Protection Level |
|---|---|---|---|---|
| trans-pool | Transactional notifications | 2 | 10 per IP | Highest — never paused or degraded |
| campaign-pool | Marketing campaigns | 3-4 | 8 per IP | Standard — subject to reputation management |
| warming-pool | New IP warming | As needed | 2-3 per IP | Conservative — warming schedule only |
ISP-specific domain blocks were configured for each major destination: Gmail (max-smtp-out: 8, retry-after: 15m), Outlook (max-smtp-out: 5, retry-after: 20m), Yahoo (max-smtp-out: 6, retry-after: 15m), and ISP-specific configurations for European providers including GMX, Web.de, T-Online, and OVH. Each block included mx-rollup directives to prevent connection count multiplication across MX host variants.
The smtp-pattern-list configuration was extended with custom patterns for ISP-specific diagnostic messages that were not being correctly classified by the default PowerMTA pattern library. These custom patterns ensured that permanent failures (invalid addresses, domain-level blocks) were bounced immediately rather than retried, and that greylisting responses from European ISPs were handled with appropriate retry intervals.
DKIM keys were rotated to 2048-bit RSA on all sending domains. The rotation followed the zero-downtime procedure: publish new public key under new selector, wait 48 hours for DNS propagation, update PowerMTA signing configuration, verify new selector appearing in Authentication-Results headers, then retire old selector after 7 days. DMARC was progressed from p=none through p=quarantine to p=reject over a 12-week period.
Results After 90 DaysThe infrastructure changes produced immediate delivery improvement, but the operational changes — the monitoring discipline and response protocols — are what sustain that improvement over time. Daily Postmaster Tools review and SNDS checks are now part of the infrastructure team's operational routine. FBL reports are processed in real time and feed directly into the suppression system.
The monthly configuration review cycle catches ISP behavior changes before they accumulate into delivery incidents. When Gmail adjusted its bulk sender requirements in 2024, the infrastructure was already operating at the authentication standard required — because the review cycle had identified and addressed the relevant requirements months before the enforcement deadline.
The technical changes in this engagement were straightforward. The more significant work was establishing the monitoring discipline that prevents the gradual drift that caused the original problems — an infrastructure that meets today's ISP requirements but has no ongoing review process will fall behind those requirements within 12-18 months.
— Cloud Server for Email Infrastructure TeamThe infrastructure improvements achieved in this engagement represent a point-in-time improvement, not a permanent outcome. Email deliverability is an ongoing operational discipline — ISP filtering systems evolve, list composition changes with growth, and the configuration settings that are optimal today may need adjustment in six months. The monitoring and review processes established during this engagement are what sustain the improved performance over time.
Key ongoing practices established: daily Postmaster Tools and SNDS review integrated into the operations team's monitoring dashboard, real-time FBL complaint processing feeding directly into the suppression system, quarterly DKIM key rotation cadence, and monthly ISP-specific configuration review against current best practices. These practices take less time than a single delivery incident response — and they prevent the incidents.
One of the less-visible benefits of well-managed dedicated infrastructure is that it compounds over time. ISP reputation systems give weight to consistent historical behavior — a sender with 18 months of clean sending history recovers from a single incident faster than a sender with inconsistent history. The reputation capital built over time becomes a form of infrastructure resilience that is not visible in day-to-day metrics but matters significantly during incidents.
The infrastructure patterns in this case study recur across different sender types and volumes. A technical assessment identifies which apply to your environment and what the remediation sequence looks like for your specific configuration.
Contact the technical team to discuss your specific situation. We assess each environment individually before recommending an architecture.
