Marketing Operations
August 7, 2026 · 5 min read · by Ananda Narasimhan
Every MAP or CRM migration we run has a deliverability problem hiding inside it. Nobody plans for it. The team is focused on field mapping and workflow parity, and the sending domain's reputation gets treated as something that just carries over. It doesn't. A new ESP, a new IP range, or even a sudden change in send volume and pattern is exactly the kind of signal spam filters are built to catch.
This is the audit we run before touching a live sending domain, whether the move is HubSpot to Marketo, Pardot to HubSpot, or a straight ESP swap with no CRM change at all.
SPF, DKIM, and DMARC are table stakes now, not a nice-to-have. Since November 2025, Gmail and Yahoo reject non-compliant bulk mail outright instead of routing it to spam. We check that SPF includes every sending source, that DKIM keys are actually signing outbound mail from the new platform, and that DMARC is set to at least p=quarantine with a real reporting address someone is watching. A DMARC record that exists but points at nobody is the same as not having one.
Google wants your spam complaint rate under 0.10% in Postmaster Tools and treats 0.30% as a hard ceiling. Yahoo's math is stricter: they calculate complaints against inbox-delivered mail only, not total sent, so the same complaint count produces a higher rate on Yahoo than on Google. We pull Postmaster Tools data before migration to establish a baseline, then watch it daily for the first two weeks after cutover. A rate that looks fine on day one can drift past the threshold by day five if send volume ramps too fast on the new platform.
Contact records migrate cleanly. Sender reputation does not. A new ESP means a new IP range or a shared pool the account has no history on, and mailbox providers have no basis yet to trust it. We ramp volume deliberately on the new platform, starting with the most engaged segment of the list, rather than firing the full send calendar on day one. Warming a domain takes one to two weeks minimum, and skipping it is the single most common cause of a post-migration deliverability drop.
We suppress hard bounces, unengaged contacts past 180 days, and any address collected without a clear opt-in trail before the new platform sends a single email. A list that was quietly accumulating dead weight on the old ESP will surface every one of those problems immediately on the new one, because the new platform has no sending history to absorb the hit. One-click unsubscribe also has to work correctly on day one — it's a hard requirement for bulk senders now, not an optional courtesy link.
We watch four numbers: inbox placement rate via seed testing, spam complaint rate in Postmaster Tools and Yahoo's feedback loop, bounce rate by domain, and open rate against the pre-migration baseline for the same segment. A drop in open rate with a stable complaint rate usually means inbox placement, not content, and it points straight back to authentication or IP reputation rather than the email itself.
Fix authentication and list hygiene before the migration date is even scheduled, not during cutover week. Ramp volume on the new platform over ten to fourteen days rather than matching the old send calendar immediately. Monitor Postmaster Tools and bounce rate daily for the first two weeks, and have a rollback plan for volume — not a full platform rollback — if the spam rate climbs past 0.10%.
None of this is complicated. It's just easy to skip when the project plan is organized around field mapping and workflow logic, and deliverability doesn't show up as a line item until inbox placement has already dropped.