Teams change infrastructure providers for sensible reasons — cost at scale, a dedicated IP option, DNS automation, or leaving an agency. The reasons are rarely the problem.
The problem is doing it as a switchover. Cancel on the 31st, start on the 1st, and discover that the new mailboxes need three weeks of warmup before they carry real volume.
The migration is straightforward if you understand one distinction.
What transfers and what does not
Domain reputation transfers. This is the good news and it is most of your accumulated value. Inbox providers score the domain, and that score follows the domain regardless of which infrastructure sends from it. If your domains are yours and you keep them, you keep the reputation.
IP reputation does not transfer. New provider, new IPs, no history. If you are moving to dedicated IPs, those start unknown and need warming exactly as any new IP does.
Mailbox contents transfer if the mailboxes are portable. Over SMTP and IMAP, you can move or at least export conversation history. If the mailboxes are locked inside a platform with no export path, the threads stay there.
Warmup history does not transfer. The new mailboxes are new mailboxes.
So the shape of a good migration is: keep the domains, ramp the new infrastructure in parallel, and move volume gradually as it warms.
The staged plan
Week 1: audit
Establish what you actually own.
- Are the domains registered to you, on an account you control? If not, start transfers now — they take five to seven days.
- Can mailboxes be exported over SMTP and IMAP, or only used inside the platform?
- Where do replies currently land, and will that change?
- What is your current sending volume per domain and per mailbox?
If domains are not yours, the whole plan changes and the ownership piece is the place to start.
Week 2: provision in parallel
Set up the new infrastructure alongside the old, without touching the old.
- Create mailboxes on the new provider, three per domain
- Point authentication records to include the new sending source without removing the old one — both should pass during the transition
- Verify SPF stays within the ten-lookup limit; this is the step where it commonly breaks, because you are temporarily authorising two providers
- Start warmup on the new mailboxes
That SPF point deserves attention. Adding a second sending provider to an existing SPF record is the most common way a migration silently breaks authentication, and the symptom is spam placement that looks like a reputation problem.
Weeks 3–5: warm and test
- Warmup runs three to four weeks; do not compress it
- Run an inbox placement test on the new mailboxes before sending anything real
- Compare placement against the old mailboxes on the same domains — this is a clean comparison because the domain is constant
- Fix anything the test surfaces before moving volume
Weeks 5–7: shift volume gradually
- Start at roughly 20% of volume on the new mailboxes
- Increase by about 30% every few days, watching bounce rate, complaint rate and placement
- Keep the old mailboxes sending the remainder
- If anything degrades, hold rather than continuing to ramp
Week 8: complete
- Move remaining volume across
- Export mailbox contents from the old provider
- Remove the old provider from SPF, and verify the record still passes
- Cancel only after export is confirmed complete
That last point is not pedantry. Cancelling before exporting has cost people every conversation in every mailbox, and there is no recovery.
The specific traps
SPF lookup limit. Authorising two providers temporarily can push the record past ten lookups, at which point it fails silently and everything lands in spam. Check the count after every change.
DKIM keys are per provider. Both providers need their own DKIM records published during the overlap. Removing the old one too early breaks authentication on mail still going out from it.
Tracking domains. If your tracking domain points at the old provider, links break when you cancel. Move tracking before, not after, and confirm SSL is valid on the new setup.
Reply routing. MX records determine where replies arrive. If the new provider handles inbound differently, test that a reply to a new mailbox actually reaches you before you rely on it.
Suppression lists. They do not migrate automatically. Export and import before the first send on the new infrastructure, or you will contact people who asked you to stop.
Sequences mid-flight. Leads partway through a sequence on the old mailboxes should finish there. Do not move an in-progress sequence mid-flow, because the sender changes and the thread breaks.
When to move rather than migrate
Sometimes a clean break is correct.
If domain reputation is already poor, migrating it preserves the problem. Buy new domains, warm them on the new provider, and retire the old estate.
If you are changing strategy substantially — from mainstream mailboxes to private infrastructure at ten times the volume — the old estate may not fit the new shape anyway.
If the old provider owns the domains and will not transfer them, you are rebuilding regardless. Start the new estate now rather than at the contract end date, so the warmup runs in parallel with your remaining service.
Portability, before you commit next time
Worth asking of whichever provider you move to, because this whole exercise is easier the second time if you ask now:
- Can mailboxes be used with any sending tool over SMTP and IMAP?
- Are domains registered in my name?
- Can I export mailbox contents, and in what format?
- Is there a retention period after cancellation?
Portability is not a feature vendors advertise, since the incentive runs the other way. Ask anyway.
The short version
Domain reputation transfers; IP reputation and warmup history do not. So keep the domains, provision the new infrastructure in parallel, and let warmup run while the old setup carries the volume.
Eight weeks end to end: audit, provision, warm, test, shift gradually, complete. Watch the SPF lookup count at every step, because authorising two providers at once is the most common way a migration silently breaks.
And never cancel before the export is confirmed. That mistake is unrecoverable and it is made surprisingly often.
Next: infrastructure cost at 10, 100 and 500 mailboxes, or volume ramp schedules.
Frequently asked questions
Does sender reputation transfer when changing email providers?
Domain reputation transfers, because it is attached to the domain rather than the infrastructure. IP reputation and warmup history do not — new IPs start unknown and need a full ramp.
How long does a mailbox migration take?
About eight weeks done properly: a week to audit, a week to provision in parallel, three to four weeks of warmup and testing, then two weeks shifting volume gradually.
What breaks most often during an email infrastructure migration?
The SPF record. Authorising two providers during the overlap can exceed the ten-lookup limit, which fails silently and sends everything to spam.
Can I move mailboxes between providers?
If they support SMTP and IMAP, you can export contents and use them with other tools. Mailboxes locked inside a platform with no export path mean the conversation history stays behind.