A Zurich-based payment infrastructure company processing B2B payments across 18 European markets sent 2.4 million transactional emails per month: payment confirmations, failure notifications, 2FA codes for high-value transaction authentication, and compliance notifications required under PSD2.
The SLA requirement was strict: 2FA codes must reach the recipient within 60 seconds of the authentication request, or the transaction session expires and the user must restart the flow. Payment confirmation emails had a softer but still commercially important SLA: under 2 minutes from transaction completion to delivery.
On their existing commercial transactional email service, average delivery time was 2.4 minutes. 2FA codes were timing out at a rate of 3.8% — meaning one in twenty-six high-value authentication attempts failed to complete due to email delivery delay.
Infrastructure designThe dedicated transactional infrastructure was designed around three priority tiers with different queue characteristics:
The Swiss and EU financial services regulatory context required that all message content — including transactional email content containing personal financial data — be processed and transmitted within the EU/EEA. The dedicated infrastructure was deployed in a Frankfurt datacenter with ISO 27001 certification, satisfying data processing location requirements under GDPR and Swiss Federal Act on Data Protection (revFADP).
Post-migration: 2FA timeout rate dropped from 3.8% to 0.2%. Average delivery time for authentication codes: 22 seconds. Payment confirmations: 38 seconds average. Zero infrastructure downtime in the first 8 months of operation. The previous provider had experienced two incidents totalling 4 hours of degraded delivery in the same 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.
