Michael O.23 Jun 2018Updated 14 Sep 2026Domains & DNS7 min read

DNS Change - tips and tricks to avoid problems

On this page

TL;DR

  • DNS changes can disrupt websites and email if not planned correctly.
  • Lower TTL values before making changes to speed up propagation.
  • Always test DNS records and services on the new server before switching.
  • Monitor propagation and email flow carefully after the change.
  • Preparation and patience are the keys to a smooth DNS update.

Changing a DNS record for a domain may seem like a non-issue to some people, but the implications are often not realized. At HostAfrica, we realize that these can have a large impact on your business. Register co.za domain today.

Effects of an unplanned or badly done DNS change can range from your website being unreachable to a total disruption of all emails. Changing name servers have to be orchestrated properly and correctly to avoid any outages as far as possible. The steps involved are not complicated but must be done correctly and in order. Find out what is a parked domain.


How to change NS

When you change server, or before changing any record there are a few preparation steps that will help the process.

Reduce TTLs

  • Lower all A Record TTL's (Time To Live) to 600 or even 300 seconds. A TTL is the amount of time that a record is allowed to be cached before it is looked up again. The standard TTL is 14400 seconds (1 day). Thus any change will take a day to reflect. To avoid this, we reduce the TTL on all A records. These must all be changed back after the move, so record the original values.
  • If changing DNS servers, lower the TTL on NS records as well as all TTL's in the SOA. The NS (NameServer record) is the record that points to your nameservers. These records must also be reduced to around 600 seconds. The SOA (Start of Authority) defines maximum cache time, maximum time before expiry, and the SOA's own TTL. These are usually set to high values. We can reduce these all down to a range between 3600 seconds ( 1 hour ) and 600 seconds ( 10 minutes ). These must all be changed back after the move, so record the original values.

Check Setups

  • Ensure that all new servers are set up. If you're moving your DNS to a different Name Server, test to see if the records have been set up. We do this using either nslookup or dig. The nslookup syntax is (works in Linux and Windows command line): "nslookup mydomain.dom new.nameserver.dom". nslookup also has a few query switches. These are: nslookup -q=A (A record), nslookup -q=NS (NS record), nslookup -q=SOA (SOA record), nslookup -q=ANY (full lookup). Also, ensure that your website is up and working on the new server and that all mailboxes have been created. If you are doing a cPanel migration, these will all be created during the migration process.
  • MX records: If you are moving to a different server, a good solution is to create a secondary MX with a higher priority value (i.e. lower priority) pointing to the new server. If your existing MX record is priority 5, set the new MX to priority 10. Do this on the existing DNS record. Once you have moved, shut down mail processing for that account or shut down the server (if it is a server move). That way, any email heading for the old MX will fall over to the new MX and get sent to the new address.

The DNS change

The actual change is never as dramatic as most people imagine. Change the DNS, reload the nameserver and it's done. For a nameserver change, you have to send a change request to the domain registrar. This is where it's important to ensure that the records exist on the new DNS servers, as many registrars will refuse a change if the new records cannot be found.

Post-DNS change cleanups

Check that DNS resolves correctly. Check DNS propagation using sites such as DNS Checker will tell you how the new DNS change is progressing. If possible, shut down services on the old server or suspend the account so that people do not access the wrong server. Ensure that the email is not still going to the old server or put forward on the old server. If any email is on the old server, synchronize the mailboxes to the new server or ask your hosting provider if they could do it for you.

Send and receive a few test emails using a third-party mail address such as Gmail. This will tell you if any records are not updated. Above all, be patient. Migrations or changes can go smoothly, but they often have small issues. These are often due to non-standard setups. It may even be that some of your users are using the server IP address or name to access their email instead of the domain.

All will be well in the end. Address each issue as it happens and ensure that you sort out that issue before moving on to the next one. Be prepared and the change will most likely be a smooth one.


Common DNS Change Mistakes (and How to Avoid Them)

Even experienced administrators run into DNS-related issues. Here are some of the most common mistakes made during DNS changes and how to prevent them.

Forgetting to Lower TTL Values

Leaving TTL values at default levels (often 14,400 seconds or higher) can cause DNS changes to take a full day or longer to reflect.

How to avoid it:
Lower TTL values at least 24 hours before making changes, and restore them once everything is stable.

Updating DNS Before the New Server Is Ready

Pointing DNS to a server that isn’t fully configured leads to broken websites, missing mailboxes, and failed services.

How to avoid it:
Verify all DNS records, websites, and email services on the new server using tools like nslookup or dig before making any live changes.

Overlooking Email Configuration

MX records, mail routing, and mailbox synchronisation are often treated as an afterthought.

How to avoid it:
Set up mailboxes in advance and use temporary secondary MX records to ensure no emails are lost during the transition.

Making Multiple Changes at Once

Changing nameservers, DNS records, and server configurations simultaneously makes troubleshooting difficult.

How to avoid it:
Apply changes in controlled stages and confirm each step before proceeding to the next.


FAQ

What is a DNS record?

A DNS record tells the internet how to route traffic for a domain, including where the website is hosted and how email should be delivered.

Why should TTL values be lowered before a DNS change?

Lowering TTL values reduces caching time, allowing DNS changes to propagate faster and minimising downtime during the transition.

Can DNS changes cause email downtime?

Yes. Incorrect MX records or incomplete mail server setups can stop emails from sending or receiving during a DNS change.

How long does a DNS change take to fully propagate?

Most DNS changes propagate within a few hours, but full global propagation can take up to 24–48 hours depending on TTL settings and ISP caching.

What tools can I use to verify DNS changes?

Tools like nslookup, dig, and online services such as DNS Checker can be used to confirm DNS resolution and propagation status.

Should I shut down the old server after a DNS change?

Yes, once propagation is confirmed. This prevents users and email traffic from accidentally reaching the old server.


Final Note

DNS changes are rarely dangerous on their own, problems arise when they’re rushed or poorly coordinated. With proper preparation, validation, and post-change checks, most DNS updates can be completed with little to no disruption.

Learn More About Managing DNS

Changing DNS records is easier when you understand how DNS setup, zones, propagation, and record checks work together. These related guides will help you avoid common mistakes, troubleshoot changes, and keep your domain settings accurate:

Find the perfect domain name

Search and register your domain in seconds, with free DNS management.

Avatar for Michael O.

Michael O.

The Author

Michael is the founder, managing director, and CEO of HostAfrica. He studied at Friedrich Schiller University Jena and was inspired by Cape Town's beauty to bring his German expertise to Africa. Before HostAfrica, Michael was the Managing Director of Deutsche Börse Cloud Exchange AG, one of Germany's largest virtual server providers.