How to change nameservers for a .uk or .co.uk domain

Changing nameservers tells the internet which authoritative DNS service should answer for your domain. It can affect the website, email and every subdomain, even when your immediate aim is only to move a website.

For a .uk or .co.uk domain, make the delegation change through the registrar or the domain-management route it provides. This is separate from a registrar transfer, and it does not require changing the registrant. Plan it as a DNS migration with a complete new zone and a way to recover.

Decide whether a nameserver move is necessary

If a new web host only needs an A record updated, keeping your existing DNS service may be simpler. You can point the website at the new server while retaining email and verification records where they already work.

A nameserver change is appropriate when you are intentionally adopting another DNS provider or a hosting platform that will manage the complete zone. Confirm whether the platform requires that move or merely offers it as a convenient option.

Do not confuse nameserver hostnames with the website's server IP address. An authoritative service supplies names such as its assigned ns hosts. Your hosting account may separately supply A or AAAA destinations for the website.

Step 1: inventory the current zone

Export all records from the active DNS provider, including less visible subdomains and TXT values. Record the current nameserver set, TTLs, DNSSEC status and the providers responsible for the website and mail.

Check for entries created by hosted tools: a shop, newsletter service, booking application or search verification may depend on records that do not look familiar. Ask the relevant owner before leaving any of them out.

Also record the current website and email behaviour. Knowing which canonical address, mailboxes and critical forms work before the move gives you a meaningful acceptance test afterwards. Otherwise an older application problem can be mistaken for a new DNS fault.

Step 2: build the new zone before changing delegation

Add the domain at the new DNS provider and recreate the required records. Automated imports can help, but inspect the result. Public lookups cannot reliably discover every record in a zone, so an automatic scan is not a complete backup.

Preserve MX and authentication records when the mail service is staying in place. Preserve subdomains and verification tokens too. If the website is moving simultaneously, change only the website destinations required by the migration plan.

Check the new provider's conventions. An at sign may mean the zone apex; some panels append the domain to a short record name. Review CNAME restrictions, TTL options and any proxy or alias features rather than assuming identical behaviour between interfaces.

Step 3: prepare DNSSEC correctly

A signed domain needs a coordinated DNSSEC transition. The parent DS information must match the signing arrangement used by the authoritative provider. If an old DS remains while the new provider serves different keys or an unsigned zone, validating resolvers can return SERVFAIL.

Follow both providers' documented migration process. Depending on their capabilities, this may involve a coordinated key transition or removing the old DS, allowing its cache lifetime to pass and re-enabling signing through the new provider afterwards.

Do not delete random DNSKEY or DS entries in an attempt to make a warning disappear. Record the old state, the planned sequence and the person responsible. For a business-critical domain, ask the DNS supplier for help with the exact transition.

Step 4: obtain the assigned nameserver set

Copy the nameservers assigned to your domain by the new service. Use the complete set and spelling shown in its dashboard. Another customer's nameservers or generic values from an old guide may not be valid for your account.

Ordinary third-party nameservers are different from private nameservers under your own domain. The latter can need parent-level glue arrangements so resolvers can locate them. If you are setting up private reseller nameservers, follow the registrar and hosting provider's specific instructions.

Test the new zone directly before the switch where the service permits it. For example, query a new authoritative server for the domain's A and MX data. Here dig @NEW_NAMESERVER example.com MX illustrates the method; replace both placeholders with your real values.

Coordinate a change with colleagues

Let the people who use the services know the change window and what to report. Ask for the affected hostname, exact error, time and network rather than a general statement that the internet is broken. A mobile connection and an office network may use different resolvers, so apparently conflicting reports can both be accurate.

Keep a dated timeline of delegation changes, record corrections and test results. This helps providers understand the sequence and prevents two administrators from making opposing changes. Assign one person to coordinate the migration until the acceptance checks are complete.

Step 5: change delegation through the registrar

1. Sign in to the account that controls the domain registration.
2. Select the exact domain and locate its nameserver or delegation settings.
3. Replace the old nameserver set with the complete assigned new set.
4. Review spelling and any DNSSEC-related state before submitting.
5. Save the change and retain the confirmation or change reference.
6. Keep the old DNS zone available for the planned transition.

Interface labels vary, so do not assume a particular button exists in every account. If the registrar restricts changes or an approval is pending, use its support process rather than repeatedly submitting the same request.

Changing NS records inside the old zone alone is not a substitute for updating parent delegation through the registration system. Confirm what the registrar has actually submitted, not just what one local zone displays.

Step 6: verify delegation and services

Check the domain's NS answers and compare them with the assigned new set. A trace lookup can help identify the parent delegation. Query the new authoritative servers for the key records and then compare answers from recursive resolvers.

Caches can retain the earlier delegation or record answers for their remaining lifetime. This is why keeping old and new zones consistent during the transition matters. There is no single guaranteed completion time for every network.

Visit the main website and www over HTTPS. Test essential pages and forms. Send an external message to the domain and reply from it; confirm the expected email authentication results through the mail platform's tools where available.

Diagnose failures without undoing the plan blindly

If the new zone has a missing record, correcting it may be safer than reversing the entire delegation. A rollback itself is another cached change. Use the recovery plan and compare the likely effect of each action.

Close the migration deliberately

Once delegation and services are stable, save the new zone export and update your service inventory. Review account access, billing and alert contacts. Retire the old DNS service only when it is no longer needed for the transition or other domains.

A registrar transfer is a separate task. On 30 October 2026, ordinary .uk registrar changes still use the current TAG-based process; Nominet's announced standardisation is scheduled for 9 February 2027. Do not combine an unnecessary registrar move with a DNS migration merely because the website is changing.