How a Paris-based B2B lead generation agency rebuilt its cold-and-warm email architecture into a four-pool isolation model — recovering from a 72-hour Gmail block, eliminating cross-client reputation contamination across a 14-client portfolio, and giving each client an attributable reputation profile of their own.
A Paris-based B2B lead generation agency operates cold outreach campaigns on behalf of 14 SaaS clients across France, the UK, the Nordics, and the DACH region. The agency's service model combines two distinct email operations under one roof: cold outreach to prospect lists provided or sourced for each client, and ongoing warm marketing to those clients' existing opt-in subscriber bases. By Q3 2023, the agency was sending approximately 400,000 cold emails per month alongside 2 million permission-based marketing emails for the same client roster — all running through the same shared IP pool inherited from a previous ESP relationship that the agency had never formally re-architected.
In October 2023, Gmail began blocking the shared pool entirely. Cold outreach complaint rates — averaging 1.2–1.8% per campaign across clients, with worst-case campaigns reaching 2.4% — had contaminated the reputation of the IPs also used for warm marketing audiences whose complaint rates were below 0.05%. For 72 hours, no message from any of the agency's 14 clients reached any Gmail inbox. The clients whose marketing was disrupted had no operational connection to the cold outreach activity that triggered the block; they were affected because their warm marketing shared infrastructure with someone else's cold campaigns. Several clients raised contractual concerns about being exposed to reputation risk from activity they did not control.
Presenting Problems
- Gmail block affecting all 8 IPs in the shared pool — zero delivery to Gmail for 72 hours, with subsequent partial recovery only after the contaminating cold campaigns were paused
- Cold outreach complaint rate at 1.4% average across all clients, well above Gmail's 0.1% threshold for sender reputation downgrade and 14× the warm-marketing baseline on the same pool
- No infrastructure separation between cold and warm traffic — reputation events from cold campaigns directly affected warm marketing delivery for clients with no involvement in cold outreach
- 14 clients affected by deliverability problems originating from other clients' cold outreach activity — a cross-tenant contamination pattern that the shared-pool architecture made structurally inevitable
- No per-client IP isolation within either traffic class — a Spamhaus listing on Client A's cold campaign affected Client B's deliverability across both cold and warm streams
- DMARC at p=none on all 14 client domains — no enforcement, no aggregate-report visibility into authentication failures, no protection during the reputation crisis
- Cold and warm traffic sent at the same per-IP hourly rate, producing a sending pattern that ISPs read as bulk sender behaviour rather than the individual-sales-rep pattern that low-volume cold outreach should mimic
- No automated blacklist monitoring on the cold IPs, where listing events are statistically more frequent and remediation timelines matter most
The complaint-rate data was unambiguous: cold outreach to non-opt-in prospects was generating 14× the complaint rate of warm marketing campaigns to the same clients' opt-in subscribers. This was not a content quality problem — the cold campaigns were professionally written, opt-out compliant, and following industry best practice for B2B outreach. It was a structural reality of the channel: even the best-executed cold outreach to a prospect who has no prior relationship with the sender will produce complaint rates an order of magnitude above warm marketing, because some recipients will mark unsolicited mail as spam regardless of how it is constructed.
The fundamental problem was architectural: there was no mechanism to contain the reputation consequences of cold outreach to a dedicated pool. A single client's cold campaign producing a 2% complaint rate degraded the reputation of every IP serving every other client's warm marketing. Secondary findings included DMARC at p=none across all 14 client domains (with misalignment patterns surfaced once aggregate-report processing was activated), and a sending-rate uniformity across cold and warm traffic that produced a behavioural fingerprint at receiving ISPs more characteristic of bulk-sender activity than of the legitimate-individual-outreach pattern that cold email at moderate scale should produce.
Average Complaint Rate by Traffic Type
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 — both because the operational consequence of cross-contamination was the original problem, and because the agency's contractual obligations to its clients required that each client's reputation be a function of that client's behaviour alone. The four-pool model (cold-isolated per client + warm-shared across clients on dedicated marketing IPs + transactional + warming) gave each client a sub-pool within the cold infrastructure, with no path by which one client's cold campaign behaviour could affect another client's cold or warm delivery.
Cold email is also sent at a deliberately lower rate per IP — matching the behavioural fingerprint that ISPs associate with individual sales-representative outreach rather than bulk sending. The 50 messages-per-hour ceiling per IP at Gmail produces a sending shape consistent with a single human or small team operating outreach manually, not with an automated bulk-marketing system. This reduces the ISP-side signal similarity between cold campaigns and the spam-operation patterns that aggressive filtering responds to.
Gmail Inbox Placement Rate — Cold vs Warm Traffic
Cold email infrastructure requires more intensive ongoing monitoring than warm marketing infrastructure because the complaint rate tolerance is lower, the signal-to-noise in blacklist events is higher, and the consequences of an unaddressed listing event compound faster on cold IPs than on warm.
- 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
(from blocked)
(unaffected by cold events)
contamination events
from each other
Technical Assessment: Infrastructure Layers Examined
The post-cutover assessment focused on the three layers that distinguish cold-email infrastructure from warm-marketing infrastructure: per-client reputation isolation, per-client authentication delegation, and the operational monitoring cadence that cold operations require but warm operations do not.
Per-Client Reputation Isolation Through Sub-Pools
Each of the 14 clients receives a dedicated sub-pool of cold-email IPs sized to that client's volume — typically 1 IP for clients sending under 5,000 cold messages per month, 2 IPs for clients in the 5,000–15,000 range, 3 IPs for the highest-volume clients above that threshold. Within each sub-pool, no other client's traffic is sent. A reputation event on Client A's cold pool affects only Client A's cold delivery; other clients' cold and warm streams are unaffected. The sub-pool architecture also makes per-client reputation attributable in DMARC aggregate reports and in Postmaster Tools data — the agency's operations team can identify which client's behaviour is producing reputation drift, which was operationally impossible under the shared-pool architecture.
Per-Client DKIM Delegation
Each client's domain has its own DKIM key under its own selector, signed by the agency's PowerMTA infrastructure. This means receiving ISPs evaluate each client's authentication independently — Client A's DKIM identity has its own reputation history at Gmail, separate from Client B's. The delegation also gives each client demonstrable control over their domain's DKIM configuration: clients can rotate keys at their own cadence if their security policy requires it, and the agency's signing infrastructure picks up the new keys without affecting other clients. Independent DKIM identity per client closes the last reputation-coupling vector that shared infrastructure would otherwise leave open.
Cold-Specific PowerMTA Domain Block Configuration
The cold pool's per-domain PowerMTA configuration is calibrated for the sending shape and ISP tolerance of cold outreach: very low max-smtp-out per IP (3 for Gmail, 2 for Outlook), low max-msg-rate (50/h Gmail, 30/h Outlook), longer retry intervals on deferrals (40m rather than the 15m used for warm sending), and stricter bounce-handling that suppresses any address producing a soft bounce on the second consecutive attempt rather than waiting for hard-bounce confirmation. These parameters would be inefficient for warm marketing — they would dramatically slow throughput — but they are precisely the parameters that produce the behavioural fingerprint cold email needs to maintain at receiving ISPs.
Infrastructure Rebuild: Configuration Decisions
Listener-based client routing as the agency-tenant boundary. Each of the 14 clients connects to the agency's PowerMTA infrastructure through a dedicated SMTP listener with credentials authorising only that client's pools. Client A's cold-outreach tooling cannot send through Client B's cold pool because the credentials it has do not authorize that. This enforces tenant isolation at the authentication layer rather than relying on application-level routing discipline; a misconfigured cold-outreach campaign on Client A cannot accidentally send through Client B's IPs because the architecture makes the cross-routing technically impossible.
Automated blacklist monitoring with auto-hold on detection. Each cold-pool IP is monitored continuously against the major DNSBL providers — Spamhaus SBL/XBL, Barracuda, SpamCop, Invaluement, SURBL. A new listing on any monitored DNSBL produces an immediate PowerMTA hold on the affected VMTA (the IP stops sending while remediation is investigated) and an alert to the agency's operations on-call. The auto-hold is conservative: most listings are short-lived false positives that resolve within hours, and resuming sending immediately on an IP that genuinely has a listing problem would compound the issue. The hold-and-investigate model has been triggered 23 times in the year following deployment; 19 were false-positive listings that resolved within 4 hours and 4 required active remediation including delisting requests.
Per-campaign complaint-rate enforcement at injection. Cold campaigns above 0.08% complaint rate (measured against Google Postmaster Tools API at 30-minute granularity) are automatically held — no further messages from that campaign send until the agency's deliverability operations team has reviewed the campaign's content, list source, and sending pattern. The 0.08% threshold is below Gmail's 0.1% reputation-affecting threshold, giving operations time to intervene before reputation damage is locked in. The auto-hold has fired 47 times in the post-deployment year; in 31 cases the campaign was paused permanently and the underlying list source flagged for review, and in 16 cases the campaign was allowed to continue after the spike was identified as a one-time artefact of a specific recipient cluster rather than a systemic issue.
Operational Monitoring: What Changed Permanently
Per-client deliverability dashboards and weekly reporting. Each of the 14 clients receives a weekly deliverability report covering their cold and warm streams independently: per-ISP placement rates, complaint rate trend, blacklist incidents (if any), and list-quality metrics. The reports surface client-specific behaviour to the client, giving them visibility into their own reputation as distinct from the agency's aggregate. This addressed a contractual concern that surfaced during the original incident: clients wanted to see their own reputation independently of any other client's contribution, and the per-client architecture made that visible for the first time.
List-source quality scoring per client. Cold campaign performance is segmented by list source — purchased lists from specific data brokers, scraped lists from specific public sources, list-rental from specific intermediaries. Sources whose lists consistently produce above-baseline complaint rates or above-baseline bounce rates are flagged in the agency's source registry and either deprecated entirely or required to undergo additional verification before subsequent use. The discipline that this enforces — measuring acquisition source quality before measuring campaign outcome — is the practice the agency had not had before the incident.
Quarterly client-portfolio reputation review. Across the full 14-client portfolio, the agency's operations team reviews quarterly which clients are operating within healthy cold-outreach parameters and which are at risk of producing pool-wide reputation issues. Clients trending toward problematic complaint rates receive proactive consultation on list quality, sending cadence, content adjustments, or — in the most extreme cases — recommendations to pause cold outreach pending list rebuild. The portfolio view makes pattern detection possible across clients that individual client review would miss; two specific list-broker sources were identified as contributing disproportionately to portfolio-wide complaint rates and were removed from the agency's approved-source list as a result.
"We had been operating cold and warm email on the same infrastructure because that was how the previous ESP arrangement was structured, and we had not questioned it. The Gmail block in October 2023 made it concrete that we were exposing every client to reputation risk from every other client's cold activity — a contractual problem we had not considered before it actually happened. The four-pool architecture means each client's reputation is now their own, attributable to their own behaviour, and the cross-contamination pattern that started this engagement cannot recur. The clients who renewed in the year following the migration cited the per-client isolation specifically as a factor in renewal."
— Director of Client Operations, French Lead Generation AgencyThe 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 TeamCold and warm email are not the same operational category with different content; they are different operational categories with structurally different complaint-rate profiles, sending-pattern requirements, and acceptable inbox-placement targets. Running them on the same infrastructure means the higher-complaint category sets the reputation ceiling for the lower-complaint one — the warm-marketing pool's reputation is constrained by the cold-pool's behaviour even when the warm pool's behaviour is impeccable. The architectural separation that resolved this engagement is not optional for any operator running both categories at meaningful scale; it is the baseline that allows each category to operate at its own optimum without contaminating the other.
For multi-client agency operations, the per-client sub-pool architecture extends the same principle one level deeper: each client's reputation should be a function of that client's behaviour alone, not of the aggregate behaviour of every client sharing the agency's infrastructure. Clients who renew with an agency operating shared infrastructure are accepting reputation risk from every other client of that agency without necessarily understanding it. The per-client isolation is not just an operational improvement — it is a contractual clarity improvement that aligns each client's exposure with their own behaviour rather than with their fellow clients'.