KoltrixEmail Migration Rollback Plan: When the Cut-Over Goes Wrong
Most email migrations go fine, but the bad ones go badly fast. A rollback plan: triggers, the DNS values to save, and how to reconcile mail after reverting.
On this page(8 sections)
- What "rollback" means for email
- Before the cut-over: make rollback possible
- Lower your TTLs early
- Record every current value
- Keep the old provider fully alive
- Publish authentication for both
- Decide who can call it
- Define rollback triggers in advance
- The rollback runbook
- Reconciling split mail
- After the rollback: find the cause
- A one-page rollback template
- Key takeaways
Every email migration plan has a section on how to move forward. Very few have a section on how to go back. That's fine right up until the morning the new provider rejects mail for an address you forgot, and the only plan anyone has is "fix it fast."
A rollback plan is cheap to write before the cut-over and almost impossible to improvise during one. Here's how to put one together.
What "rollback" means for email
Email migrations are mostly DNS changes. Mail servers around the world look up your domain's MX records to decide where to deliver. Rolling back means pointing those records back at the old provider and making sure the old provider will still accept the mail.
Two facts shape everything else:
- DNS changes are not instant. Resolvers cache records for as long as the TTL says. If your MX TTL is an hour, some senders will keep using the old answer for up to an hour after you change it, sometimes longer.
- Mail doesn't disappear during the overlap. It lands on whichever server the sender looked up. A rollback creates a window where some mail is on the new provider and some is on the old one. Your plan has to account for both.
Before the cut-over: make rollback possible
Most of a rollback plan is preparation. Do these at least a day ahead.
Lower your TTLs early
Drop the TTL on your MX records, and on SPF if you'll edit it, to 300 seconds at least 24 hours before the change. The old, longer TTL has to expire from caches before the short one takes effect, which is why this can't be done an hour before.
Record every current value
Copy the exact current DNS records into the runbook: MX hosts and priorities, SPF, DKIM selectors, DMARC, any autodiscover or CNAME records your old provider uses. Screenshot the registrar's DNS page too. "I'm pretty sure it was priority 10" is not a rollback plan.
Keep the old provider fully alive
Don't cancel, downgrade or delete anything on the old side until the migration has been stable for a while. The old mailboxes must still exist and still accept mail for every address, or there's nothing to roll back to.
Publish authentication for both
Make sure SPF includes both providers during the transition and both DKIM keys are published. That way mail sent from either side passes authentication, whichever way you end up.
Decide who can call it
Name one person who decides whether to roll back. In a small company that's often the founder. The worst outcome is two people making conflicting DNS edits at the same time.
Define rollback triggers in advance
Write down what would make you roll back, before emotions are involved. Good triggers are specific and observable:
| Trigger | Check | Roll back if |
|---|---|---|
| Inbound mail failing | Send test messages from Gmail, Outlook and one other provider to several addresses | Any core address bounces or doesn't arrive within 15 minutes, and the cause isn't fixable quickly |
| Outbound mail rejected | Send from the new provider to external test accounts | Messages are rejected or consistently land in spam |
| Missing addresses | Test every alias, group and shared address on your list | A critical address (support, billing) can't be created or fixed on the new side quickly |
| App or integration breakage | Trigger a password reset, an invoice email, a form submission | A customer-facing flow is broken and can't be repointed |
| Authentication failure | Check headers on test messages for SPF, DKIM and DMARC passes | DMARC fails for legitimate mail and the fix needs more than a record edit |
"Quickly" should have a number attached. Many teams use a fixed window, like 60 minutes of troubleshooting, after which they revert and investigate calmly.
The rollback runbook
When a trigger fires, work through this in order.
- Announce it. Tell the team in your chat tool that you're reverting, so nobody keeps testing or editing DNS.
- Restore MX records to the exact saved values from the old provider, priorities included.
- Restore SPF if you changed it in a way that excludes the old provider. Leave the new provider's include in for now; it does no harm.
- Leave DKIM records alone. Extra DKIM keys don't break anything, and removing them could cause failures for mail already sent.
- Verify propagation using a few public resolvers and an MX lookup tool such as our MX lookup. Expect a mix of old and new answers until the TTL passes.
- Send test messages to the old provider and confirm they arrive.
- Note the time of each change. You'll need it for reconciliation.
Reconciling split mail
After a rollback, some messages will have been delivered to the new provider during the window. They're real mail from real people and someone needs to deal with them.
- List the window. From the moment MX first pointed to the new provider until the rollback fully propagated, plus a margin.
- Check the new provider's mailboxes for anything received in that window. Shared addresses like
support@matter most. - Forward or reply from the right place. For a handful of messages, forwarding to the old mailboxes is fine. For more, export them if the new provider allows it.
- Tell anyone affected. If a customer's message sat unanswered for hours, a short apology is better than silence.
The reverse also applies if you roll forward again later: anything that arrives at the old provider after the second cut-over needs checking for a few days.
After the rollback: find the cause
Don't retry the next morning out of frustration. Work out what actually failed. Common causes:
- An address existed only as a forwarding rule or group at the old provider and wasn't recreated.
- A registrar silently appended the domain to a record, producing
mail.example.com.example.com. - SPF went over the ten-DNS-lookup limit after adding a new include.
- An app was sending through the old provider's SMTP with credentials that stopped working.
- Somebody's phone or desktop client was still configured for the old server and created confusion about what was "missing."
Fix the cause, update the runbook, and schedule the next attempt for a quiet time of day. Our Google Workspace cut-over checklist shows a forward order that pairs well with this rollback plan.
A one-page rollback template
Migration: example.com, old provider -> new provider
Decision owner: ______
Cut-over time: ______ TTL lowered on: ______
Saved records (old):
MX: ______ (priority __), ______ (priority __)
SPF: v=spf1 ______ ~all
DKIM selectors: ______
DMARC: ______
Triggers: [list from the table above]
Troubleshooting window before rollback: __ minutes
Rollback steps: announce, restore MX, restore SPF,
keep DKIM, verify, test, log times
Reconciliation owner: ______Key takeaways
- Rollback is mostly preparation: low TTLs a day early, saved DNS values, and an old provider kept fully alive.
- Agree on specific triggers and a time limit before the cut-over, and name one person who decides.
- Restore MX first, leave extra DKIM keys in place, and verify from several resolvers.
- Expect split delivery during the window and assign someone to reconcile it.
- Treat a rollback as information, find the real cause, and retry calmly.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
