A website can be online, the hosting account can be healthy, and yet visitors still see an error page. That is often a DNS problem. This website DNS troubleshooting guide helps you identify where the connection has failed, fix the correct setting, and avoid making changes that create a longer outage.
DNS, or the Domain Name System, directs a domain name to the server or service behind it. When a record is missing, pointed at the wrong destination or not yet updated across the internet, your website, email or subdomains may stop working. The fastest fixes come from checking each part of that chain in the right order.
Start by identifying the actual symptom
Before changing a record, establish what is failing. A browser message such as “server not found” usually means the domain cannot be resolved. A website that loads an old version or reaches the wrong server points to an outdated DNS record, cached result or incorrect nameserver. If the main site works but email does not, the issue is more likely to involve MX, SPF or related mail records.
Try the domain on a mobile connection as well as your usual Wi-Fi. If it works on one network but not the other, local DNS caching may be the cause. You should also test the domain with and without `www`, because these are commonly configured as separate records.
Keep a note of the exact error, the affected hostname and when the issue began. This gives you a useful baseline if you need technical support and prevents guesswork later.
Check where DNS is managed
A common source of confusion is assuming that DNS is managed by the company hosting the website. That is not always the case. Your DNS zone is usually controlled in one of two places: the domain registrar or a separate DNS provider selected through the domain’s nameservers.
Look up the domain’s active nameservers. If they point to your hosting provider, DNS records are normally edited in the hosting control panel. If they point to a third-party service, make changes there instead. Editing records in an inactive DNS zone has no effect, however correct those records look.
Nameserver changes deserve particular care. When you switch nameservers, the new provider must contain every record the domain needs, not only the website record. Recreating the A record but forgetting MX, SPF, DKIM or verification records can interrupt email delivery and other connected services.
Work through the key DNS records
Once you know the active DNS provider, inspect the records for the affected hostname. The following record types solve most website and email DNS faults:
- A record: Connects a hostname, such as `example.co.uk`, to an IPv4 server address.
- AAAA record: Does the same for IPv6. An incorrect AAAA record can cause failures for some visitors even when the A record is correct.
- CNAME record: Aliases one hostname to another. It is often used for `www` or service-specific subdomains.
- MX record: Directs email for the domain to the right mail server.
- TXT record: Holds supporting information, commonly SPF, DKIM, DMARC and domain verification values.
For a standard website, the root domain often uses an A record pointing to the hosting server’s IP address, while `www` uses either a CNAME to the root domain or its own A record. The correct arrangement depends on the hosting platform, so use the values supplied for your account rather than copying an old record from another site.
Avoid placing a CNAME record and an A record on the same hostname. They conflict. Equally, check for duplicate A or AAAA records. Multiple records can be intentional for load balancing, but unplanned duplicates may send visitors to different servers.
Do not overlook IPv6
IPv6 is easy to miss because many users still reach a website through IPv4. If an AAAA record points to an old server, visitors on IPv6-capable networks may see a connection error while everyone else sees the site normally. If your hosting service has not provided an IPv6 address, remove an obsolete AAAA record rather than leaving it in place.
Confirm the records resolve publicly
The DNS panel shows what you have entered. A public DNS lookup shows what the internet can currently see. Both checks matter.
More technical users can run `nslookup example.co.uk` or `dig example.co.uk` from a command line. Check the returned IP address against the server address shown in your hosting account. You can also query a specific record, such as `dig MX example.co.uk`, when diagnosing email.
If public results show the correct record but the website is still down, DNS may no longer be the problem. Check the hosting account status, server IP, website files, SSL configuration and application errors. DNS directs traffic to a destination, but it cannot repair a site that is unavailable on the server itself.
Allow for DNS propagation, but set realistic expectations
DNS changes are not always instant. Each record has a TTL, or Time to Live, which tells resolvers how long they can retain the previous answer. A record with a 3,600-second TTL may continue to return an old value for up to an hour after a change, while some provider and browser caches can add further delay.
Nameserver changes can take longer because they must update at the registry level and then be collected by DNS resolvers worldwide. It is sensible to allow up to 24 to 48 hours for a nameserver change to settle fully, although many updates appear sooner.
Do not keep changing records during propagation unless you have found an actual mistake. Repeated edits reset the process, make diagnosis harder and can leave different visitors reaching different destinations. Make one verified correction, record the time, then monitor the public result.
Clear local caches after verifying the public result
If public DNS is correct but your own device still reaches an old server, clear the local cache. Restarting the router can help, as can flushing the operating system’s DNS cache. Browsers may also hold cached redirects or HSTS settings, so test in a private browsing window or another browser.
This is particularly useful after a migration. Your computer may remember the old IP address while customers using other networks already see the new site.
Check DNS after a website migration
Website migrations are a frequent trigger for DNS issues because timing matters. The safest approach is to build and test the new site before changing the live DNS record. Lower the TTL a day or two before the planned switch where possible, then update the A record or CNAME only when the new account is ready.
Keep the old hosting service active until you have confirmed that the domain resolves to the new server, the website loads over HTTPS, forms work and email is unaffected. Cancelling the old account immediately can turn a minor propagation delay into a complete outage.
For email, preserve existing MX and TXT records unless you are deliberately moving mail as well. A website migration does not normally require changes to mail routing.
When the problem is an SSL warning, not DNS
A certificate warning can look like a DNS failure, particularly after moving a domain. Often, DNS is working well enough to send visitors to the server, but the server is presenting the wrong SSL certificate or has not yet issued one for the domain.
First confirm that the domain and `www` record point to the correct hosting account. Then check that the domain has been added to the website configuration and that SSL provisioning has completed. A free wildcard SSL certificate can cover subdomains in many setups, but it still needs the correct domain configuration and DNS resolution before it can be issued.
Escalate with the details that matter
If the checks above do not resolve the problem, support can investigate far faster when you provide the domain name, affected service, error message, recent changes and the DNS records you expect to see. Include whether the issue affects every network or only your own connection.
At Blended Hosts, 24/7 technical support can help confirm whether a domain is pointing to the correct service and whether the hosting account is responding as expected. The aim is not simply to change a record, but to make sure website, email and security settings continue working together.
DNS problems are rarely mysterious once you separate the domain, the active nameservers, the public record and the destination server. Change only what you can verify, allow caches time to expire, and your next DNS fix should be measured in minutes rather than days.
