Your new website is ready and the developer says it only needs a DNS change to go live. The same domain also routes email and identifies authorized senders. If those instructions disappear during the move, the website can launch perfectly while enquiries, invoices and password resets stop arriving.
This guide helps you decide whether you are editing a few records or moving the whole DNS service, build an inventory before anything changes, plan around caching instead of a promised deadline, and confirm that mail still works afterwards. If you are still recovering account access, start with our guide to regaining control of your domain and hosting.
For a Joomla site staying on the same domain, our Joomla server-move guide covers the files, database, private rehearsal and final data transfer that should happen before these DNS changes.
1. Decide which change you are actually making
DNS for your domain is answered by whichever provider your nameservers point to, the authoritative DNS provider. That provider holds the zone: the full set of records for the domain. A website move usually touches only the records that send visitors to the web server. Changing nameservers is a different and larger operation. It hands the whole zone to another provider, and anything not recreated there stops answering.
As of 2026, Cloudflare's DNS record reference describes A and AAAA records as mapping a name to IPv4 or IPv6 addresses, and MX records as required to deliver email to a mail server. A CNAME points one hostname at another hostname. These are the records a typical website move edits.
| Change | What it touches | Email risk | Typical reason |
|---|---|---|---|
| Edit A or AAAA records for the root domain or www | Website address, possibly a shared mail target | Low only after checking mail dependencies | New host gives you an IP address |
| Edit or add a CNAME for www or a subdomain | One hostname | Low only after checking the hostname has no mail dependency | Host or platform gives you a target hostname |
| Change nameservers at the registrar | The entire zone moves to a new provider | High if any record is missed | Moving DNS management to a new host or proxy |
| Accept a host's default DNS template | Replaces your zone with the host's starting records | High; templates may route mail elsewhere | Rarely right for an established business |
If the new host only needs an address or a CNAME, edit those records where DNS already lives and leave the nameservers alone. The case against that approach: if your current DNS provider is hard to manage, or controlled by someone who has left, staying put keeps a weak point. In that case move the zone deliberately, as its own project, rather than as a side effect of a launch. If the reason is putting a proxy in front of the site, our Cloudflare and shared hosting guide explains what that adds and what it does not.
2. Inventory every record before anything changes
Before editing anything, export or copy the complete zone from the current provider through an account the business controls. Many providers offer a zone-file export; where they do not, record each entry by hand with its type, name, value, MX priority and TTL. Store the copy privately with the date. Use it as the migration and rollback checklist.
Pay particular attention to records with no visible website function:
- MX records, which route incoming mail to your mailbox provider.
- The SPF record, a TXT record beginning
v=spf1, listing the services allowed to send for the domain. - DKIM records, usually on a name containing
_domainkey. As of 2026, Microsoft's DKIM documentation notes Microsoft 365 publishes them as CNAME records while other systems may use TXT. - The DMARC record, a TXT record on the
_dmarcname. - Verification TXT records for search, mailbox and other services, plus any SRV records and subdomains.
Check where mail actually goes, not only what the MX records say. An MX record names a mail server hostname, and that hostname has its own address records. On some hosting plans the mail hostname, or even the root domain itself, points to the same server address as the website. If you change that A or AAAA record to the new web host, incoming mail can follow it even though the MX record never changed. Before editing any address record, check whether an MX target uses it, and ask the mailbox provider if you are unsure. The website's contact form is a separate risk: it may send through the old host's mail server or a sending service whose settings and credentials do not move with the site files, so test it on the new host before cutover.
If you are moving to a new DNS provider, do not rely on its automatic import alone. As of 2026, Cloudflare's setup documentation states that its quick scan is not guaranteed to find all existing records and asks you to review them before changing nameservers. Its import and export guide covers moving a standard zone file; other providers document their own process. Either way, compare the new zone line by line against your export.
3. Plan around caching, not a fixed deadline
Resolvers cache DNS answers for the record's time to live (TTL). Until a cached copy expires, some visitors and mail servers keep using the old answer while others already see the new one. That is why a change can look finished on your phone and unfinished in a customer's office. It is also why one universal waiting period, such as 48 hours for every change, is not accurate.
If a record you plan to change has a long TTL, lower it at least one full old TTL before the cutover so cached copies expire sooner. As of 2026, Cloudflare's migration preparation notes suggest doing this 24-48 hours ahead. The case against: lowering TTLs on records you are not changing adds lookups without benefit, and it does not shorten caching of the delegation itself, which the domain's registry typically controls. Raise TTLs again once the move is stable.
4. Coordinate DNSSEC before moving nameservers
DNSSEC signs DNS answers so resolvers can detect forged responses, and a DS record held at your registrar anchors the chain of trust. Ordinary record edits within the same provider typically leave that chain intact. Moving nameservers can break that chain if the new provider uses different signing keys. As of 2026, Cloudflare's DNSSEC key documentation explains that you cannot simply keep an existing DS record when migrating to Cloudflare, and its DNSSEC overview describes the supported migration paths. Note any DS record in your inventory and follow the sequence that both providers document, in their order. Do not switch DNSSEC off as a general fix. If either procedure is unclear for your domain, ask both providers through their official support channels before you change anything.
5. A cutover checklist that protects email
- Confirm that business-controlled accounts manage the registrar, DNS, mailbox provider and new host.
- Export or copy the full zone, and note any DS record at the registrar.
- Decide whether you need record edits only or a nameserver move. Prefer record edits when the current provider is manageable.
- Check whether any MX target or mail hostname shares an address you plan to change.
- If moving nameservers, recreate every record at the new provider and compare it with the export.
- Lower TTLs on the records you will change, at least one old TTL ahead.
- Agree the DNSSEC sequence with both providers if a DS record exists.
- Make the change at a quiet time and record what changed, when and in which timezone.
- Test the website from two networks, send mail to and from an outside mailbox, and submit one clearly marked test through the contact form.
- Keep the old DNS service and hosting active until tests pass and cached answers have had time to expire.
When not to move DNS at all: if launch is close and the inventory is incomplete, postpone the change until mail dependencies are understood, or limit it to verified web-only records and schedule the DNS migration separately. If customers report that the site works for some people and not others, our intermittent outage guide explains what to record. The guides index and tools cover the next decisions.
— Editorial team. Facts current as of 2026; we revise guides when the ground shifts.
Frequently Asked Questions
How long until DNS changes take effect?
It depends on the TTL of the old record and on resolver and device caches, so there is no single universal figure. Some visitors see a change within minutes while others keep a cached answer longer, and nameserver changes also depend on registrar processing.
Will moving my website move my email?
Not necessarily. Email is routed by MX records, but changing an address used by an MX target can redirect incoming mail even when MX stays unchanged. The site's form may also depend on sending settings at the old host.
Should I let my new web host manage my DNS?
Only if you have a reason to move and have recreated every existing record there first. Accepting a host's default zone can replace working mail and verification records, so keep DNS where it is when that provider is manageable.