A Stockholm-based SaaS platform serving 180,000 business users across Northern Europe had accumulated four separate SMTP relay providers over five years of growth — each chosen reactively to solve a different problem: one for transactional email, one for marketing, one as a backup when the first blocked, and one for a German subsidiary with its own sending domain.
The result was a configuration that no single engineer fully understood. Bounce processing was inconsistent across providers. Authentication records were misaligned. When deliverability problems occurred, it was unclear which provider was responsible. Monthly infrastructure costs were high because all four providers were maintained simultaneously with no consolidation plan.
Problem diagnosisA structured deliverability audit across all four sending environments revealed:
The consolidation architecture used a single PowerMTA environment with three virtual-MTA pools:
Authentication was rebuilt from scratch: SPF reduced to a single include statement, DKIM implemented with 2048-bit keys on all three pools, DMARC upgraded from p=none to p=quarantine during migration and p=reject within 60 days of confirmed alignment.
Overall delivery rate improved from 78% (average across all four providers) to 94% on the consolidated infrastructure. The improvement was attributable primarily to correct authentication alignment and removal from shared IP pools. Per-ISP performance improved most significantly at Microsoft Outlook (71% → 91%) where the previously misconfigured DKIM had been causing soft rejections.
Monthly infrastructure cost reduced by 55% by eliminating three of the four commercial relay contracts. The fourth contract (the primary transactional provider) was terminated on completion of the 12-week warming period.
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.
