Five weeks. Three million emails per month. Schrems II compliant.

The customer is an FCA-regulated payments platform headquartered in London, providing card-acquiring and account-to-account transfer services across the UK and several European markets. The volume sits at roughly three million emails a month, split between transactional (card receipts, dispute notifications, fraud alerts, KYC reminders) and a smaller marketing programme directed at the platform's merchant base. We were contacted in February 2025 by the platform's CISO, after their internal Schrems II compliance review identified the existing email infrastructure as the largest unaddressed CLOUD Act exposure in the technology stack. The previous vendor was SendGrid. The contract was up for renewal in May 2025, which gave us a five-week window to complete the migration before the renewal forced either a one-year commitment to a US-domiciled processor or an ad-hoc fallback that the compliance team would not approve.

The compliance issue was clear. The technical situation under it was less clear and turned out to be the harder part of the engagement. The platform had been on SendGrid for six years. During those six years, the configuration had drifted in a way that nobody on the current team could fully reconstruct from documentation. There were three sending domains active. There was a fourth that DNS still pointed at SendGrid IPs, but no production code had referenced it for at least eighteen months. SPF records on two of the three active domains had grown past the 10-DNS-lookup limit specified in RFC 7208 section 4.6.4 and were silently failing for an unknown fraction of receivers. DKIM was correctly signing on transactional mail but not on the marketing programme. DMARC was published at p=none with no aggregate report destination configured, which meant the platform had no visibility into authentication failures.

The deliverability footprint was worse than the platform realised. The marketing programme had been getting roughly 78 percent inbox placement at Gmail according to the postmaster tools data we pulled in the first week of the engagement, with the remainder split between Promotions tab and outright spam folder. Outlook.com was running at 64 percent inbox. Yahoo had silently throttled the platform to 40 messages per minute on the primary IP three months earlier, after a complaint spike from a poorly-targeted re-engagement campaign. Apple iCloud Mail was bouncing about 6 percent of messages with 521 5.7.1 rejections that the platform had been treating as recipient-side problems but were actually originating from a DKIM key length issue (the marketing programme was still using a 1024-bit selector that some receivers had started rejecting in Q3 2024).

We mapped the migration as five weeks with explicit deliverables per week, and we missed the original timeline by four days. The critical path turned out to be DKIM key rotation, which we underestimated.

Weeks 1-2: Discovery and DKIM remediation. Week one was discovery and DNS audit. We catalogued every sending domain, every DKIM selector in production, every SPF include, every MTA-STS policy, every BIMI record. The fourth domain that nobody had referenced for eighteen months turned out to be sending roughly 80,000 messages a month from a customer support tool that had been provisioned by a since-departed engineer and never deprovisioned. We scoped that into the migration. Week two was DKIM remediation. We rotated all selectors to 2048-bit keys, published the new selectors alongside the old ones, and waited the recommended seven-day overlap before retiring the old keys. The marketing programme picked up the new selector immediately. The transactional programme had a hardcoded selector reference in a third-party templating service that nobody on the platform's engineering team knew about. That cost us three days of debugging and a 90-minute call with the templating vendor.

Weeks 3-4: IP warmup and cutover. Week three was the IP warmup. The platform's Schrems II compliance team required all production sending to move to dedicated IPs in our Slovenian PoP within the five-week window, with no fallback to the existing SendGrid pool. We allocated four IPs, two for transactional and two for marketing, and ran a 14-day warmup curve on each pair starting at 50 messages per day and ramping per the Yahoo and Gmail bulk sender requirements that took effect in February 2024. By day eight we were at 60,000 messages per IP per day with clean reputation building at Gmail Postmaster. By day ten we hit a complaint rate spike at Yahoo (0.42 percent over a 24-hour window, above the 0.3 percent threshold the bulk sender requirements specify) which traced back to a single segment of the marketing list that had been imported from a 2022 acquisition without re-consent. We paused that segment, dropped 27,000 addresses from the active sending list, and the complaint rate fell back below 0.1 percent within 36 hours. Week four was the cutover. We migrated transactional traffic on a Sunday morning, monitored for six hours, and migrated marketing traffic on the following Tuesday. The cutover itself was uneventful.

Week 5: DPA execution and DNS cleanup. Week five was DPA execution and DNS cleanup. The platform's compliance team reviewed our DPA template, requested two amendments (a 24-hour breach notification window instead of our standard 48-hour, and an explicit reference to FCA SYSC 8 in the audit-rights clause), both of which we accepted. The DPA was counter-signed on a Wednesday. We removed the SendGrid SPF includes from production DNS on the same day, retired the legacy DKIM selectors after the seven-day overlap completed, and decommissioned the dormant fourth domain entirely. The platform's CISO sent a one-line confirmation to the FCA compliance officer on the following Friday: "Migration complete. Schrems II exposure on email infrastructure is now zero."

What measurably improved. What measurably improved over the 90 days following migration. Gmail inbox placement on the marketing programme moved from 78 to 94 percent. Outlook.com from 64 to 88 percent. Yahoo throttling resolved completely; the platform's IPs were back to unconstrained throughput by week three after migration. Apple iCloud rejection rate dropped from 6 percent to under 0.5 percent, which corresponds to the population we should reasonably expect to see (recipients with full mailboxes, recipients who had genuinely closed the account). Bounce rate on the transactional programme fell from 1.3 percent to 0.6 percent, mostly because the new infrastructure correctly handled SPF for receivers that had been silently failing the previous configuration. The compliance team's quarterly Schrems II review for Q3 2025 listed email infrastructure as "materially compliant, no remaining exposure", which was the operational outcome the engagement was contracted to deliver.

What did not change. The platform's overall list quality did not improve through migration alone. The 27,000-address segment we paused during warmup has not been re-engaged, and the platform's marketing team still has not implemented the kind of progressive permission renewal that would let them recover those subscribers without starting another complaint spike. We flagged this to the CMO during the engagement and the recommendation has been on their backlog for nine months. The transactional programme volume did not increase. We had hoped that the cleaner authentication would let the platform send more aggressive product-update emails to dormant accounts, but the legal team has not approved that programme, and on reflection it was not a deliverability problem in the first place. The marketing programme cost per acquisition improved by roughly 12 percent, mostly through the inbox placement gain. That improvement was real but it is not the headline. The headline was Schrems II compliance, and the deliverability gains were the side effect of doing the migration properly rather than the goal that justified the engagement.