To migrate email provider traffic safely, move in stages, and the switch becomes a deliverability exercise rather than a gamble. This guide gives a plan: take stock of what you send, export suppression data, prepare DNS, move traffic in steps, warm up new infrastructure and watch a short list of numbers until everything is stable.
Never switch everything on one day. A full cutover with new IPs and no warm-up looks like a compromised account to receivers. Move one stream or a slice of volume at a time and keep the old provider as a fallback.
What moves and what does not
| Item | Moves with you? | What to do |
|---|---|---|
| Domain reputation | Yes, it belongs to your domain | Keep the same From domain and authenticate it |
| IP reputation | No, it belongs to the IP address | Warm up new IPs, or start on an established shared pool |
| Suppression lists | Only if you export and import them | Import before the first send |
| Templates | Usually not | Recreate and test in the new account |
| Webhook endpoints | No | Register them again and verify signatures |
| Tracking links | No, they use the old domain | Set a custom tracking domain on your own domain |
Stage 1: Inventory what you send
- Every application and script that sends mail, and the credentials each one uses.
- Sending domains and subdomains, and which streams each one carries.
- Peak volumes by day and hour, and any seasonal peaks coming up. Avoid migrating just before one.
- Current baselines: bounce rate, complaint rate, delivery time and placement.
- Templates, webhook consumers and any reports that read data from the old provider.
Stage 2: Export suppressions and consent data
This stage protects your reputation and your legal position. Export hard bounces, spam complaints and unsubscribes and import them into the new account before any message goes out. See suppression list management and GDPR and email consent for what to keep.
Stage 3: Prepare DNS and authentication
| Record | Action during migration | Remove later |
|---|---|---|
| SPF | Add the new provider include next to the old one | Remove the old include after cutover |
| DKIM | Publish the new selector keys | Remove old selectors after cutover |
| DMARC | Keep your policy and make sure alignment passes with the new system | Not applicable |
| Return-path and tracking domains | Create them on your own subdomains | Remove the old ones last |
| TTL | Lower to about five minutes a few days ahead | Raise again afterwards |
Send test messages and check the headers for SPF, DKIM and DMARC alignment, as in the authentication guide.
Stage 4: Move traffic in steps
| Week | Share of traffic on the new provider | Who receives it |
|---|---|---|
| 1 | 5 to 10 percent | Most engaged recipients, or one low-risk stream |
| 2 | 25 percent | Engaged recipients plus more of the same stream |
| 3 | 50 percent | Add a second stream, such as transactional |
| 4 | 75 to 100 percent | Remaining streams, keeping the old provider as fallback |
These steps are a starting point. Use smaller steps when you start on new dedicated IPs, and follow the plan in the warm-up guide. Pause at any step where bounces, complaints or deferrals rise.
Stage 5: Watch the right numbers
| Metric | Healthy target | If it moves the wrong way |
|---|---|---|
| Hard bounce rate | Under 2 percent | Pause and check list quality and DNS |
| Complaint rate | Under 0.10 percent | Reduce volume and send to engaged recipients only |
| Deferrals at one provider | Rare and short | Slow the rate for that provider |
| Gmail spam rate | Well under 0.10 percent | Check content and segments |
| Delivery time | Close to your baseline | Check queues and rate limits |
Stage 6: Finish and clean up
- Move the last stream and confirm that the old provider sends nothing.
- Update webhook consumers and verify signatures with the new secret.
- Remove the old provider from SPF and delete old DKIM selectors.
- Keep the old account for two to four weeks to catch late events, then export final data and close it.
- Raise your DNS TTL values again and document the new setup.
Planning a migration? Tell us your volume, streams and current provider and we will help you build a staged plan.
Further reading and sources
Frequently asked questions
How long does an email provider migration take?
A small, single-stream setup can move in a few days. A larger one with several applications, templates and a dedicated IP usually takes three to six weeks, mostly because of the staged ramp. Rushing the ramp is the most common cause of deliverability problems after a move.
Will my sender reputation move with me?
Domain reputation follows your domain, so a well-authenticated domain with a good history keeps most of its standing. IP reputation does not move, because it belongs to the IP address. New IPs need a warm-up, and a shared pool starts from the pool reputation.
Should I keep sending from the same domain?
Usually yes. Keeping the same From domain preserves the history that mailbox providers associate with it. You change the infrastructure under the domain, and you keep the domain.
Do I need to warm up if I am moving a lot of volume?
If you use new dedicated IPs, yes. If you use shared IPs with an established reputation, the ramp can be shorter, but a sudden jump in volume at a new connection still looks unusual to receivers, so move in stages either way.
Which data must I export from the old provider?
At minimum, export suppression lists of hard bounces, complaints and unsubscribes, and your active contact lists with consent information if you hold them there. Also save templates, webhook configuration, sending domains and a record of recent volume and bounce rates.
What happens to SPF and DKIM when I switch?
Add the new provider include to your SPF record and publish the new DKIM keys while the old ones remain. Remove the old provider only after all traffic has moved. Keep the lookup count under 10, as explained in the authentication guide.
Can I run two providers at the same time?
Yes, and it is the safest approach. Split by stream first, for example transactional on the new provider while marketing stays, or by percentage of volume. Keep both authorised in SPF during the overlap.
Why lower the DNS TTL before the switch?
A short TTL, such as five minutes, means that a change reaches receivers quickly and that you can roll back fast if something goes wrong. Lower it a few days ahead, then raise it again after the migration settles.
What should I watch after the cutover?
Watch hard bounce rate, complaint rate, deferrals by provider, delivery time and, for Gmail, the spam rate in Postmaster Tools. Compare them with your baseline from the old provider, and slow down if any number moves the wrong way.
When should I close the old account?
Keep it for two to four weeks after the last stream moves, so you can handle late bounces, complaints and unsubscribe links that point to the old system. Export final reports before closing.