How to change DNS records and nameservers, without killing your email
Changing your nameservers replaces your entire DNS zone. Every record you had, including the MX records that deliver your business email, stops applying the moment the new nameservers take over. If you have not recreated those records at the new provider first, incoming email stops arriving.
It does not bounce loudly. Senders often get nothing at all, or a delayed failure hours later, so the first sign is usually a customer asking why you never replied. VentraIP states this plainly in its own documentation: "Once a DNS change is made the existing records are removed". GoDaddy words it as "changing your nameservers may break existing connections to your website or email".
Copy your MX and TXT records before you touch the nameserver field. The next section shows you how, and it takes about two minutes.
Most of the panic around DNS changes comes from one confusion: people treat "change my DNS" and "change my nameservers" as the same job. They are not. One is a scalpel and the other replaces the whole organ. Getting the distinction right usually turns a risky migration into a two minute edit, and it is the difference between a website that switches over cleanly and a business that loses a week of email.
First, work out which change you actually need
Your nameservers decide who holds your DNS records. Your records decide where each service points. Almost every request we get for "change our nameservers" turns out to need a single record edit instead.
| What you want to do | What you actually change | Risk to email |
|---|---|---|
| Point the website at a new host or server | The A record (and www) | None. Email is untouched. |
| Move email to Microsoft 365 or Google Workspace | MX plus the TXT records they give you | This is the email change. Do it deliberately. |
| Verify a domain for a third party service | One TXT record | None. |
| Add a subdomain for an app or shop | One A or CNAME record | None. |
| Move DNS hosting itself to Cloudflare or a new host | The nameservers | High. The whole zone is replaced. |
Read that table honestly and the useful conclusion is uncomfortable for anyone selling hosting: if all you are doing is pointing your website somewhere new, you do not need to move your nameservers, and you should not. Change the A record, leave everything else alone, and your email cannot break because you never touched it. A host that tells you a simple site move requires their nameservers is describing their preference, not your requirement.
Copy your records before you touch anything
Do this even if you are only changing one record. It costs two minutes and it is the only thing standing between a mistake and a rollback.
If you have a terminal (macOS and Linux have one built in), these four commands capture almost everything that matters:
| Command | What it captures |
|---|---|
dig MX example.com.au +short | Your mail routing. This is the one that ends businesses. |
dig TXT example.com.au +short | SPF, domain verification tokens, and anything else stored as text. |
dig A example.com.au +short and dig A www.example.com.au +short | Where the website points. |
dig NS example.com.au +short | Which nameservers are live right now, which is also how you confirm the change later. |
Paste the output into a text file and keep it until the migration is confirmed working. If you would rather not use a terminal, an online DNS lookup tool will show you the same records, or take a screenshot of every page of your current DNS zone. A screenshot is less convenient than text but far better than nothing.
dig can only show you records you know to ask for. Two categories are routinely missed and both break silently:
DKIM selectors live on subdomains like selector1._domainkey.example.com.au, so a plain TXT lookup on the root domain will not show them. Lose these and your outbound mail starts failing authentication and landing in spam, which looks like a deliverability problem rather than a DNS one. Get the selector names from your mail provider.
Autodiscover and SRV records point Outlook and phones at the right mail server. Losing them does not stop mail, it stops clients configuring themselves, which generates a fortnight of "my phone won't connect" tickets.
The reliable move is to export the full zone file from your current provider if they offer it, rather than reconstructing it from lookups.
What each record type does
| Record | Points to | Used for |
|---|---|---|
A | An IPv4 address | The website. The most commonly edited record. |
AAAA | An IPv6 address | Same job as A, for IPv6. Safe to omit if your host has not given you one. |
CNAME | Another hostname | Aliases, usually www or an app subdomain. Cannot coexist with other records on the same name. |
MX | A mail server hostname, with a priority number | Incoming email. Lower priority number means tried first. |
TXT | Free text | SPF, DKIM, DMARC, and domain ownership verification. |
NS | A nameserver hostname | Delegation. Set at your registrar, not usually inside the zone. |
SRV | A service, port and host | Autodiscover, VoIP, and similar service location. |
Verified control panel steps
Control panels change, sometimes without notice, so every path below was checked against the provider's own current documentation on 15 August 2026. If what you see on screen does not match, trust the panel and the provider's own help article over this page, and tell us so we can correct it.
VentraIP (VIPcontrol)
To change nameservers: log in to VIPcontrol, click My Services then the Domains tab, click the DNS button for the domain, open the Custom Nameservers tab and click Enable, enter at least two nameservers, then click Set Custom Nameservers. If your hosting is with VentraIP, use the VentraIP tab instead of Custom Nameservers.
To edit individual records: the same path as far as the DNS button, which opens the table of records for that domain.
VentraIP's documentation warns that the existing records are removed when the change is made, and quotes up to 24 hours for the change to reflect. Source: modifying the nameservers on a domain name registration and managing DNS records within VIPcontrol.
Crazy Domains
To change nameservers: open the domain in your Crazy Domains account, click the Name Servers tab, click ADD on the Name Servers table, replace the existing nameservers with the new ones, then click SAVE RECORD.
Two things worth knowing. Their default nameservers are ns1.crazydomains.com and ns2.crazydomains.com, and while those are in place your DNS is managed in their Account Manager, so pointing the domain elsewhere means that zone stops having any effect. Their panel also validates nameservers as you type and can briefly freeze the field, so their own advice is to type the names in a text editor first and paste them in. Source: change the name servers of your CD domain.
GoDaddy
To change nameservers: sign in to your Domain Portfolio, select the domain to open Domain Settings, then choose DNS and Nameservers.
If Domain Protection is on the domain, GoDaddy requires identity verification before it will accept the change, so have your two step verification method to hand or the change will stall halfway. Source: change my domain nameservers.
Cloudflare
Cloudflare is a common destination for DNS, and it has an important distinction most guides get wrong.
The full setup is the normal one: Cloudflare assigns you two nameservers, you set them at your registrar using the steps above, and Cloudflare becomes authoritative for the whole zone. Cloudflare scans your existing records when you add the domain, but that scan is not guaranteed to be complete, so check the imported zone against the records you captured earlier before you switch. Source: set up a primary zone.
The partial or CNAME setup lets you keep your existing DNS provider and proxy only selected subdomains. It is the low risk option when you cannot move the zone. The catch that costs people an afternoon: it is only available on Business or Enterprise plans, and not at all on domains registered with Cloudflare Registrar. Plenty of tutorials describe it as though anyone can use it.
We have deliberately left out registrars whose current documentation we could not reach and verify on the review date, rather than publish a click path from memory. Netregistry and Webcentral in particular have moved their help content more than once. If yours is not above, get the steps from your provider's own current help article, and apply the same rule regardless of provider: capture the zone first, rebuild it at the destination, then switch.
Verify it worked, in the right order
-
Confirm the delegation changed
dig NS example.com.au +shortshould return the new nameservers. Until it does, nothing else you check means anything. -
Confirm mail routing survived
dig MX example.com.au +shortshould match what you captured before the change, exactly. Compare them line by line rather than glancing at both. -
Send real mail in both directions
Send an email from an outside address (a personal account on another provider) to the domain, and confirm it arrives. Then reply from the domain. A resolving MX record proves DNS is right, not that mail is being delivered.
-
Check the website last
It is the most visible thing and the least likely to fail quietly. If DNS is right and the site still will not load, that is a different problem: see the website down triage.
If some people see the change and others do not, nothing is wrong. That is cache expiry, and how long it takes is entirely predictable once you know the TTL.
If email has already stopped
Act on this quickly, because most mail servers give up retrying after a few days and undelivered mail is genuinely lost, not queued forever.
- Put the MX records back first. Recreate them at whichever provider is currently authoritative, using your captured copy. If you did not capture them, your mail provider can tell you exactly what they should be; Microsoft 365 and Google Workspace both publish yours in their admin console.
- Do not revert the nameservers as a reflex. If the new zone is nearly right, fixing the missing records is faster than switching back and waiting out another TTL. Reverting doubles the outage when the old zone is also incomplete.
- Then fix SPF, DKIM and DMARC. Mail may start flowing while still failing authentication, which sends it to spam. That looks like the problem is unfixed when it is half fixed.
- Ask senders to resend. Anything that hard bounced is gone. Anything still in a sending queue will arrive once the records are right.
If the mail in question is Microsoft 365 and it is arriving but landing in the wrong place, or your website contact form has stopped delivering, that is a different fault path: see contact form email not arriving in Microsoft 365.
The short version
Decide first whether you need a record change or a nameserver change, because the honest answer is usually a record change and that carries no risk to your email. If you genuinely do need to move nameservers, capture the existing zone before you touch anything (MX and TXT above all, plus DKIM selectors and SRV records, which plain lookups miss), rebuild it fully at the destination before switching, then verify by sending real mail rather than by loading the website. Lower the TTL a day ahead if the change is planned. And treat any control panel instruction, including the ones on this page, as something to check against the provider's own current documentation, because panels move.
General guidance only. If your domain carries live business email and you are not confident, get someone to do it with you rather than after you. We would rather answer a question than recover a mailbox.
Where this comes from
The primary sources behind the above, so you can check any of it yourself rather than take our word for it:
- VentraIP: modifying the nameservers on a domain name registration, the source of the click path and of the warning that existing records are removed.
- Crazy Domains: change the name servers of your CD domain, the source of their click path, default nameservers and paste advice.
- GoDaddy: change my domain nameservers, the source of their click path and the Domain Protection verification step.
- Cloudflare: set up a primary zone (full setup) and set up a partial zone (CNAME setup), including the plan restriction on partial setups.