If your website is down after a DNS change, it is easy to assume something has broken. In many cases, the issue is temporary: some visitors are still being sent to the old server, while others are already reaching the new one. That uneven behaviour is usually caused by DNS propagation and DNS cache hits.

However, DNS changes can also expose genuine configuration errors, such as an incorrect A record, a missing CNAME record, incorrect nameservers, or overwritten MX records. This guide explains the main checks in plain English, so you can work out whether to wait, fix a record, test from another network or contact support.

Why this matters

For a business website, even a short disruption can affect enquiries, online orders, bookings and customer trust. DNS is also connected to email delivery, so a rushed hosting move or domain transfer can accidentally interrupt mail if the correct MX records are not preserved.

Giraffe Hosting Limited supports UK businesses with hosting, WordPress hosting, managed cloud hosting, VPS hosting, domain registration and domain transfer services. Since 2007, the team has helped website owners make hosting and DNS decisions easier to understand, especially during migrations where calm troubleshooting matters.

DNS in simple terms

DNS, or the Domain Name System, is often described as the Internet's's phonebook. Instead of requiring visitors to remember a server IP address, DNS translates a domain name into the technical destination used by browsers and mail systems.

When you change hosting, move a website, transfer a domain or update a DNS record, you are changing the instructions that tell the Internet's where to send traffic. The most relevant DNS terms are:

• Nameservers: These tell the Internet which DNS provider is authoritative for your domain's records.
• A record: This points a domain or subdomain to an IPv4 address, commonly used for the main website.
• CNAME record: This points one hostname to another hostname, often used for subdomains such as www.
• MX records: These tell mail systems where to deliver email for your domain.
• TTL: Time To Live. This tells DNS resolvers how long they may cache a result before checking again.
• DNS cache: A saved DNS answer held by your device, browser, router, internet provider or public DNS resolver.

If you want more background on common DNS configuration pitfalls, Giraffe Hosting's guide to DNS management mistakes is a useful supporting read.

What is DNS propagation?

DNS propagation is the period during which DNS changes are being picked up across different networks and resolvers. After you update nameservers or records, not every internet provider, device, or DNS resolver immediately sees the new answer.

Some sources describe DNS propagation as typically taking 24–48 hours, although larger DNS services may update more quickly in many cases. The important point is that propagation is variable, not a fixed guarantee. It can be affected by TTL values, caching policies, server load, old cached results and sometimes DNS server errors.

This is why your website may load on your phone using mobile data but not on your office Wi-Fi. It can also explain why your developer sees the new site, while a customer still sees the old one.

Common reasons a website appears down after a DNS change

1. Cached DNS is still sending visitors to the old server

If your DNS had a long TTL before the change, some resolvers may continue using the previous answer until that cached result expires. This can make the site appear inconsistent across locations.

2. Nameservers were changed before the new DNS zone was ready

Changing the nameserver transfers the DNS record authority to another provider. If the new DNS zone does not contain the correct A, CNAME, MX and other required records, the website or email may stop working.

3. The A record points to the wrong IP address

The A record for the root domain, such as example.co.uk, needs to point to the correct web server IP address. A single-digit error can send visitors to the wrong destination or nowhere useful.

4. The www record is missing or incorrect

Many businesses use both example.co.uk and www.example.co.uk. If the root domain works but the www version does not, check whether the www CNAME or A record is present and pointing to the intended destination.

5. Email records were overwritten during the move

When moving hosting or changing nameservers, it is common to focus on the website and accidentally replace the existing mail records. If MX records are missing or wrong, email delivery can be disrupted even when the website loads correctly.

Quick checklist: what to check first

How to test without advanced command-line tools

You do not need to be a systems administrator to run useful checks. Start with simple comparisons:

1. Try a different network. Test the website on office broadband, mobile data and a home connection if possible.
2. Try a different device. Check a phone, a laptop and another browser to rule out local browser caching.
3. Check both versions of the domain. Test example.co.uk and www.example.co.uk.
4. Use an online DNS propagation checker. These tools can show whether different global resolvers are returning different results.
5. Check your DNS panel carefully. Compare the lwithords against the providedils supplied by yng provideprovidersail provider.
6. Ask someone outside your network to test. A colleague, developer or support team may see a different result because their DNS cache is different.

If your issue appeared during a registrar move, Giraffe Hosting's domain transfer troubleshooting guide explains other common transfer-related problems, including locked domains and DNS errors.

How TTL affects DNS changes

TTL stands for Time To Live. It tells DNS resolvers how long they can keep a DNS answer before asking for a fresh one. A shorter TTL can help changes be picked up more quickly, while a longer TTL may reduce repeated lookups but can make changes appear slower during a migration.

Ideally, reduce the TTL before a planned hosting move or DNS change, then wait for the previous TTL period to pass before making the final switch. The elimination removes propagation, because caching behaviour can vary, but it can reduce the chance of old results lingering longer than expected.

Protecting email during DNS or hosting changes

Email disruption is one of the most avoidable problems in migration. The key is to treat email DNS records as separate from website DNS records.

• Record your current MX records before making changes. Take a screenshot or export the DNS zone if your provider allows it.
• Check whether the email is hosted with your website host, Microsoft 365, Google Workspace, or another provider. Your website move does not always mean your email should move.
• Do not overwrite MX records when changing nameservers. Recreate the correct mail records in the new DNS zone before or immediately after the nameserver change.
• Preserve related mail records where required. Some email providers also use TXT, SPF, DKIM, DMARC, CNAME or autodiscover records.
• Test sending and receiving after the change. Check both internal and external mail, and monitor for bounce messages.

If you are consolidating domains, moving hosting, or reviewing ownership details, Giraffe Hosting provides domain services and WHOIS/RDAP lookup resources to help website owners better understand registration and domain information.

When is it DNS, and when is it hosting?

A DNS issue usually means visitors are not being sent to the correct place. A hosting issue means they can reach the server, but the server, website files, application, database, or SSL setup is not responding as expected.

As a rough guide:

• Likely DNS: Different networks show different results, the domain points to an old IP address, nameservers are not as expected, or the www and non-www versions behave differently.
• Likely hosting: DNS points to the correct server, but the site shows a server error, a blank page, a database error, an SSL warning, or an application-specific problem.
• Possibly both: The domain was moved to new nameservers before the new hosting account, SSL certificate and website files were fully ready.

When to contact support

Contact your hosting provider, DNS provider, or registrar if the site remains unavailable after a reasonable propagation period and multiple networks are experiencing the same issue.

• The site is still unavailable after a reasonable propag,ation period and multipare experiencingetworks shissuesame problem.
• You are unsure which nameservers should be a
• The A record, CNAME, or MX records do not match the ones provided by your provider.
• Email has stopped working after a change to the nameserver or hosting.
• You suspect DNSSEC, registrar settings or a domain transfer issue may be involved.
• The domain resolves correctly, but the hosting account shows errors for the server, SSL, database, or application.

When raising a support ticket, include the domain name, the time the change was made, the records you changed, screenshots of the DNS zone if possible, and examples of what you see from different networks. That context helps support teams diagnose the issue faster.

Frequently Asked Questions

Why can a website appear down after changing DNS?

A website can appear down because some DNS resolvers still have old cached results, while others have already picked up the new records. It can also happen if nameservers, A records or CNAME records have been entered incorrectly.

How long can DNS propagation take?

DNS propagation times vary. The supplied sources commonly describe changes as taking 24–48 hours, although larger DNS services may update faster. TTL values, caching policies and DNS server behaviour can all affect the result.

Which DNS records should I check first?

Check the nameservers first, then the A record for the root domain, the CNAME or A record fowwwfor the domain, and the MX records for email. These are the most common records involved when a website or email stops working after DNS changes.

What is TTL and why does it matter?

TTL means Time To Live. It tells DNS resolvers how long they may cache a DNS answer before checking again. A high TTL can mean older results remain in use for longer after a change.

How can I avoid email disruption when changing DNS?

Before changing nameservers or hosting, copy your existing MX records and any related mail records. Recreate them in the new DNS zone and test sending and receiving afterwards. Do not assume a website migration should also move your email.