Will changing email providers hurt my deliverability?

Temporarily and mildly, if you do it properly — your domain reputation follows the domain rather than the provider, so most of what you have built travels with you. What does not travel is the sending history at the new provider's infrastructure, which is why volume has to ramp. Migrations that damage delivery badly almost always did one of three things: lost the suppression list, misconfigured SPF, or mailed the whole list on day one.

Can I use two email providers at the same time?

Yes, and during a migration you should. A domain can publish multiple DKIM selectors, so both providers sign mail as you simultaneously. SPF is the only record needing care — merge both services into one record rather than publishing two.

What happens if I lose my suppression list?

You will mail people who unsubscribed, and a meaningful share will report it as spam rather than unsubscribing again. That is the worst possible way to start at a new provider, because complaint rate is the metric that gets sending suspended. If you have already closed the old account, the only remedy is to mail only recently engaged recipients for several weeks and rebuild suppression from the complaints you receive — which is as unpleasant as it sounds.

How long should I keep the old provider running?

Until the new one has run clean for at least a week of real traffic, and ideally a full billing cycle. The last month's fee is cheap next to discovering a problem with no way back. Keep the old credentials in your configuration too, so rolling back is a config change rather than an emergency deploy.

Should I move transactional or marketing email first?

Marketing first, always. Campaigns carry the reputation risk you want to observe under controlled conditions, and a late newsletter is survivable. Transactional mail is the traffic where failure is immediately visible to customers, so it moves last, after the domain has a delivery history at the new provider.

Getting started

How to move email providers without breaking delivery

Updated 4 September 2026 · 7 min read · SendKernel

A safe email migration runs both providers at once for one to two weeks and moves traffic in one direction only: campaigns first, transactional last. The step that decides whether it goes well is exporting your suppression list as a separate file before anything else — it is stored apart from your contacts at every major provider, it is the file teams forget, and losing it means mailing people who already unsubscribed, which is the fastest way to arrive at a new provider with a damaged reputation.

The short version

Export the suppression list separately. It is not in your contacts export, and it is the one file you cannot reconstruct.
A domain can hold several DKIM selectors at once, so both providers can authenticate in parallel. There is no cutover moment.
Move marketing first and transactional last — receipts and password resets are the traffic you cannot afford to get wrong.
Volume on the new provider still has to ramp. A migration does not inherit the old provider's reputation.

Why migrations damage delivery

Three causes, in order of how often they happen. The suppression list is left behind, so people who unsubscribed months ago receive a campaign and report it as spam. The new domain configuration ships without full authentication, so mail is rejected outright. And the entire list is mailed on day one from a domain with no sending history at the new provider, which looks exactly like a compromised account.

All three are avoidable, and all three come from treating a migration as a cutover rather than an overlap. There is no technical reason to switch in one step: DNS lets both providers authenticate simultaneously, so you can move traffic gradually and roll back at any point by simply sending through the old one again.

Before you touch anything: export

1Export the suppression list as its own file
Unsubscribes, hard bounces, and spam complaints. Every major provider stores these separately from contacts, so a contacts export does not include them. This is the single most important file in the migration and the one most often missed.
2Export contacts with their subscription status
Keep the status column. Any competent platform honours it on import rather than resurrecting people who opted out. If the export offers a choice, take all fields — you can discard them later, but you cannot re-export from an account you have closed.
3Record how each audience opted in
Under GDPR and CASL you may have to demonstrate consent, and that provenance rarely survives a CSV round trip. Write it down now, while you still have the old platform's interface to check against.
4Screenshot your current deliverability numbers
Bounce rate, complaint rate, and delivery rate for the last few campaigns. Without a baseline you cannot tell whether a change after the move is the migration or the season.

Leaving	Where the suppression list lives
SendGrid	Suppressions, kept separately from Marketing Campaigns contacts — export bounces, blocks, spam reports, and unsubscribes as distinct lists
Mailchimp	Unsubscribed and cleaned addresses inside each audience; export per audience, and keep archived contacts too
Resend	Audience contacts carry unsubscribe state; export per audience
Amazon SES	The account-level suppression list, exported through the SES console or API — separate from anything in your own database
Postmark or Mailgun	Suppressions endpoint in the API, separate from any contact storage

If you cannot find it, ask support before you cancel. Reconstructing a suppression list after the account closes is not possible, and the consequence is mailing people who explicitly asked you not to.

Set up in parallel, not in sequence

Add the new provider's DNS records alongside the existing ones. DKIM is published per selector, so two providers coexist without conflict and both can sign mail as your domain at the same time. This is what makes the whole migration reversible.

Add the new provider's DKIM records. Leave the old provider's in place — they cost nothing and they are your rollback.
Merge SPF rather than adding a second record. One SPF record per domain, with an include: term for each service. Two records is a permanent failure, not a combination.
Leave DMARC alone. It is already published and applies to both providers equally.
Verify the domain at the new provider and confirm it reports SPF, DKIM, and DMARC all passing before sending anything.

Move marketing first

Campaigns are the right thing to move first because a delayed newsletter is an inconvenience and a delayed password reset is a support incident. It is also where the reputation risk concentrates, so it is where you want to be watching closely.

1Import suppression before contacts
In that order. If contacts land first, there is a window in which a send could reach a suppressed address, and a race condition is a poor reason to generate a spam complaint.
2Send one campaign to a few hundred engaged recipients
People who opened something in the last 30 days. Compare bounce and complaint rates against the baseline you recorded.
3Ramp roughly double per send
The new provider has no history for your domain, so volume still has to build. A full-list send on day one is the mistake the whole plan exists to avoid.
4Keep the old provider live until you are done
Cancelling early to save one month's fee removes your rollback at the exact moment you might need it.

Move transactional last

By the time you move receipts and password resets, the domain already has a delivery history at the new provider and you have seen its numbers. Point a small share of traffic at the new API first if your application can — a percentage of sends, or one low-risk message type such as a weekly digest — before moving password resets.

Keep the old provider's credentials in your configuration until the new path has run clean for a week. Rolling back should be an environment variable, not a deploy.
Re-point your bounce and complaint webhooks, and confirm events are arriving. A migration that silently stops feeding suppression is a slow-motion failure.
Check that your idempotency approach still holds. Most transactional APIs do not offer idempotency keys, so a retry after a timeout is your responsibility either side of the move.
Test the messages you never think about: password reset, email verification, receipt, and anything triggered by a webhook from a third party.

A two-week schedule

When	Do	Stop if
Day 1	Export suppression, contacts, and consent records	You cannot locate the suppression list
Day 1	Add DKIM, merge SPF, verify the domain	Authentication does not report as passing
Days 2–3	Import suppression, then contacts. Send to 200–500 engaged recipients	Bounces over 2% or any complaints
Days 4–7	Ramp campaigns, roughly doubling each send	Complaint rate over 0.1%
Days 8–10	Move a slice of transactional traffic	Delivery rate below your baseline
Days 11–14	Move remaining transactional, re-point webhooks	Any event stream not arriving
After 14 days	Cancel the old provider	You have not yet seen a full billing cycle of clean numbers

Two weeks is the shortest sensible version. If your list is large, unengaged, or has not been mailed in months, take four and treat it as a warm-up rather than a migration — the schedule is the same, just slower.

Questions people actually ask

Will changing email providers hurt my deliverability?: Temporarily and mildly, if you do it properly — your domain reputation follows the domain rather than the provider, so most of what you have built travels with you. What does not travel is the sending history at the new provider's infrastructure, which is why volume has to ramp. Migrations that damage delivery badly almost always did one of three things: lost the suppression list, misconfigured SPF, or mailed the whole list on day one.
Can I use two email providers at the same time?: Yes, and during a migration you should. A domain can publish multiple DKIM selectors, so both providers sign mail as you simultaneously. SPF is the only record needing care — merge both services into one record rather than publishing two.
What happens if I lose my suppression list?: You will mail people who unsubscribed, and a meaningful share will report it as spam rather than unsubscribing again. That is the worst possible way to start at a new provider, because complaint rate is the metric that gets sending suspended. If you have already closed the old account, the only remedy is to mail only recently engaged recipients for several weeks and rebuild suppression from the complaints you receive — which is as unpleasant as it sounds.
How long should I keep the old provider running?: Until the new one has run clean for at least a week of real traffic, and ideally a full billing cycle. The last month's fee is cheap next to discovering a problem with no way back. Keep the old credentials in your configuration too, so rolling back is a config change rather than an emergency deploy.
Should I move transactional or marketing email first?: Marketing first, always. Campaigns carry the reputation risk you want to observe under controlled conditions, and a late newsletter is survivable. Transactional mail is the traffic where failure is immediately visible to customers, so it moves last, after the domain has a delivery history at the new provider.

Run a migration in parallel, on the free plan

Verify your domain, import a consented segment, and send one real campaign while your current provider stays live. 2,000 emails and 500 contacts free, with no card and no expiry, which is enough to complete the whole evaluation.

Start free