How to Troubleshoot DNS Issues: A Step-by-Step Guide for Website and Email Problems

Overview

Here is the core idea: DNS troubleshooting is easier when you separate where the problem appears from where the problem actually lives. A website may fail to load in the browser, but the root cause might be the wrong nameservers at the registrar, an incorrect A record in DNS management, a stale CDN setting, or an SSL certificate mismatch after a host change. Email may bounce, but the issue could be a missing MX record, a malformed SPF value, or mail still pointing to the previous provider.

A reliable DNS troubleshooting guide starts with five questions:

1. What exactly is failing? Website, email, one subdomain, one region, one device, or all users?
2. What changed recently? Domain registration transfer, nameserver update, web hosting migration, DNS edits, SSL certificates setup, or email provider switch?
3. Who hosts the DNS zone? Your registrar, web hosting company, CDN, DNS provider, or cloud hosting platform?
4. What should the correct answer be? The intended IP, canonical hostname, mail server, or TXT record value.
5. Are you seeing authoritative data or cached data? Local resolver cache, browser cache, ISP cache, or propagation delay can make good records look broken.

If you answer those five questions before editing anything, you avoid the most common trap in website DNS problems: fixing the wrong layer.

Use this short baseline checklist before every investigation:

• Confirm the domain and hostname involved: example.com, www.example.com, mail.example.com, or a subdomain.
• Note the symptom exactly: NXDOMAIN, timeout, wrong IP, SSL warning, mail bounce, or intermittent failure.
• Check whether the issue affects everyone or only specific networks and devices.
• Write down any recent changes within the last 48 hours.
• Identify the current nameservers from the parent zone.
• Query the authoritative nameservers directly if possible.
• Compare expected records against live records.
• Only change one thing at a time, then re-test.

If you need a deeper explanation of caching windows after DNS changes, see DNS Propagation Explained: How Long Changes Take and How to Check Them.

Checklist by scenario

This section gives you step-by-step DNS lookup steps by symptom so you can diagnose faster without overcorrecting.

1. Website does not load at all

When a site is fully unreachable, narrow the issue quickly.

1. Check the exact browser error. “Server not found” often points to DNS. “Connection refused” or “timeout” may point to hosting, firewall, or origin problems rather than DNS management.
2. Look up nameservers for the domain. Confirm they match the provider that should be hosting the DNS zone.
3. Query the A or AAAA record for the root domain and the CNAME or A record for www. Verify that the returned value matches the intended web hosting or cloud hosting destination.
4. Check whether the hostname exists. An NXDOMAIN response usually means the name is missing entirely, often because the zone was not recreated after a transfer or migration.
5. Test authoritative vs recursive answers. If the authoritative answer is correct but your local answer is not, you may be dealing with caching rather than a broken record.
6. Confirm whether a CDN or proxy is in front. In some setups, DNS points to the CDN, not the origin server. Make sure you are checking the correct target. This is a common confusion when people compare CDN vs web hosting roles. For background, see CDN vs Web Hosting: What Each One Does and When You Need Both.
7. Check the web server separately. If DNS resolves correctly but the site still fails, the problem may be at the host, not in DNS.

2. Website loads the wrong site or old server

This usually happens during website hosting migrations, platform changes, or after switching between shared hosting, VPS hosting, or WordPress hosting.

1. Verify the current A, AAAA, or CNAME record values.
2. Compare them with the old hosting environment and the new one.
3. Check for duplicate records. Mixed A and AAAA values can send different users to different destinations.
4. Inspect www separately from the apex domain. One may be updated while the other still points to the old host.
5. Review TTL values and recent edit times if your DNS provider shows them.
6. Clear local DNS cache or test from another network to avoid mistaking cache for misconfiguration.
7. If a load balancer, reverse proxy, or CDN is involved, confirm the origin setting also points to the intended server.

During migrations, DNS is only one part of the chain. The site can resolve correctly while content, SSL certificates, or origin configuration still lag behind.

3. Email is not being delivered

Email DNS issues usually come from MX, SPF, DKIM, or DMARC records, but start with MX first.

1. Check MX records for the domain. Confirm they point to the intended email provider and that hostnames are spelled exactly.
2. Verify that MX targets themselves resolve. An MX record pointing to a hostname that does not resolve will still fail.
3. Check whether the domain still has old mail provider records. During provider switches, stale MX entries can split delivery.
4. Inspect SPF TXT records. Make sure there is not more than one SPF policy record for the same name, which can invalidate evaluation.
5. Check DKIM selector records. A missing or malformed selector can affect authentication even if mail flows.
6. Review DMARC syntax. Even a small formatting mistake can change the policy outcome.
7. Read the bounce message carefully. It often reveals whether the issue is DNS resolution, authentication, policy, or remote server rejection.

When troubleshooting email DNS issues, separate delivery from authentication. Mail can arrive but fail SPF or DKIM. Or delivery can fail before authentication is even evaluated.

4. Only one subdomain is broken

A healthy main site with a broken subdomain usually means the zone is mostly correct and the fault is isolated.

1. Query the exact subdomain, not just the parent domain.
2. Check whether it uses an A, AAAA, or CNAME record.
3. Look for typos in long hostnames, especially third-party verification targets.
4. Check whether the subdomain has delegated nameservers of its own.
5. Confirm there is no wildcard record producing an unexpected answer.
6. If the subdomain supports an app, API, or staging environment, verify the expected destination with the application team or hosting control panel.

5. SSL certificates fail after a DNS change

DNS and SSL certificates are tightly connected during provisioning and renewals.

1. Confirm the hostname resolves to the intended server or validation endpoint.
2. Check whether www and the apex domain both resolve correctly.
3. Verify that there is no stale AAAA record sending some traffic to a server without the right certificate.
4. If using DNS-based validation, confirm the required TXT record exists exactly as requested.
5. Make sure a proxy or CDN is not intercepting validation in a way the certificate workflow does not expect.

If the DNS is right but the certificate still fails, the problem may have moved from DNS management into the web hosting or certificate layer.

6. DNS works for some users but not others

Inconsistent behavior usually points to caching, resolver differences, split-horizon DNS, or IPv6 mismatch.

1. Compare answers from multiple recursive resolvers.
2. Test directly against authoritative nameservers.
3. Check whether local devices, VPN software, or enterprise firewalls use a custom resolver.
4. Look for differing A and AAAA behavior.
5. Confirm that recent changes had enough time to expire from old caches.
6. If this is an internal service, verify whether split-horizon DNS is intentional.

What to double-check

These are the small details that cause an outsized share of website DNS problems and email DNS issues. If your first pass does not reveal the answer, come back to this list before making bigger changes.

• Nameserver authority: The zone you edited may not be the live zone. This happens often after domain registration transfers or when a registrar keeps old nameservers active.
• Record type: A hostname meant to be a CNAME may have been created as an A record, or vice versa.
• Apex restrictions: Some DNS providers handle root-domain aliases differently. The target may need a provider-specific alias feature rather than a plain CNAME.
• Trailing dots and formatting: Some interfaces add or omit trailing dots automatically. Wrong assumptions can produce doubled hostnames.
• Multiple TXT records: This is especially important for SPF. More than one SPF policy record can break evaluation.
• Priority on MX records: Syntax may be valid, but priorities can still be wrong or incomplete.
• IPv6: An old AAAA record can quietly break traffic for users on IPv6-capable networks even when IPv4 looks correct.
• Wildcard records: Wildcards can mask missing records and create confusing responses during troubleshooting.
• Delegation: A subdomain may be delegated to another DNS zone entirely.
• Local overrides: Hosts files, browser DNS settings, VPNs, and security products can make live DNS look inconsistent.

For operational teams, it helps to maintain a small DNS inventory document with the expected values for web hosting, cloud storage endpoints, mail routing, verification records, and SSL certificates validation records. That inventory reduces guesswork during emergencies and migrations.

If your troubleshooting intersects with backup or migration planning, build DNS validation into the checklist. Before switching traffic, verify that site backups and offsite copies are current. Related reading: Best Backup Storage for WordPress Sites: Plugins, Remote Destinations, and Restore Workflows, How Often Should You Back Up a Website? RPO and RTO Guidelines by Site Type, and Website Backup Strategy Guide: Full, Incremental, Differential, and Snapshot Backups Compared.

Common mistakes

Most DNS incidents are not caused by obscure protocol behavior. They come from ordinary process mistakes made under time pressure.

• Editing records before confirming the authoritative zone. This is the fastest way to lose time.
• Changing several records at once. When everything changes together, you cannot tell which edit helped or hurt.
• Ignoring www while fixing the apex domain. These are often separate records.
• Assuming propagation is the only issue. Propagation does matter, but it is often used as a placeholder explanation for a record that is simply wrong.
• Forgetting mail records during a website migration. Moving website hosting does not always mean email should move too.
• Leaving old provider records in place. Partial cleanup can create split behavior.
• Not checking AAAA records. An outdated IPv6 record can create intermittent failures that are hard to reproduce.
• Using browser results as the only test. Browsers add their own caching and HTTPS behaviors on top of DNS.
• Skipping documentation. If you do not record what changed, the next outage starts from zero again.

Another common mistake is blaming DNS when the issue belongs to uptime or application health. If your records resolve correctly and the origin is still down, review the hosting side. This is especially relevant for teams evaluating web hosting reliability, cloud hosting operations, or provider support. For a useful companion read, see How to Read a Hosting SLA: Uptime Guarantees, Credits, Exclusions, and Red Flags.

When to revisit

The best DNS troubleshooting guide is one you return to before change windows, not just during incidents. Revisit this checklist whenever the underlying inputs change:

• Before moving a site to new website hosting, VPS hosting, or cloud hosting
• Before changing nameservers or transferring domain registration
• Before switching email providers or adding new sending services
• Before enabling a CDN, reverse proxy, or new SSL certificates workflow
• Before seasonal planning cycles or major traffic events
• When workflows, hosting control panel tools, or DNS providers change
• After staff handoffs, vendor changes, or infrastructure consolidation

Make the next troubleshooting session easier with this action-oriented maintenance routine:

1. Create a current DNS record inventory for every production domain and critical subdomain.
2. Document which provider is authoritative for each zone.
3. Store intended targets for website hosting, mail routing, and certificate validation in one place.
4. Reduce unnecessary legacy records after migrations are complete.
5. Test from authoritative and recursive resolvers during every planned DNS change.
6. Include DNS checks in your website backup and rollback process.
7. Review internal runbooks quarterly or whenever tools change.

DNS is one of those layers that seems invisible until it fails. A calm checklist prevents rushed edits, shortens outages, and makes migrations safer. If you manage websites on modern cloud infrastructure, that discipline matters as much as choosing fast web hosting, secure domain registration, or reliable cloud storage. Keep this runbook handy, and use it before every major change—not only after something breaks.