UK Fintech — Deliverability Recovery After Shared IP Blacklisting and DMARC Enforcement

A London-based fintech platform serving 1.2 million users across the UK and Western Europe suffered a complete delivery failure at Microsoft (Outlook, Hotmail, Live) and Yahoo in December 2023. The cause was a Spamhaus CSS listing on two of four shared IPs used by their ESP — IPs that the fintech company did not control and could not remediate.

For a fintech platform, email is not marketing — it is compliance infrastructure. Account alerts, transaction confirmations, fraud notifications, and regulatory communications were failing to deliver to any Microsoft or Yahoo mailbox. Regulatory exposure was immediate.

The immediate priority was restoring delivery for compliance-critical messages. This required bypassing the blocked shared infrastructure entirely while a permanent dedicated environment was provisioned.

1. Day 1–2: Emergency SMTP relay provisioning

   Provisioned 2 clean IPs on dedicated infrastructure, configured with full authentication (SPF, DKIM, DMARC p=quarantine). Transitioned critical compliance emails (transaction confirmations, fraud alerts) to the clean IPs within 48 hours.

2. Day 3–5: Microsoft Postmaster remediation

   Submitted Microsoft SNDS complaint and engaged with Microsoft Postmaster directly. Documented that the CSS listing was on co-tenant IPs and provided traffic segregation evidence. Microsoft lifted the block on the new dedicated IPs within 72 hours of enrollment.

3. Day 5–7: DMARC progression to enforcement

   Moved DMARC from p=none to p=quarantine. Monitored aggregate reports for 5 days to confirm no legitimate sources were failing alignment. Advanced to p=reject at Day 12.

4. Week 2–3: Full infrastructure migration

   Migrated all 6 million monthly messages to dedicated infrastructure across 6 IPs with traffic separation: 2 IPs for compliance/transactional, 4 IPs for account-based marketing.

Moving from p=none to p=reject in a regulated financial services environment required careful sequencing. A misconfigured DMARC enforcement that blocked legitimate email would compound the delivery problem rather than solve it.

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.