How to change domain nameservers without losing website or email settings

Nameservers tell the internet where a domain’s authoritative DNS answers are managed. Changing them moves that responsibility to another DNS service. It does not, by itself, copy the website, move mailboxes or transfer the registration to a different registrar.

The safest change begins before the registrar’s nameserver field is edited. Prepare the destination DNS zone, preserve all required records and plan how to check the result. That preparation matters even when the website and email are hosted by different companies.

Know which part of the setup you need to change

The registrar manages the domain registration and usually provides the route for changing its delegation. The authoritative DNS provider holds records such as A, AAAA, CNAME, MX and TXT. Hosting serves the website or application, while a mail provider may operate email separately.

You can use different suppliers for each role. If only the web server address changes and you want to retain the current DNS service, updating the relevant A, AAAA or CNAME record may be sufficient. A full nameserver change is appropriate when you intend to move authoritative DNS management.

Do not replace DNS simply because a new host has sent nameserver details without first understanding the intended arrangement. Ask which records need changing and which service should remain responsible for email. Keep ownership and renewal control of the domain clear throughout.

Prepare a complete DNS inventory

Export the current zone where the provider supports it, and keep a readable record as well. Inventory the root domain, www, subdomains, mail routing, verification records, service records and any special routing features. Automated import tools can miss records, so compare their results with the source.

• Website A and AAAA records, including whether an old IPv6 address remains active.
• CNAME aliases and subdomains used by applications, shops or support systems.
• MX records and the hostnames they reference for inbound email.
• SPF, DKIM and DMARC records used for mail authentication.
• TXT verification, CAA and relevant SRV records.
• DNSSEC status and any DS record managed at the registrar.

Record current TTLs and any provider-specific features that do not translate into a standard record. Keep account recovery details secure and ensure you can still access the registrar if the domain’s own email temporarily fails. Avoid putting credentials in a shared migration document.

Create and test the destination zone first

Add the domain to the new DNS service and reproduce the required records accurately. Use the exact nameservers assigned to that zone or account. Example nameservers in a tutorial are not a substitute for the values your provider issued.

Check the new authoritative servers directly where tools and expertise permit it. Confirm website and mail answers, record names, priorities and values. A copied DNS zone should not accidentally include an obsolete server or omit a verification record used by a payment or email platform.

If the website itself is moving, test the destination hosting separately through a supported preview method. A correct DNS answer cannot repair an application that has not been copied or configured. Keep transactional data and mailbox migration plans distinct from the delegation change.

Coordinate DNSSEC deliberately

DNSSEC adds signed DNS information and a chain of trust through the parent zone. A DS record pointing to keys from the old DNS service can cause validation failures after delegation changes. Do not copy a DS record blindly into a new arrangement.

Follow the documented transition procedure for the old DNS provider, new DNS provider and registrar. Depending on supported features, this may involve a controlled removal and later re-enablement or another coordinated migration. Verify each stage and its timing. Disabling a control without understanding how it will be restored is not a complete plan.

Update nameservers at the current registrar

1. Sign in through the registrar’s known address and complete the required authentication.
2. Select the exact domain and locate its nameserver or DNS-delegation settings.
3. Choose the supported custom or external nameserver option if appropriate.
4. Replace the old set with the complete set supplied by the new authoritative DNS provider.
5. Review spelling and save the change, completing any required confirmation.
6. Record the time, previous values and new values for verification or recovery.

Do not combine nameservers from unrelated providers as an improvised backup unless those services explicitly support the same zone arrangement. Otherwise different visitors can receive inconsistent answers. Keep the old DNS service available during the transition rather than deleting the zone immediately.

Updating through telaHosting

If telaHosting is the current registrar or provides the relevant domain-management route, open the authenticated domain account and select the domain’s nameserver settings. Use the current account interface or support guidance for that service. If another company is the registrar, the delegation normally needs to be changed there.

For a site hosted with telaHosting while DNS remains elsewhere, obtain the required website records and update them at the authoritative DNS provider. Preserve independent mail records. A domain registration, website-hosting account and external DNS zone may be connected without being managed in the same panel.

Notes for other familiar providers

GoDaddy: its current help guide explains changing the domain’s nameservers in the domain account. Select the intended domain and review its delegation settings, following the current confirmation steps. Changing the provider also changes where you manage the authoritative zone.

Namecheap: use the domain’s nameserver configuration in the domain-management area and follow its current documentation for external nameservers. Domain delegation and individual host-record editing are different operations.

Former Google Domains registrations: Google Domains registrations migrated to Squarespace. Use the account of the domain’s current registrar rather than following an obsolete Google Domains screen sequence; a domain may since have moved again.

Cloudflare: distinguish using Cloudflare DNS from registering through Cloudflare Registrar. Registrar has specific nameserver requirements, so it should not be treated as a generic panel that always permits arbitrary external nameservers. Review its current documentation before planning a move.

Allow for caching and check the actual answers

DNS changes become visible as delegation and record caches update. There is no single guaranteed worldwide propagation interval for every change. Lowering a relevant record TTL sufficiently in advance can help a planned record update, but it does not instantly clear existing caches or control every delegation cache.

Check the authoritative delegation and records as well as answers from more than one recursive resolver. Use a different network where helpful and record the returned values. Repeatedly switching providers because one device shows an old page can make diagnosis harder.

Troubleshoot website and email problems separately

If the website fails, compare the intended A, AAAA and www answers, confirm the hosting is ready and review HTTPS for the actual hostname. An old AAAA record can send some visitors to the wrong destination even when the A record looks correct.

If mail is disrupted, check MX records, their targets and mail-authentication records at the new authoritative service. Confirm the mailboxes still exist at the mail provider. Changing DNS does not copy messages or create accounts.

If validation fails, investigate DNSSEC and DS coordination rather than waiting indefinitely. Once the service is stable, verify key forms, payment callbacks and email sending and receiving. Keep the migration record and remove obsolete services only after the transition and data checks are complete.

Keep a simple handover record

After verification, record the registrar, authoritative DNS provider, hosting provider and mail provider with their business account owners. Include where records are now edited and which recovery route is used. Store configuration evidence securely and omit passwords. Give future administrators enough context to change one service without accidentally replacing another. Review the record when suppliers change, because the familiar company taking the hosting payment may still be different from the company answering DNS or handling email.