Hi everyone,
I've been helping a client migrate their email marketing from one major platform to another over the last few weeks, and we've hit a snag that's been surprisingly tricky to diagnose. I'm wondering if this is a common pitfall or if we just missed something obvious in the planning.
The migration itself went smoothly on the surface—contact fields mapped, send history archived, automations rebuilt. But after the first few campaign sends from the new system, we noticed our open rates had plummeted. And I don't mean a slight dip; I'm talking a drop from a consistent ~22% to under 5%. The click-through rates remained stable relative to the number of opens, which was the first clue.
After digging in, we found the culprit: **the open-tracking pixel.** The old system used a specific subdomain structure (e.g., `track.oldcrm.com/pixel123`). The new system, of course, uses its own (`em.newplatform.io/abc456`). The issue wasn't the pixel itself, but the legacy of our **email authentication records** (SPF, DKIM, DMARC).
We had updated our SPF record to include the new platform's sending servers, but we failed to consider that the open-tracking pixel is often loaded from a *different* domain than the one used for sending. Some email clients and corporate firewalls were blocking the pixel load because the domain it was hosted on wasn't fully aligned or authenticated in the way our old setup was. It looked like a third-party tracker being blocked.
Here's what we had to untangle:
* **SPF/DKIM for Sending:** We had this correct for the "From" domain.
* **Tracking Pixel Domain:** The new platform uses a completely separate domain for hosting tracking assets. This domain wasn't referenced in our DMARC policy, and its reputation was unknown to our recipients' systems.
* **Legacy Image Links in Automated Emails:** Some of our older, cloned automation emails still contained links to static images hosted on the *old* platform's CDN. Those were returning 404s, which caused some clients to flag the email content.
The fix involved a few steps, but the main one was working with the new CRM's support to understand their recommended CNAME setup for custom tracking domains. We ended up:
* Setting up a dedicated subdomain (like `track.ourdomain.com`) and pointing it to their tracking servers via a CNAME record.
* Ensuring this subdomain was included in our DKIM signing setup where possible.
* Creating a blanket redirect for any remaining old CDN image URLs to a generic placeholder on our own server.
Has anyone else encountered this "silent" breakdown in tracking after a CRM switch? I wish I had known to add **"validate tracking domain delivery"** to our pre-migration checklist, right up there with field mapping and list segmentation. It's one of those things that doesn't break the *sending*, but completely breaks the *reporting*, which can take a while to notice.
Would love to hear if you have other data-point oddities to watch for during a marketing automation platform migration.
~Jane
Stay connected