DNS Troubleshooting Checklist: Why Your Site, Email, or SSL Is Not Working

Overview

Here is the practical promise: if your site is down, email is failing, or SSL is not issuing after a DNS update, this checklist helps you isolate the cause without skipping the basics. It is especially useful for developers, IT admins, and small teams that manage domain registration, DNS management, and cloud web hosting across multiple providers.

Most DNS incidents fall into one of a few patterns:

• The wrong nameservers are active.
• The correct zone exists, but the record values are wrong.
• The right records were added in the wrong DNS provider.
• TTL and propagation are being confused with a configuration error.
• Email authentication or mail routing records are incomplete.
• SSL validation is blocked by record conflicts, redirects, or proxy settings.

Before you troubleshoot by scenario, capture four facts first:

1. What changed? A record edit, nameserver update, domain transfer, hosting migration, CDN enablement, or email provider switch.
2. What is broken? The apex domain, a subdomain, outgoing mail, incoming mail, SSL issuance, or only one network location.
3. Where is DNS actually hosted? Your registrar, your cloud hosting provider, a CDN, or a separate managed DNS platform.
4. What should the working state be? The expected A, AAAA, CNAME, MX, TXT, or CAA records and the provider that should answer authoritatively.

If you are unsure whether you should change nameservers or individual records, review Nameservers vs DNS Records: What to Change and When. If the domain was recently pointed to a new service, How to Point a Domain to Your Website, Store, or App is a useful companion.

Checklist by scenario

Use the scenario that matches the symptom first. If the issue spans site, email, and SSL at the same time, start with nameservers and authoritative DNS.

1) The website is not resolving or loads the wrong server

1. Confirm the failing hostname. Test the root domain, www, and any affected subdomain separately. It is common for one host to work while another is misconfigured.
2. Check the active nameservers at the registry level. If they do not match your intended DNS provider, the rest of the zone file may be irrelevant.
3. Verify the authoritative zone. Look up the authoritative answer for the hostname, not just what your browser cached earlier.
4. Check record type and value. Make sure an A or AAAA record points to the correct IP, or a CNAME points to the exact target your host requires.
5. Check for conflicting records. A hostname generally should not have a CNAME mixed with other record types at the same label.
6. Check the hosting side. Confirm the domain or subdomain is attached inside your cloud web hosting or application platform. Correct DNS can still point to an unconfigured virtual host.
7. Review redirects and proxy layers. CDN, reverse proxy, and platform redirect rules can make a DNS problem look like an application problem, or the other way around.
8. Wait only after verification. If the authoritative answer is wrong, more time will not fix it. If the authoritative answer is correct but some resolvers still show the old value, then propagation is the likely explanation.

If you are in the middle of a launch, pair this with Website Launch Checklist for a New Domain. If timing is the concern, see How Long Does Domain Propagation Take? A Practical DNS Change Timeline.

2) Email is not being received or sent

1. Confirm whether the problem is inbound, outbound, or both. Inbound mail usually points to MX or mail host issues. Outbound delivery and spam placement often involve SPF, DKIM, and DMARC.
2. Check MX records first. Make sure they point to the correct provider hostnames and priorities. One typo can stop delivery entirely.
3. Verify the mail host records. If your MX points to a hostname that lacks a valid A or AAAA record, mail may fail even though the MX itself looks correct.
4. Review SPF. Confirm there is one valid SPF record for the domain and that it includes all approved sending services.
5. Review DKIM. Make sure the selector hostnames and TXT values were published exactly as provided by your email service.
6. Review DMARC. DMARC does not route mail, but an overly strict policy during setup can expose alignment problems fast.
7. Check provider activation steps. Some platforms require domain verification in their dashboard even after DNS records are added.
8. Test the exact sending domain. A root domain and a subdomain used for marketing or transactional mail may have different authentication records.

This is a common email DNS issue after migrations because teams update MX records but forget authentication TXT records or custom return-path settings.

3) SSL is not issuing, renewing, or matching the domain

1. Confirm the certificate scope. Is the problem on the apex domain, www, or a specific subdomain? Certificates do not automatically cover every hostname.
2. Check that the hostname resolves correctly first. An SSL DNS problem is often just a DNS resolution problem in disguise.
3. Review CAA records. If CAA is present, confirm it authorizes the certificate authority your platform uses.
4. Check DNS validation records. For DNS-based certificate issuance, the required TXT or CNAME validation record must be present exactly as instructed.
5. Look for proxy interference. Some proxy or CDN settings can complicate validation if the origin hostname or expected answer is masked.
6. Check redirects. Aggressive HTTP-to-HTTPS or domain canonicalization rules can interfere with some validation flows if the service expects plain HTTP access during issuance.
7. Confirm hosting attachment. Many SSL failures happen because the domain resolves to the platform, but the domain was never added inside the platform settings.

If the site is moving between providers, SSL should be checked only after DNS, domain attachment, and the intended canonical host are confirmed.

4) Everything broke after a nameserver change

1. Check whether the full zone was recreated. Changing nameservers does not move records automatically unless a provider explicitly handled that for you.
2. Compare old and new zones line by line. Website, email, verification TXT records, and subdomains are commonly missed.
3. Confirm glue or child nameserver details if relevant. This matters mostly in advanced setups, but broken custom nameserver configurations can cause broad resolution failure.
4. Check DNSSEC status. If DNSSEC was enabled with the old provider and not updated correctly, validation may fail even when records look right.
5. Verify propagation at the delegation layer. The registry must show the intended nameservers before your new zone can fully take effect.

This is especially common after domain transfer or registrar consolidation. If that is your situation, review Domain Transfer Checklist: What to Unlock, Back Up, and Verify Before Moving Registrars.

5) Only one region, office, or device shows the problem

1. Test from another network. Separate local caching from true DNS failure.
2. Flush local resolver and browser cache if appropriate. Do this only after checking authoritative DNS, so you do not mistake a local issue for a global one.
3. Check ISP or enterprise resolver behavior. Split-horizon DNS, internal overrides, or security filters can create location-specific results.
4. Review IPv6 separately. A broken AAAA record can affect some users while others continue over IPv4.

When someone reports that the site is not resolving DNS but only from one environment, treat caching and local resolver behavior as first-class suspects.

What to double-check

Once the immediate symptom is identified, these are the items worth reviewing every time. This is where many avoidable incidents live.

Authoritative vs cached answers

The most important distinction in DNS troubleshooting is whether the authoritative DNS answer is correct. If it is wrong, fix the zone. If it is correct and some users still see old results, you are likely in a propagation window. Do not repeatedly edit records trying to force the internet to refresh faster; that often extends the outage by changing the target again.

The right provider

A surprisingly common DNS misconfiguration happens when records are edited at the registrar while the domain actually uses third-party nameservers. The dashboard lets you save the record, but it has no effect because that zone is not authoritative. Always confirm where DNS is hosted before making changes. For registrar selection and operational controls, Best Domain Registrar Features Checklist for Developers and IT Teams provides a practical framework.

Apex vs subdomain

The root domain, www, and subdomains often need separate records and separate platform attachment. A working www does not prove the apex is correct. Likewise, a wildcard record does not guarantee that your app, SSL, or mail service is configured for the specific host being used.

Record syntax and formatting

TXT values, DKIM keys, validation tokens, and trailing dots can all matter depending on the provider interface. Copy the required value carefully and confirm whether the UI appends the zone automatically. Many failed verification steps are simple hostname formatting errors.

TTL expectations

TTL controls how long caches may hold a record, but it does not replace validation. Lower TTLs can help before planned migrations, yet they do not fix an incorrect record and do not guarantee immediate refresh everywhere. Treat TTL as one variable, not the whole explanation.

Domain status and registration health

If nothing makes sense, verify the domain itself is active and renewed, especially after billing changes or a transfer. DNS troubleshooting sometimes masks a domain registration issue. If you need a refresher on safe ownership practices, read How to Buy a Domain Name Safely and WHOIS Lookup Explained.

Common mistakes

The fastest way to shorten incident time is to stop repeating the same failure patterns. These are the most common ones to watch for.

• Changing records in the wrong zone. This is the classic failure after moving to managed DNS or a CDN.
• Updating nameservers without recreating the zone. Delegation changed, but the new provider has an incomplete set of records.
• Assuming propagation is the issue before checking authoritative DNS. Time does not fix a typo.
• Forgetting related records during migrations. MX gets updated, but SPF or DKIM is left behind. A record changes, but the SSL validation CNAME does not.
• Leaving old AAAA records in place. IPv6 can break access for part of your audience even when IPv4 works.
• Mixing apex and subdomain logic. Teams point www correctly and forget the naked domain redirect or hosting attachment.
• Overlooking CAA records. Certificate issuance fails even though the validation record is present.
• Making multiple changes at once. When nameservers, A records, proxies, and redirects all change together, root-cause analysis becomes much slower.
• Skipping documentation. Without a record of the intended state, every incident becomes detective work.

For related structural decisions, Subdomain vs Subdirectory for SEO, Hosting, and Team Ownership can help prevent architecture choices from turning into recurring DNS cleanup later.

When to revisit

This checklist is most useful before and after change windows, not only during outages. Revisit it whenever one of these events is coming up:

• You are moving to new cloud web hosting or changing origin IPs.
• You are switching email platforms or adding a transactional mail provider.
• You are changing nameservers, enabling managed DNS, or adding a CDN.
• You are issuing new SSL certificates, adding subdomains, or changing the canonical host.
• You are transferring the domain to a new registrar.
• You are preparing a product launch, seasonal traffic event, or maintenance window.
• Your team changed internal workflows, tooling, or approval paths for DNS edits.

A simple action plan makes this article reusable:

1. Before the change: export the current zone, lower TTLs where appropriate, document the target state, and define rollback values.
2. During the change: modify one layer at a time, confirm authoritative answers, and record exactly what changed.
3. After the change: test website resolution, email flow, SSL issuance, redirects, and key subdomains from multiple networks.
4. For ongoing operations: keep a domain inventory with registrar, nameservers, DNS host, renewal owner, and critical records.

If you manage multiple domains, create your own one-page version of this checklist with your preferred tools, standard hostnames, and escalation steps. That small bit of process turns DNS troubleshooting from a stressful outage ritual into a repeatable maintenance task.

And if the issue begins at the ownership layer rather than the zone itself, review WHOIS Privacy Protection and your registrar controls to make sure account access, notifications, and renewal responsibilities are clear. Reliable DNS starts with reliable domain operations.