How do I move an email list to a new provider without hurting deliverability?

Import your suppression list first, then contacts with their statuses preserved, keep the same sending domain, authenticate it properly, and send your first campaign to your most engaged segment rather than the whole list. Changing provider and domain at the same time is the main thing to avoid.

Why should I import suppressions before contacts?

Because until the suppression list is in place, your new tool believes those addresses are mailable. A campaign in that window mails people who complained about you and addresses that are known dead, some of which are spam traps. It is the one migration mistake you cannot undo.

Do I need to warm up a new email provider?

If you keep the same sending domain, far less than people assume, because reputation follows the domain rather than the tool. Ramping your first few sends and starting with engaged recipients is still sensible. A genuine warm-up matters when you change domain or subdomain.

Can two email providers authenticate the same domain at once?

Yes. DKIM selectors are independent, so each provider publishes its own key under its own selector, and SPF can include both. Keep the old records in place until you have fully cut over: removing them early breaks mail that is still in flight.

What should I do with a list I have not emailed in over a year?

Treat it as needing re-permission rather than a warm-up. Send to the most recently engaged slice in small batches and watch bounce and complaint rates. Old addresses decay into spam traps, and there is a separate GDPR question about whether consent that old still supports contacting someone.

All guides

DeliverabilityAugust 12, 20268 min read

How to migrate an email list without wrecking your deliverability

Moving providers is mostly a data-import problem with one deliverability trap in it. Get the order right and mailbox providers barely notice. Get it wrong and you can undo years of reputation in one send.

The short version

Import your suppression list before your contacts, not after. This is the step people skip and the only one that is genuinely hard to undo.
Keep the same sending domain if you can. Reputation follows the domain, so keeping it means keeping most of what you built.
Import unsubscribed contacts as unsubscribed. A migration must never re-subscribe someone.
Send your first campaign to your most engaged segment, not the whole list.
If the list has been dormant for a year or more, treat it as needing re-permission rather than a warm-up.

What you are actually protecting

Two things carry your sending reputation: the domain you send from and, to a lesser degree for most senders, the IP address. On shared provider infrastructure the IP belongs to the provider and is their problem. The domain is yours, and it is where the value you have accumulated lives.

That is the single most useful fact about migrations. If you keep the same sending domain, you keep most of your reputation, and the move is closer to invisible than people expect. If you change domain at the same time as changing provider, you are starting from zero on the identity that matters and doing it while also changing everything else.

So: change one thing at a time. Move providers on your existing domain. If you also want to move to a subdomain for bulk mail, do that as a separate, later step with its own warm-up.

Suppressions first. Always.

Your suppression list is every address that hard-bounced, complained, or explicitly asked never to hear from you again. It is the most valuable file in your old account and the one nobody thinks to export.

If you import contacts before suppressions, there is a window in which your new tool believes those addresses are mailable. If a campaign goes out in that window, you have mailed people who complained about you and addresses that are known dead, both of which are exactly what mailbox providers watch for. Some of those dead addresses will be spam traps, and a trap hit is worth considerably more damage than an ordinary bounce.

Import them in the right order and something reassuring happens: the contact rows matching your suppression list get refused on the way in. That looks like an import error and is actually the guard working. Expect it, rather than debugging it.

The order of operations

1Export everything from the old provider while you still have access: contacts, custom fields, unsubscribes, and the suppression or blocklist. Do this before you cancel anything.
2Import the suppression list into the new tool.
3Import contacts, preserving status. Unsubscribed stays unsubscribed, with the original date if the format allows it.
4Map custom fields and rebuild segments. Check that merge tags resolve before you rely on them in a subject line.
5Authenticate the sending domain: DKIM signing as your domain, SPF including the new provider, DMARC left as it is if you already have one.
6Send a test to yourself and to a couple of colleagues on different mail providers. Check it renders, check the unsubscribe link works, check the From address is what you expect.
7Send the first real campaign to your most engaged segment only.
8Watch bounce and complaint rates on that send before widening.

Step 5 is worth a note if you are keeping your old provider running in parallel: leave their DKIM selector and their SPF include in place until you have fully cut over. Both providers can authenticate the same domain simultaneously, because DKIM selectors are independent. Removing the old records early is a common way to break mail that is still in flight.

The first send

Resist the urge to make your first campaign on the new tool a big one. Not because the tool might fail, but because the first send is your only cheap chance to see whether anything is subtly wrong before it is wrong at scale.

Send to your most engaged segment: the people who opened something recently. Their engagement is a positive signal, their bounce rate will be near zero because the addresses are demonstrably live, and their complaint rate will be low because they remember signing up. That is the best possible first impression to give a mailbox provider that is seeing a new sending path for your domain.

Then read the numbers before widening. Bounce rate should be a fraction of a percent on an engaged segment; if it is higher, your import brought in rows it should not have. Complaint rate should be near zero; if it is not, you may have contacts on the list who do not remember you, which is a list problem rather than a migration problem.

The dormant list problem

There is one case where none of the above is enough, and it is common: the list you are migrating has not been emailed in a year or more.

Those addresses have decayed. People changed jobs, providers recycled abandoned mailboxes into spam traps, and the ones that still work belong to people who have forgotten you exist. Mailing that list is a bad idea on any provider and a worse idea as your first send on a new one.

Treat it as a re-permission exercise rather than a warm-up. Send to the most recently active slice, in small batches, and watch the numbers. Do not send to anyone who has not engaged in two years without accepting that you are gambling reputation on them. Under the GDPR there is a further question about whether consent that old is still a live basis for contacting someone, which is worth asking before the deliverability question.

How day3 handles it

Suppressions can be pushed straight in through the API before any contacts, and doing so makes day3 refuse the matching contact rows on import. CSV import takes email, first_name and last_name, dedupes, reports per-row results, and lets you retry only the rows that failed rather than restarting the batch. The API takes up to 1,000 contacts per call and upserts by plain email address, so a re-run is safe.

Contacts already marked unsubscribed import with that status and the date they left. Domain verification publishes DKIM, SPF and DMARC through Cloudflare automatically, or hands you the records for any other DNS host, and rechecks until it verifies. Bounce and complaint gauges are scaled to the provider's own thresholds, so the first send tells you whether the import was clean.

Questions

How do I move an email list to a new provider without hurting deliverability?: Import your suppression list first, then contacts with their statuses preserved, keep the same sending domain, authenticate it properly, and send your first campaign to your most engaged segment rather than the whole list. Changing provider and domain at the same time is the main thing to avoid.
Why should I import suppressions before contacts?: Because until the suppression list is in place, your new tool believes those addresses are mailable. A campaign in that window mails people who complained about you and addresses that are known dead, some of which are spam traps. It is the one migration mistake you cannot undo.
Do I need to warm up a new email provider?: If you keep the same sending domain, far less than people assume, because reputation follows the domain rather than the tool. Ramping your first few sends and starting with engaged recipients is still sensible. A genuine warm-up matters when you change domain or subdomain.
Can two email providers authenticate the same domain at once?: Yes. DKIM selectors are independent, so each provider publishes its own key under its own selector, and SPF can include both. Keep the old records in place until you have fully cut over: removing them early breaks mail that is still in flight.
What should I do with a list I have not emailed in over a year?: Treat it as needing re-permission rather than a warm-up. Send to the most recently engaged slice in small batches and watch bounce and complaint rates. Old addresses decay into spam traps, and there is a separate GDPR question about whether consent that old still supports contacting someone.