MX Cutover Timeline: What Happens During DNS Switch
Changing MX is not “instant mail to the new server for everyone.” Senders cache DNS. Some resolve in minutes; stubborn resolvers can take hours (rarely longer if TTL was high). Understanding that window — and preparing before you publish — is how MailShrine cutovers stay boring.
For what an MX row is, start with MX records explained. For the full migration playbook, see migrate without losing mail.
Real-life example: Palm Courier
Kemi flipped MX for Palm Courier at 10:00 after a successful IMAP sync. Her phone received new customer OTPs on MailShrine by 10:12. A warehouse vendor’s mail server still delivered to the old cPanel host at 14:40 because their resolver honored the previous 24-hour TTL. She had left the old mailbox online — those two messages were forwarded manually. Without that overlap, the POD photos would have vanished.
What actually happens when you edit MX
| Actor | Behavior |
|---|---|
| Your DNS host | Serves the new MX answers |
| Recursive resolvers | May cache the old answer until TTL expires |
| Sending servers | Query their resolver, then open SMTP to the MX hostname they got |
| Old mail host | Keeps accepting mail until nobody resolves to it (or you shut it off) |
| New mail host | Accepts mail as soon as someone resolves to it |
Website A records are unrelated — email and web can cut over independently (domain vs email hosting).
Recommended timeline
T−72 to T−24 hours
- Finish IMAP history (checklist).
- Lower TTL on MX (and auth TXT you will change) to 300–600 seconds if your DNS host allows.
- Confirm MailShrine mailboxes exist and webmail login works.
- Announce the cutover window to staff.
T−1 hour
- Delta-sync IMAP once more.
- Freeze risky password resets.
- Screenshot current MX for rollback.
T0 — publish
- Delete legacy MX (Google / Microsoft / cPanel).
- Add MailShrine MX exactly as shown in Domains.
- Update SPF/DKIM for outbound (SPF, DKIM).
- Cloudflare users: keep mail hostnames DNS only (grey cloud).
T+15 minutes to T+2 hours
- Lookup MX from multiple public resolvers.
- Send tests from Gmail/Yahoo to each critical address.
- Check MailShrine verification status.
- Peek at the old host for stragglers — do not panic if a few still land there.
T+24 to T+48 hours
Most leftover cache should be gone (propagation guide). Keep the old host accepting mail.
T+7 to T+14 days
If the old Inbox is quiet, decommission old mail accounts and clean leftover SPF includes.
Downtime: myth vs reality
| Claim | Reality |
|---|---|
| “MX change means email downtime” | Correctly prepared cutovers have no planned outage — both hosts can accept until cache drains |
| “Everyone switches in 5 minutes” | Only if TTL was already low and caches are cooperative |
| “Raising TTL after cutover is optional” | Raise TTL again once stable so DNS stays efficient |
Dual MX to two different providers without a plan splits mail randomly — avoid accidental dual-production.
Palm Courier cutover checklist
- History synced before T0Completed
- TTL lowered earlyCompleted
- MailShrine MX published; legacy MX removedCompleted
- SPF/DKIM alignedCompleted
- External tests received on new hostCompleted
- Old host monitored for late deliveriesCompleted
- Old host retired after quiet weekNot completed
Registrar help: Namecheap / Cloudflare / GoDaddy.
Rollback posture
If you published the wrong hostname:
- Restore the screenshot MX immediately.
- Keep MailShrine mailboxes — history is not lost.
- Re-read values from the product UI (blog examples go stale).
Next steps
Citations & References
- Reference: RFC 5321 — SMTP
- Reference: ICANN: What is DNS?
- Reference: Cloudflare Learning Center: What is TTL?
- Reference: Google: Set up MX records for Google Workspace
Written by Samira O., Email Authentication Specialist. Samira times MX cuts so late DNS caches do not become lost invoices.
