Moving email platforms resets the sending reputation a marketing programme quietly depends on. Deliverability needs its own workstream, not a checklist line in the cutover plan.
When a marketing team changes email platform, the visible work gets the attention: templates, journeys, data extensions, integrations, reporting. Deliverability usually appears late in the plan, compressed into a single task called “set up authentication”.
That is the item I would most want reviewed before a cutover date is agreed. Everything else fails loudly — a broken template is obvious the moment someone looks at it. Deliverability fails quietly, several weeks later, in numbers nobody was watching.
Reputation is not stored in your account. Mailbox providers build it from observed behaviour tied to the infrastructure a message comes from: the sending IP addresses and the sending domain. A new platform usually means both change.
Years of careful list hygiene on the old platform buys nothing on the first send from the new one. To Gmail and Outlook, you are an unfamiliar sender asking for the benefit of the doubt, at whatever volume you happen to open with.
This is the assumption worth correcting early with stakeholders. People hear “migration” and picture continuity. Deliverability is the part that genuinely starts from zero.
Three records do the work, and all three have to be correct for the new platform, not the old one. SPF has to authorise the new sending infrastructure. DKIM needs its keys generated on the new platform and published in DNS. DMARC ties them together and tells mailbox providers what to do when a message fails.
Since February 2024, Google and Yahoo require all three from bulk senders — those sending roughly 5,000 messages a day or more to their users — along with one-click unsubscribe and a spam complaint rate kept below 0.3%. These are not best practices any more. They are entry conditions.
Two failure modes are worth checking by hand. SPF permits only ten DNS lookups, and adding a new platform to a record that already includes several services can quietly exceed it, which invalidates the whole record. And DNS changes need to have actually propagated before cutover, not merely been saved in the registrar.
The instinct after cutover is to resume the normal calendar: the new platform is configured, so send the newsletter. That single decision causes most of the damage I have seen discussed in migration retrospectives.
A warm-up starts with the recipients most likely to react well — people who opened or clicked recently — and grows volume over weeks. Early positive engagement is the evidence mailbox providers use to decide you are worth delivering. Starting with your least engaged segment teaches them the opposite.
This has a scheduling consequence that belongs in the plan, not in the postmortem: for several weeks after cutover you cannot send at full volume. If the campaign calendar assumes you can, the calendar is wrong.
Decommissioning is satisfying and it is usually premature. While reputation is still being established, the previous platform is both a fallback and a baseline — the only clean comparison for what engagement looked like before the move.
Licences cost money and there is always pressure to switch them off at cutover. It is worth arguing for a defined overlap period with an explicit end date, rather than discovering mid-recovery that the comparison is gone.
Delivery rate is the most reassuring and least useful number in the reporting. It tells you a message was accepted, not where it landed. A campaign can report 99% delivered and still be routed almost entirely to spam.
The signals that matter are inbox placement, complaint rate, engagement broken down by mailbox provider, and bounce reasons read by category rather than as a total. Google Postmaster Tools and Microsoft SNDS report on their own traffic for free, and they are where problems appear first.
Segmenting by provider matters more than teams expect. Gmail, Outlook and corporate filters reach different conclusions about the same sender, and an aggregate figure averages away exactly the problem you need to see.
Give deliverability its own owner, its own timeline and its own exit criteria, agreed before the cutover date is fixed. It is the part of a platform migration whose consequences arrive after everyone has moved on to the next thing.