I want to use other name servers for my domain, how to proceed?
To use your own name server settings instead of the default name servers of hosting.fr, you need to assign other name servers to the domain. Attention: Do not make this change in the DNS zone, but only in the manner described below directly on the domain, otherwise your domain will no longer be accessible.
- Select the “Products” item in the menu on the left.
- In the “Products” menu, select the sub-item “Domains”.
- Under the domain to be modified, select the “Show details” item. If you manage a large number of domains, you may need to click on “Show all” to get a complete overview of your domains.
- In the “Name Servers” section, click on “Edit”.
- Click in the “Name Servers” line and select “Use custom name servers”.
- Enter the desired name servers and finalize the change with the “Save” button.
Attention: Please first ensure that the chosen name servers are accessible and that a correctly configured DNS zone for the domain is created there.
As soon as the domain is correctly accessible via the new name servers, we recommend deleting the DNS zone in the hosting.fr system, as it will no longer be queried and this could lead to confusion.
Why and when you should change nameservers
Changing nameservers means you are delegating your domain’s DNS management to a different DNS provider. In practical terms, the DNS zone (A/AAAA records, MX records, TXT records, etc.) will be served by the nameservers you set up. This is a powerful change: it can move not only your website routing, but also email delivery and third-party services that rely on DNS verification.
Typical, legitimate reasons to change nameservers include moving your website to a new hosting provider that manages DNS, using a specialized DNS platform (for advanced routing, CDN, DDoS protection, or DNS automation), or consolidating DNS management across multiple domains and services. You should avoid changing nameservers “just to test,” because a nameserver switch can take time to propagate fully and may temporarily break website and email if the new DNS zone is incomplete. If your goal is only to change a single record (like an A record), it is often safer to update records in the current DNS zone rather than switching nameservers entirely.
Checklist before changing nameservers
A nameserver change is safest when you prepare the new DNS zone first, then switch delegation. The most common cause of downtime is switching nameservers while the new provider’s zone is missing key records. Use this checklist to reduce service interruptions:
Export or document current DNS records from the existing provider (A/AAAA, CNAME, MX, TXT, SRV, and any special records).
Recreate the full zone at the new DNS provider before switching nameservers. Do not copy only the website records—include email and verification records too.
Email is critical: confirm MX records and required TXT records (SPF, DKIM, DMARC) are present at the new provider, otherwise inbound/outbound email can fail or degrade.
Check subdomains you actively use (e.g., www, mail, autodiscover, cpanel, custom app subdomains).
Lower TTL in advance (where possible) on key records at the current provider to speed up the transition window.
Plan timing: switch during a low-traffic period and keep access to both providers’ control panels during the transition.
Confirm ownership/verification dependencies: services like Google/Microsoft, payment providers, and SSL validation may depend on DNS TXT records—ensure these are included.
This preparation prevents the most common “site/email down after nameserver change” scenario.
What to expect after changing nameservers
A nameserver change is not instant. Once you update the delegation at the registrar, DNS resolvers across the internet will begin using the new nameservers. Still, the switchover can occur at different times for different users and networks. During this period, some visitors may resolve your domain using the old DNS zone while others use the new one. That means you can see mixed behavior: the website might load for you but not for others, or email might behave inconsistently until the transition stabilizes.
The most crucial operational impact is that the active DNS records will be whichever zone your resolver is using at that moment. If the new zone is incomplete, you may experience website downtime (missing A/AAAA/CNAME records), broken redirects, missing subdomains, or email delivery issues (missing MX/TXT records). This is why a whole pre-migration DNS zone is essential.
To set expectations internally, communicate that nameserver switching is a controlled change with a transition window. Avoid making additional DNS changes during propagation unless you are correcting a mistake, because changes made to the old zone will not reach users who already switched to the new zone, and vice versa.
Troubleshooting common issues after changing nameservers
If something breaks after a nameserver change, the root cause is usually either missing records in the new zone or DNS caching. Work through these standard checks:
Website not loading
Confirm the new DNS zone has the correct A/AAAA record (or CNAME) for the root domain and www.
Verify you did not forget common subdomains used by your setup.
Check if the issue is device/network-specific; that often indicates DNS cache propagation rather than a universal outage.
Email problems (cannot receive or send)
Confirm MX records exist at the new provider and point to the correct mail host.
Confirm TXT records for SPF/DKIM/DMARC were copied. Missing TXT records can cause deliverability issues even if mail “works.”
If you use third-party email (Microsoft 365, Google Workspace), ensure all vendor-required records are present.
Domain works for some users but not others
This is typical during propagation. Compare results from different networks (mobile data vs office Wi-Fi).
Clear the local DNS cache only as a last-mile test; the real fix is to ensure the new zone is correct.
SSL warnings after the change
- If traffic now reaches a different server than before, the certificate may not match the domain. Ensure the new hosting target is correct, and TLS is configured for the domain.
If the new DNS zone is confirmed correct, the remaining issue is usually the caching/propagation time. If the new zone is missing records, fix the zone first; waiting will not resolve missing DNS entries.