A Milan-based digital publishing group had grown from a single Italian-language technology newsletter to a seven-edition operation publishing in Italian, French, German, Spanish, Portuguese, Polish, and Dutch. Total subscriber base: 1.9 million across the EU. The original infrastructure — a single shared ESP configured for the Italian audience — had been stretched to cover all seven editions with no architectural changes.
The result: French and German editions, whose audiences had different ISP distribution (higher proportion of GMX, T-Online, and Orange users) were routed through infrastructure optimised for Italian ISPs (Libero, Alice, Virgilio, TIM). Per-country inbox rates varied from 94% (Italy, native optimisation) to 58% (Germany, where ISP routing was entirely wrong for the audience).
ArchitectureThe dedicated infrastructure was designed with two layers of isolation: per-country IP routing (to ensure traffic to German ISPs came from IPs optimised for German ISPs) and per-edition DKIM keys (to ensure reputation was not shared between editions that might vary significantly in engagement quality).
The largest improvement was in Germany (58% → 91%) where the pre-existing routing had sent German ISP traffic through Italian-optimised IPs. German ISPs — particularly GMX, Web.de, and T-Online — apply aggressive throttling to new or unrecognised sending IPs. IPs with established reputation at German ISPs (built through correct country-targeted warming) receive significantly more favorable treatment.
Polish ISP inbox placement improved from 62% to 83%, the second-largest gain. Polish ISPs apply strict volume limits per connection and longer retry patience than Western European providers — configuration that the original single-configuration infrastructure could not accommodate per-country.
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 TeamContact the technical team to discuss your specific situation. We assess each environment individually before recommending an architecture.
