Prepare the destination service and lower risk before changing nameservers or production records.
Applies to: Nameservers and DNS records
DNS tells internet services where to find a website, mail server or other service. Changes can be technically correct yet appear inconsistent for a time because recursive resolvers cache earlier answers until their TTL expires.
Before you start
- Export or record the complete current DNS zone.
- Make the new website, email and verification records ready before cutover.
Step-by-step
- List every current record, including less obvious TXT, SRV, CAA, DKIM and subdomain entries, not just the website A record.
- Create and verify the replacement zone before changing delegation. Keep record names and trailing-domain behaviour consistent with the DNS interface.
- At least one previous TTL period before the change, reduce TTLs on records that will move when the current provider permits it.
- Test the destination using a temporary hostname, hosts-file entry or application-specific preview without changing public DNS.
- Change only the planned nameservers or records and note the exact time. Keep the old service operating during the caching window.
- Query authoritative and public recursive resolvers, then test website, HTTPS, inbound and outbound email and any third-party verification.
- After stability is confirmed, restore sensible TTLs and retain the previous service until rollback is no longer required.
Confirm the result
- Authoritative DNS is consistent and users on old and new caches both reach a working service during transition.
Common problems
| Symptom | Likely cause | What to do |
|---|---|---|
| Website works but email stops. | MX, SPF, DKIM or autodiscover-related records were omitted from the new zone. | Compare the complete old and new zones and restore missing mail records immediately. |
| Some users reach a different server. | The previous TTL has not expired or authoritative nameservers disagree. | Check each authoritative server directly and keep both endpoints functional until caches expire. |
When to contact Tudor Internet
Open a ticket through the Customer Portal when the checks above do not resolve the issue, when an action is unavailable for your service, or when continuing could risk data loss or service interruption. Include the following so the request can be investigated efficiently:
- The full domain name
- The current and intended registrar or nameservers
- Any registry or transfer error shown
- Whether website or email service is currently live
Do not send passwords, private keys, full payment-card details, one-time authentication codes or unredacted identity documents in an ordinary support reply.
Related articles
- Change a domain’s nameservers
- Manage DNS records
- DNS propagation and caching
- Check DNS with dig, nslookup and public resolvers
- Create and troubleshoot A and AAAA records
Last reviewed: 2026-07-18.
