A DNS provider migration without breaking email means you copy MX, verification TXT, and sending records to the new zone, match them in public, then change NS. If you change NS first with an empty zone, mail dies. Exclusive MailerZ MX must exist on the destination zone before delegation moves. TTL on NS is a clock. Dual MX is not the safety story. The copied exclusive set is.
Quick answer for dns provider migration email
DNS hosts change. MX ownership should not.
RFC 1035: NS move is the cut. Records must already exist at the destination.
Copy MailerZ dashboard values again. Do not copy a typo from the old panel.
Lower NS TTL if you can wait.
Do not add a second vendor MX as a migration trick.
Start free and treat a test domain as a rehearsal if you have never moved NS.
Authoritative mail transport is defined in IETF RFC 1035 — Domain names. Product path: docs, migration planner, and troubleshooting.
User problem and decision criteria
Decision criteria: can you write the new zone before NS, leftover rows, who owns registrar, TTL.
Empty new zone plus NS change is an outage.
Two zones with different MX during NS convergence is a split.
Agencies should screenshot both zones.
Registrar lock and IAM matter.
No inboxing from a successful NS change.
Do not migrate NS on a product launch day if you can wait.
Ghost zones at the old provider after you leave still confuse people—document public NS.
Technical mail flow
Clone records → optional check against new NS → change registrar NS → wait TTL → public resolvers agree → probe.
Rollback is old NS plus old zone still intact. Keep it until probes pass.
MailerZ hop does not change if MX hosts stay the same.
HOLD and aliases stay on MailerZ. DNS move is not a map move.
Step-by-step setup / decision path
- Export old MX/TXT. Screenshot.
- Create new hosted zone. Paste exclusive MailerZ set.
- Compare row by row.
- Lower NS TTL if possible. Wait.
- Change registrar NS to the new set.
- Query public NS and MX.
- Probe inbound.
- Decommission old zone after a quiet period.
Classify the next failure before a second DNS edit.
HOLD unknown unless you wrote a FORWARD reason.
Quote live pricing before promising alias counts.
Failure modes and proof
NS first, empty zone: outage.
Different MX on new zone: split or wrong hop.
Leftover copied too: you cloned a split.
Self-send.
Registrar not actually changed.
Old NS TTL ignored.
Deleted old zone immediately: no rollback.
Invented hosts.
Inboxing claim.
Moved aliases? You should not.
Two v=spf1 cloned.
Wrong account zone.
MailerZ workflow and product boundary
MailerZ is custom-domain aliasing and forwarding with optional paid send-as. Secuno LLC operates mailerz.net. The app is mail.mailerz.net. Not Workspace, not IMAP, not an open relay, not a campaign ESP.
Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. Exclusive MX. Hold unknown on Free. Copy SMTP host, port, and TLS or STARTTLS from the dashboard when you send.
Free: one domain, three aliases, one seat, fourteen-day store, fifty outgoing a month, no send-as. Solo forty dollars a year, fifteen aliases, ninety-day store, one hundred outgoing, five send-as per hour. Starter eight or eighty. Business nineteen or one hundred ninety. Agency thirty-nine or three hundred ninety. Quote pricing. No SOC 2, ISO, HIPAA, SLA, or inboxing percentage.
Cost, alternatives, and trade-offs
An empty-zone NS cut is a brand incident.
Keeping old zone a week is cheap rollback.
Agencies: NS migrations are a named change.
TTL wait is calendar.
Cloned leftover MX is a cloned outage.
Rehearsal domain is cheap.
No fake SLA.
Dashboard copy beats a bad export.
Operational depth
Keep the old zone read-only until public NS match the new. That is rollback.
If the new provider clamps TTL, plan the wait.
Email records are a short list. Copy them by hand from the dashboard if the export looks dirty.
Website A/AAAA/CNAME are a parallel project. Do not mix the change windows if you can avoid it.
MailerZ does not move when NS moves if MX hosts stay correct.
Two-resolver checks after NS.
Document who can change registrar NS. That is production.
No ports in DNS.
HOLD still on.
No SOC 2 because you changed AWS to Cloudflare or the reverse.
Probe after convergence.
Write the date you will delete the old zone.
Clone the exclusive set, then move NS
A DNS host change is not an MX owner change. MailerZ should already be the only inbound hop. You copy that exclusive MX set, the verification TXT, and sending TXT if you send, onto the new provider’s zone. You prove the new zone answers those records when queried against its nameservers. Then you change NS at the registrar. Empty new zone plus NS cut is an outage. Dual MX “during the move” is leftover MX.
Export from the old zone first. Screenshots of Route 53 or Cloudflare are not an export if you cannot read priorities and hostnames. Write every MX line. Write TXT names and values. Write NS you are leaving. That packet is rollback.
Create the same exclusive set on the new zone while the old NS still serve the world. Traffic does not move until delegation moves. You can take an hour to match records without an inbound outage.
Query the new nameservers directly if your tools allow it, before NS changes. If the new zone still has registrar placeholders or old Google MX you forgot to delete, you will cut to leftovers. Fix the new zone first.
TTL on NS is the clock after the registrar change. Some resolvers still talk to the old host. Both zones must have the same exclusive MailerZ MX during that tail. If the old zone still has leftovers and the new zone is clean, the tail is split delivery. Clean both before you cut NS.
Do not lower MX priority on one side and call it overlap. Overlap is identical exclusive sets on both zones, then NS. Priority games are leftover MX.
Apex and WWW are website records. Do not “simplify” them in the same change window as MX unless you like mixed tickets. Email first. Website second. Or the reverse, on another day.
After NS agrees on two public resolvers, probe from another mailbox. Empty history is leftover MX on whichever zone still wins, a missing alias, or a Free hold. Destination 5xx after 250 is Gmail. Do not revert NS to debug a destination refuse.
Send-as is unchanged if the hop did not change. Do not rotate SMTP because you moved Cloudflare to Route 53. 550 is still plan and identity. Free cannot send.
Multi-domain agencies: one domain per NS cut. Blending four clients into one “DNS migration Friday” is how one empty zone takes down a portfolio.
Registrar lock and the person who can edit NS are the real risk. If that human is on vacation, you do not have a migration. You have a hope. Write the owner.
If the new provider offers “free email,” decline it. That product is leftover MX waiting to be published beside your clone. Delete it if the wizard already added it.
Keep the old DNS account until probes pass and NS TTL is done. Cancel last. Same rule as an email-provider keep: login, not a second MX owner.
Monthly after the move: leftover lookup. Helpful restores love a new console. Route 53 and Cloudflare both make aspmx easy to add. The hop cannot stop you.
NS cut day, written as a script
Minus two days: export old zone, lower NS TTL if you can wait, create new zone, paste exclusive MailerZ MX and TXT, delete any wizard leftovers, query new NS directly, screenshot both zones’ MX as identical exclusive sets.
Minus one day: tell the team not to edit email records on either zone. Website edits wait. SPF does not get a “helpful” second include.
Cut hour: change NS at the registrar. Copy the new NS list. Do not change MX. Do not add Google. Do not accept a registrar free-email upsell in the same session.
Plus one hour: two public resolvers. If they still show old NS, wait remaining TTL. If they show new NS and leftover MX, you cloned wrong. Fix the new zone. Do not flap NS.
Plus one hour also: probe from another mailbox. Unique subject. Hop row. Destination copy. If empty and MX is exclusive on both public answers, look at alias HOLD or destination 5xx. If MX is leftover, you did not clone exclusive.
Plus one day: leftover check again. Someone will have used the new console’s email template. Delete it.
Plus one week: cancel or keep the old DNS login per your keep rule. MX owner did not change. The old login is rollback for NS, not a second hop.
Failure: new zone had aspmx because import. Public NS moved. Split. Fix: delete aspmx on the new zone. Do not add MailerZ a second time. Exclusive means one owner.
Failure: edited Cloudflare while NS already pointed at Route 53. Old console is a diary. Two resolvers would have said so.
Failure: mixed website CNAME batch revert restored old MX. Split the tickets next time.
Send-as: unchanged. If someone “refreshed SPF” with two hops’ includes, permerror. One include for the hop that sends. MailerZ dashboard values.
Free HOLD still applies. A DNS host change does not create aliases. If billing@ never existed, it still HOLDs.
Agencies: one domain per cut hour. A spreadsheet of NS changes is fine. A single apply across twenty zones is how you empty one zone and take down a client.
No inbox SLA because NS moved. Propagation is RFC 1035, not a vendor mood. Empty history is still leftovers, HOLD, or destination refuse.
Start free on a spare domain if you need to practice clone-then-NS. Do not practice on the registrar that prints invoices.
Worked scenarios for DNS host moves
You are leaving Cloudflare DNS for Route 53 because the website team wants a different CDN story. Email is not the reason. Clone exclusive MailerZ MX and verify TXT into the new zone first. Confirm the new nameservers answer those records when queried directly. Then change NS at the registrar. If you change NS first, the new zone is empty and mail dies.
A registrar 'email included' product rewrites MX when you touch nameservers. After the NS change, re-query. Delete the gift MX. Exclusive MailerZ only. The migration is not done because the NS row looks modern.
TTL on NS is 48 hours and someone changes NS after cloning records with a 10-minute MX TTL. The MX TTL does not save you from NS cache. Read the NS TTL. Wait that clock. Probe after the world agrees, not after the console agrees.
An agency moves ten client zones in one afternoon and clones nine correctly. The tenth is the empty default zone. That tenth is the donor domain. Use a checklist per zone, not a mood. Dual MX is not the safety story. The copied exclusive set is.
Old provider stays as a secondary DNS. If it still serves an old MX set, some resolvers will see leftovers depending on how you delegated. Secondary that serves a different MX is leftover MX with extra architecture. Match the sets or do not secondary.
Someone copies A records and forgets MX. The site lives. Mail dies. The migration runbook must list email records by name: MX, verify TXT, SPF, DKIM if you send. Website records are a different heading.
Practice and anti-patterns when changing DNS hosts
Practice: export, clone, query the new NS directly, then delegate. Anti-pattern: delegate, then 'quickly add MX' while caches already point at emptiness.
Practice: exclusive MailerZ set on both old and new zones before NS moves. Anti-pattern: adding Google on the new zone 'as backup during cut.' That is a split on arrival.
Practice: read NS TTL. Anti-pattern: treating MX TTL as the only clock.
Practice: probe from a third mailbox after public resolvers show the new NS and the exclusive MX. Anti-pattern: self-send from the destination Gmail five minutes after the registrar save.
Practice: screenshot old and new. Anti-pattern: a single Slack message that says 'moved DNS, should be fine.'
Practice: disable registrar email products that rewrite MX. Anti-pattern: celebrating NS then discovering Professional Email republished overnight.
Practice: HOLD and named aliases stay as they were. Anti-pattern: 'cleaning up' aliases during a DNS host move so you cannot tell which outage you caused.
Operator closeout after NS moves
Closeout shows registrar NS, two public resolver NS, two public resolver MX, and a probe ID. If any leftover host appears, the move is not closed.
Closeout names the old DNS host and whether it is fully decommissioned. A leftover login that still serves the old zone is a landmine for the next intern.
If send-as exists, confirm SPF and DKIM still publish on the new zone. Copy dashboard values. Do not invent records. Free has no send-as. Do not start send-as in the same hour as NS if you can avoid stacking failures.
Website owners confirm A and AAAA, separately. Do not let a site 404 conversation rewrite MX 'while we are in the panel.'
Agencies file one packet per zone. Bulk closeout is how the tenth zone stays empty.
Schedule a morning re-query. Wizards republish. The first night is not the proof. The next morning is.
Edge cases in DNS provider migration
DNSSEC is on and the new host is not signing yet. Some resolvers will SERVFAIL. Mail dies in a way that looks like MX. Coordinate DNSSEC or turn it off with a plan. Do not ignore it.
The new host flattens CNAME at apex in a way that fights MX. Read their docs. Do not stuff an IP into MX to dodge the fight.
You moved NS but the old host still has a hidden primary that slaves update from. The clone you typed in the UI is overwritten hourly. Kill the hidden primary or you will watch MX flap.
A child zone for mail.example.com exists with its own NS. You cloned the parent and forgot the child. If anything still points there, you migrated the wrong layer.
Internationalized domain or unexpected extra spaces in NS hostnames at a cheap registrar. Copy carefully. A typo NS is an outage that looks like 'propagation.'
The business wanted to migrate email providers and DNS hosts in the same window. Unstack them. One change class per window. This article is DNS host. Email cutover is a different runbook.
Field notes from DNS moves
The quiet moves clone first. The loud moves delegate first. Loud is cheaper in the first ten minutes and more expensive in the first ten hours.
Registrar UIs lie about 'email connected.' Believe resolvers. RFC 1035 is what the world uses.
Website agencies will treat DNS like a theme setting. Give them a two-row checklist: site records, mail records. Mixed checklists get half-done.
Null MX leftover from a brand pause will travel with a sloppy export. Review the export. Delete null if you want mail.
Use /tools to see public MX after NS. Use /troubleshooting when the new host looks right and senders still hit the old one. Cache is a clock, not a vibe.
No ports in DNS. If someone asks to 'move 587,' they want SMTP, not NS. Separate tickets.
Handoff memo for the registrar owner
Old NS, new NS, when registrar changed, NS TTL you read, exclusive MX set, and who may touch the zone. If two people can edit two hosts, you will split again.
The memo forbids empty-zone delegation. Juniors will still try to 'switch first so we do not forget.' The sentence has to exist.
Link /docs and /email-forwarding. DNS host is not a mailbox. Destinations stay. MailerZ stays. Only the zone operator changes.
If a secondary exists, the memo says both sides serve the same exclusive MX. Different MX on a secondary is leftover MX.
Morning re-query owner is named. Wizards do not care that you were tired last night.
Acceptance criteria for a DNS host migration
New NS are public. MX on those NS is exclusive MailerZ. Verify TXT present. Leftovers gone. Two resolvers agree.
A third-mailbox probe succeeded after the NS TTL window. Self-send was not the gate. Header From intact.
Old host cannot silently win. Either decommissioned or serving the same set as a true secondary.
SPF and DKIM still correct if you send. Dashboard copy, not folklore. Free still has no send-as.
Website records independently verified. No MX edits during a site hotfix without a new ticket.
One packet per zone. No bulk vibes.
Operations review of DNS host changes
Count how many zones moved this quarter and how many had an empty-zone incident. If the number is not zero, the runbook is not being used. Fix the habit, not only the zone.
Review registrar products that rewrite MX. Disable them in writing. They will come back during a domain renewal.
Review DNSSEC status. A move that 'worked on the laptop' and fails at a validating resolver is a mail outage.
Review who has credentials on the old host. Leftover credentials are leftover authority.
Quote /pricing if the move was an excuse to add domains. DNS host changes do not raise Free's one-domain cap.
Start free on a lab domain and rehearse clone-then-NS. The checkout domain is the wrong first rehearsal.
Quarterly review after you change DNS hosts
Are NS still where you think? Registrars get 'helpful.' Re-read them.
Did any zone pick up gift MX? Delete. Probe.
Is the old host still serving a divergent set? Kill it or sync it.
Did anyone stack an email-provider cut into a DNS-host cut? Unstack the next one.
Does the export still match the dashboard MX? Copy again if MailerZ guidance changed.
Author: MailerZ editorial, Secuno LLC. Review when host UIs, pricing, or scope change.
Closing notes on clone-then-delegate
A DNS provider migration without breaking email means the exclusive MailerZ set exists on the destination zone before NS moves. Query the new nameservers directly. Then delegate. Wait the NS TTL. Probe from a third mailbox. Dual MX is not the safety story.
Empty-zone delegation is the failure mode that looks like courage. It is not courage. It is an outage.
Start free, clone the records, then move NS. Product path: /docs, /tools, /troubleshooting.
Clone checklist you can print
Old zone export: NS, MX lines, verification TXT, SPF/DKIM/DMARC if sending, record names exactly.
New zone create: same exclusive MailerZ MX, no wizard email, no aspmx, no null MX unless you intend refuse.
Direct query new NS: MX equals old exclusive set. If not, stop. Do not change registrar NS.
Website records: copy if this is also a web move, but apply email first or website first, not both in the panic window.
Registrar NS cut: paste new NS. Decline free email. Screenshot.
Two public resolvers: NS and MX. Tail is TTL. Both zones must stay exclusive-identical during the tail.
Probe: other mailbox, unique subject, hop row, destination copy.
Plus one day: leftover check on the new console.
Keep old DNS login until TTL and probes done. Cancel last.
Do not: dual MX, priority overlap, SPF two includes, SMTP rotate, self-send as proof, empty new zone, import Google MX and forget to delete.
Do not: edit the old console after NS moved and call it production.
Agencies: one domain per cut. Spreadsheet rows are cuts, not one blast.
Free HOLD unchanged by NS. Missing aliases still HOLD. DNS host is not an alias factory.
Send-as unchanged. 550 is plan and identity. Free cannot send. Route 53 will not fix From.
RFC 1035 NS. RFC 5321 MX. Dashboard hosts. Exclusive. Probe.
Rollback NS only if the new zone is wrong and the old zone is still exclusive-identical. Rollback MX to Google is a class change.
Monthly leftover check after the new console becomes muscle memory.
Start free on a toy domain to practice clone-then-NS if the team has never done it. Not on the invoice domain.
FAQ
- What is the safest way to handle dns provider migration email?
- Export MX and TXT from the old authoritative zone. Create the same exclusive MailerZ set on the new provider. Verify with a resolver against the new nameservers if you can. Then change NS at the registrar. Wait. Probe.
- Does this require a new mailbox?
- No. MailerZ is not IMAP. Keep Gmail or Outlook unless you need a suite for other reasons.
- Will it work with Gmail or Outlook?
- Yes as destinations. Self-send is not proof. Use a third mailbox and open original.
- What DNS records are involved?
- Exclusive MX, verification TXT, one SPF if you send-as. Leftover MX is a hard stop. Dashboard values only for sending.
- What should I test before production?
- A uniquely titled probe from an unrelated provider to each public alias. Confirm Header From and hop history.
Key takeaways
- Clone exclusive MX first.
- Then move NS.
- Keep old zone for rollback.
- Do not clone leftovers.
- Wait NS TTL.
- Probe after public agreement.
- Aliases stay in MailerZ.
- One vendor MX.
Conclusion
Move DNS under email, not over it. The hop stays MailerZ if MX stays exclusive and correct.
Start free, keep the map, and treat NS as a second checklist after records exist.