French Lead Generation Agency — Cold Email Infrastructure Isolation and Reputation Recovery

A Paris-based B2B lead generation agency ran cold outreach campaigns on behalf of 14 SaaS clients across Europe. They were sending approximately 400,000 cold emails per month alongside 2 million permission-based marketing emails for the same clients — all through the same IP pool.

In October 2023, Gmail began blocking the shared pool entirely. Cold outreach complaint rates — 1.2–1.8% per campaign — had contaminated the reputation of the IPs also used for warm marketing audiences. Clients began losing revenue from disrupted marketing campaigns that had nothing to do with cold outreach.

The complaint rate data was clear: cold outreach to non-opt-in prospects was generating 14x the complaint rate of warm marketing campaigns. The fundamental problem was architectural — there was no mechanism to contain the reputation consequences of cold outreach to a dedicated pool.

Secondary problems included no DMARC enforcement (p=none with misaligned domains) and sending cold email at the same hourly rate as warm email, which ISPs interpreted as a single high-volume sending pattern rather than distinct sending behaviors.

The solution required complete isolation not just between cold and warm traffic, but between different client accounts within each category. A reputation event from one client's cold campaign must not affect any other client's traffic under any circumstances.

Cold email is also sent at a deliberately lower rate per IP — matching the behavioral fingerprint that ISPs associate with individual sales rep outreach rather than bulk sending. This reduces the ISP signal similarity between cold campaigns and spam.

Cold email infrastructure requires more intensive ongoing monitoring than warm marketing infrastructure because the complaint rate tolerance is lower and the signal-to-noise in blacklist events is higher.

• Daily automated blacklist check across all 16 cold IPs (Spamhaus SBL, XBL, Barracuda, SpamCop)
• Per-campaign complaint rate monitoring via Google Postmaster Tools API — automatic campaign hold if rate exceeds 0.08%
• ISP deferral rate alert at 8% — any cold IP generating sustained deferrals above 8% triggers automatic hold and investigation
• Weekly cold email list quality review — bounce rate analysis per client to identify list quality degradation

Technical Assessment: Infrastructure Layers Examined

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.

Infrastructure Rebuild: Configuration Decisions

IP Pool Architecture

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.

PowerMTA Domain Block Configuration

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.

Authentication Upgrade

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.

Operational Monitoring: What Changed Permanently

The 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.