Surviving Microsoft's May 2025 enforcement: a 21-day cold-outbound infrastructure rebuild

The 21-day rebuild plan we proposed had three workstreams running in parallel: infrastructure, authentication, and integration.

Infrastructure (days 1-14): provision a dedicated PowerMTA cluster in our Netherlands datacentre with a fresh /27 IPv4 block. Warm the /27 across the 14-day window using the engaged-first warmup methodology, calibrated specifically against Outlook.com / Hotmail / Live as the target receiver. Configure per-IP throttling for Microsoft destinations at 600/hour/IP for the first 7 days, ramping to 1,800/hour/IP by day 14.

Authentication (days 1-10): clean up SPF on all sending domains to be under the 10-lookup limit. Generate fresh RSA-2048 DKIM selectors per sending domain. Migrate DMARC from p=none to p=quarantine on the 14 sending domains in scope, with the rua= aggregate report ingestion routed through our parsedmarc + Elasticsearch stack so we could see in near-realtime which receivers were honouring the policy and which were not.

Integration (days 8-21): rebuild the OAuth handoff with their existing tooling. They were using Smartlead for one outbound program and Lemlist for another. Both tools support OAuth-based SMTP relay against custom infrastructure, but the configuration is fiddly enough that most operators give up and use the vendor's default sending pool. We did the OAuth setup correctly so their reps continued using the Smartlead and Lemlist UI they already knew, but the actual SMTP traffic was originating from our dedicated infrastructure.

Cutover happened on day 21. Sub-accounts 1 and 3 were migrated cleanly onto the new infrastructure. Sub-account 2 — the burned one — was retired entirely; its sending domains were sunset and its outbound traffic was rebuilt on fresh domains with proper alignment from day one. Microsoft 5.7.515 rejection count dropped to zero on day 22.

The /27 warmup curve was the most operationally sensitive part of the 21-day window. Fresh IPv4 against Microsoft destinations starts at zero reputation — Microsoft does not extend "new sender on a clean /27" any benefit-of-the-doubt. The curve we used began at 50 messages/day per IP on day 1, rising to 200/day by day 3, 800/day by day 7, 2,400/day by day 10, and 14,400/day by day 14. The volume was sourced exclusively from the engaged-segment book of the client's prior CRM activity — recipients who had opened or clicked an email from the brand in the prior 90 days.

The Smartlead OAuth integration is worth detailing because it is where most cold-outbound migrations get stuck. Smartlead supports custom SMTP via OAuth 2.0 against a self-hosted MSA. We deployed an internal MSA on the same /27 as the outbound IPs, with PostgreSQL-backed credential storage and per-user rate limiting. The MSA accepts SMTP submission from Smartlead, applies our per-domain DKIM signing, and hands off to PowerMTA for delivery. The end-to-end latency from Smartlead "send" button to first SMTP DATA on the wire to Outlook is consistently under 800ms.

On the DMARC migration, we made one non-obvious choice: we migrated to p=quarantine on the 14 sending domains in scope, but kept p=none on the parent root domain (which the client uses for their corporate / non-cold-outbound mail). This is a defensible posture because the cold-outbound traffic uses dedicated subdomains and the receiver enforcement we cared about applies at the From: header domain, which was always one of the subdomains. Migrating the parent root to p=quarantine without first auditing the corporate mail flows would have risked breaking something orthogonal to the engagement.

The MTA-STS deployment was opportunistic but consequential. The client's sending domains had no MTA-STS policy, which meant their TLS-RPT reports were sparse and their Outlook delivery TLS posture was opportunistic. We published MTA-STS policies in testing mode for 14 days, then switched to enforce mode with a max-age of 86400. The TLS-RPT report stream became substantially richer afterwards — useful both for security posture and for spotting per-receiver TLS misconfigurations early.

The bounce-classification work mirrored what we did on the DACH engagement. The 5.7.515 rejections, in particular, deserved a dedicated bounce category and remediation flow: any 5.7.515 rejection on the new infrastructure (which should have been zero, but we wanted defence in depth) would automatically pause that specific domain and trigger a manual authentication audit before sending resumed.

Reporting cadence during the 21-day rebuild was daily — a 2-page status note covering Microsoft rejection count, IPv4 reputation movement (Talos + SNDS), Smartlead/Lemlist queue health, and any authentication anomalies caught by the parsedmarc ingestion. Post-cutover the cadence dropped to weekly, then monthly after month 3.