A new platform doesn't inherit your good name
Read past the "modernization" and two of this week's job postings describe the same move: a company rebuilding its email stack. It's overdue. It's also the single most dangerous week in the life of a sender reputation — and nothing on the migration plan says so.
TL;DR You can migrate contacts, templates and journeys. You cannot migrate reputation. But one asset does move and almost nobody carries it across: the suppression list. Skip it and you re-mail the people who already complained — on infrastructure with no history to absorb it.
Why is a replatform the riskiest week for a sender?
This month Fortune Media posted a set of roles that quietly reveal what's happening under the hood: it's moving off Salesforce Marketing Cloud and evaluating a new customer-data platform. Poshmark surfaced the same shape from a different angle — a growth PM whose mandate is standing up the marketplace's new customer-engagement platform. On paper, two sensible, overdue modernizations. Underneath, both companies are about to walk through the one moment that quietly resets everything: the migration.
What exactly fails to transfer?
Here's the trap. You can migrate contacts, templates, journeys, automations, and reports. You cannot migrate reputation. The warmed IPs, the aligned DKIM signatures, the years of accumulated inbox trust that made your mail land — none of it transfers. The new platform starts you at zero, usually on new sending infrastructure, and no migration checklist has a row for it. Everyone's watching feature parity: does the new tool do everything the old one did? Nobody's watching the asset the new tool can't bring with it.
Where does the reset actually happen?
The reset happens in three places, and all of them fail silently. Authentication alignment: a new sending domain or subdomain means SPF, DKIM, and DMARC alignment have to be re-established, and a mismatch doesn't error — it just quietly stops passing. Warmth — the same ramp problem AI sequencers hit at volume: new IPs and domains have no history, so blast your full list on day one and receivers treat you as a stranger sending in bulk. And trust: mailbox providers score the new sending identity from scratch, watching how the first days go before they decide where you belong.
So the story writes itself. The migration gets scoped as a feature-parity project. The team rebuilds the journeys, imports the segments, matches the dashboards, signs off. Then the first real campaign goes out on the new platform — full volume, because why wouldn't it — and it lands in spam. Right at the moment leadership is watching the shiny upgrade prove its ROI. The tool works perfectly. The reputation didn't come along, and now you're rebuilding it in public, under scrutiny, from behind.
A migration isn't a config swap; it's a warmup event. Re-audit authentication alignment on the new sending domain before the first send. Ramp volume on the new IPs and domain instead of opening the taps. And watch posture through the cutover, so a silent reset shows up as a line on a graph the day it happens — not as a mystery three weeks later when someone finally asks why open rates fell off a cliff. The companies posting these roles are ahead of most: they've at least put a human on the new stack. The trap isn't the migration. It's calling it done when the last journey is rebuilt, and forgetting that your good name is the one part of the move with no import button.
Each of the three resets fails in its own way, and none of them raises an error:
- Alignment — a new sending subdomain means SPF, DKIM and DMARC alignment must be re-established. A mismatch does not error; it just stops passing.
- Warmth — new IPs and domains carry no history, so day-one volume is the reputation.
- Consent state — unsubscribes and complaints live in the old platform, and nothing in the new one knows about them.
The alignment reset is the one people underestimate, because DMARC does not check that your mail authenticates — it checks that the authenticated domain matches the one your recipients see. Murray Kucherawy and Elizabeth Zwicky put it plainly in RFC 7489 §3.1: “DMARC authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier.” Move to a new sending subdomain and that match has to be rebuilt from scratch — and when it is wrong, nothing errors.
What is the one thing you can carry across?
The suppression list — and it is the asset most migrations leave behind. Reputation cannot move because it is an opinion mailbox providers hold about your infrastructure. Suppression state is different: it is a record you own, of people who hard-bounced, complained, or unsubscribed. It is portable by construction, and every platform will export it.
Skipping it produces the worst possible combination. You arrive on cold infrastructure with no history to absorb a mistake, and the first thing you do is re-mail the exact population that already told the old platform to stop. Those recipients do not complain again politely — they complain to the mailbox provider, against a brand-new sending domain, during the window when every signal is weighted most heavily. Gmail’s bulk-sender rules cap spam complaints at 0.30%, and a fresh domain has no volume to dilute them.
| Asset | Migrates? | What happens if you assume it does |
|---|---|---|
| Contacts, templates, journeys | Yes | Nothing — this is what checklists cover |
| Suppression list | Yes, but only if you carry it | You re-mail everyone who already complained |
| IP and domain reputation | No | You blast a full list from zero history |
| Authentication alignment | No — must be re-established | Mail silently stops passing DMARC |
| Engagement history | No | You cannot segment by who still opens |
There is a harder version of this problem that most companies do not realise they have: suppression is fragmented per sending platform. A company running transactional mail on one provider, lifecycle on a second and outbound on a third has three disjoint lists. Someone who complained on one is still perfectly mailable from the other two, and no vendor holds the union because each sees only its own traffic.
What belongs on the migration plan that isn’t on it?
Feature parity dominates every replatform plan. These five rows rarely appear, and each one fails silently:
- Export and import the suppression list first — before the first send, not after the first complaint.
- Re-establish authentication on the new sending domain and confirm it, since a mismatch does not error. An authentication audit takes seconds; in our scan of 117 companies hiring for this work, 97% publish DMARC but only 74% enforce it.
- Verify the provider’s specific records before cutover, not the generic ones. A go-live pre-flight exists because a shared sandbox domain passes every DNS test while belonging to someone else.
- Plan a ramp instead of a launch. New infrastructure has no history, so the first week’s volume is the whole reputation. Check whether the domain can absorb the volume before scheduling the blast.
- Segment by engagement on day one — send to people who opened recently first, because early signals on a cold domain are weighted hardest.
| Migration week | What to send | Why |
|---|---|---|
| Before send one | Nothing — import suppression, verify records | The only cheap moment to catch a mismatch |
| Week 1 | Recent openers only | Early signals on a cold domain carry the most weight |
| Weeks 2–4 | Widen by engagement recency | Builds volume history without importing risk |
| Only then | The full list | By now there is history to absorb a bad day |
How do you know the reset actually took?
You watch the receivers disagree. A domain-wide pass rate averages mailbox providers that behave nothing alike; one can report 98% while another reports 71% in the same week on the same domain. During a migration that spread is the earliest signal that alignment broke somewhere, and it arrives in the DMARC aggregate reports you are already being sent — 87% of companies in our scan publish a rua address and never read it. Reading them is the difference between finding a broken migration in week one and finding it in the quarterly numbers. It is the same gap we found when nobody owns whether email lands.
Key takeaways
- Reputation cannot migrate, but the suppression list can — and it is the asset most replatforms leave behind.
- Re-mailing complainers on cold infrastructure is the worst case: Gmail caps complaints at 0.30% and a new domain has no volume to dilute them.
- Suppression is fragmented per platform. Run three senders and you have three disjoint lists; no vendor holds the union.
- 97% of companies in our scan publish DMARC but only 74% enforce it, so a migration usually re-creates a record that asks receivers to do nothing.
- Per-receiver pass rates catch a broken migration in week one, and 87% of senders already publish the
ruaaddress that produces them.
FAQ
What can and cannot be migrated between email platforms?
Contacts, templates, journeys, automations and reports all migrate. Sender reputation does not, because it is an opinion mailbox providers hold about specific IPs and domains rather than data you own. Authentication alignment has to be re-established on the new sending domain. The one valuable asset that is portable and usually forgotten is the suppression list.
Why does the suppression list matter so much during a migration?
Because skipping it means the first send from brand-new infrastructure goes to the exact people who already complained or hard-bounced on the old platform. A fresh sending domain has no volume history to dilute complaints, and Gmail's bulk-sender rules cap the complaint rate at 0.30%. It is the worst possible combination of audience and infrastructure.
How long should a post-migration warmup take?
Long enough that early volume is dominated by people who actually engage. There is no universal schedule because it depends on list size, engagement distribution and the receiver mix, but the principle is fixed: new infrastructure has no history, so the first week's signals carry disproportionate weight. Segment by recent openers first and expand outward.
How do you tell if a migration broke authentication?
Split the DMARC pass rate by reporting mailbox provider rather than reading one domain-wide number. Receivers that behave differently will diverge when alignment breaks somewhere, and a large gap between two of them is the earliest available signal. Those reports arrive automatically for any domain publishing a rua address.
Sources
- HireAmino. What 117 companies hiring for deliverability actually publish in DNS — the scan behind the figures in this post, audited against live DNS.
- Yahoo. Sender best practices — the second half of the 2024 bulk-sender requirements.
- Google. Email sender guidelines — bulk-sender authentication requirements and the 0.30% spam-complaint ceiling, in force since February 2024.
- Kitterman, S. RFC 7489, DMARC — aggregate reporting and the
ruatag that produces per-receiver data.