DNS changes connect your domain to a website, email service, or security certificate, but one incorrect record can make a site unreachable or stop messages from arriving. This DNS troubleshooting guide gives you a reusable, symptom-based checklist for identifying record errors, checking propagation, choosing whether to wait or roll back, and restoring service safely.
Overview
The Domain Name System (DNS) translates a human-readable domain such as example.com into the destinations used by browsers, mail servers, and certificate authorities. DNS is distributed, so a change made at your domain provider may not appear everywhere at the same time. Local device caches, recursive DNS resolvers, browser behavior, and the record's time to live (TTL) can all affect what different people see.
Start troubleshooting by separating the affected service. Is the website unavailable, is email failing, or is SSL verification stuck? Avoid changing several records at once. Record the current configuration, make one controlled change, and test from more than one network or DNS-checking service.
Before editing anything, collect these details:
- The domain and affected subdomain, such as
example.comorwww.example.com. - The exact error message, time of failure, and whether the issue affects everyone or only one device.
- The DNS provider, web host, email provider, and certificate provider involved.
- A copy or screenshot of the current DNS zone, including record type, name, value, priority, and TTL.
- The intended destination supplied by the hosting, email, or SSL provider.
If you are launching a new site, the domain, DNS, SSL, and business email setup checklist can help you verify the full sequence before publishing changes.
Checklist by scenario
| Symptom | Records to check | What to verify |
|---|---|---|
| Website does not load | A, AAAA, CNAME | Confirm the record points to the current host, the hostname is correct, and an old IPv6 destination is not overriding a working IPv4 setup. |
Only www or the root domain works | A, AAAA, CNAME | Check both names separately. The root domain and www often use different records or forwarding rules. |
| Business email cannot send or receive | MX, A, CNAME, TXT | Confirm MX hostnames and priorities, then verify the referenced mail host resolves. Review provider-required SPF, DKIM, and related TXT records. |
| Email goes to spam or authentication fails | TXT, CNAME | Check the provider's SPF and DKIM instructions and ensure there is not an accidental duplicate or conflicting SPF policy. |
| SSL certificate cannot be issued or renewed | CAA, TXT, CNAME | Confirm the certificate challenge record is at the exact requested name and value. If using CAA, verify it permits the certificate authority you selected. |
| Changes appear intermittent | All relevant records | Compare answers from authoritative DNS servers and different recursive resolvers. Look for duplicate records, stale destinations, or split DNS configurations. |
Website DNS errors
An A record maps a hostname to an IPv4 address. An AAAA record maps it to an IPv6 address. A CNAME points one hostname to another hostname, which is common for hosted platforms and some website builders. Check the exact hostname first: a record for www does not automatically configure the root domain, and a root-domain CNAME may be restricted by some DNS providers.
If a browser reports that the domain cannot be found, confirm that the domain uses the intended nameservers and that the record exists in the active DNS zone. If the domain resolves but shows the wrong site, the record may still point to an old host, or the hosting account may not be configured to accept that domain.
Email DNS records
MX records tell other mail systems where to deliver messages. Check the complete hostname and priority values supplied by your email provider. Do not replace working MX records merely because a website was moved; web hosting and email hosting may be separate services.
TXT records commonly support sender authentication and service verification. SPF is published as TXT, while DKIM may use a TXT or CNAME record depending on the provider. Follow the current setup instructions from the service responsible for email, and avoid guessing values from an unrelated provider. If you change email services, keep the old configuration documented until the new service is confirmed.
SSL DNS verification
Some certificate workflows ask you to publish a unique TXT or CNAME record. Copy the record name and value exactly, including any required underscores. DNS dashboards may automatically append your domain to a record name, so entering the full domain when the interface expects only a host label can create an incorrect, duplicated name. Check the provider's verification page again after the record is visible.
What to double-check
Propagation, caching, and TTL
DNS propagation is not a single global event. Resolvers may continue returning a previous answer until its cached TTL expires, while other resolvers may already show the new value. Use a DNS lookup tool to compare the record from multiple locations, but treat those results as observations rather than a guarantee that every network has updated.
Before a planned migration, lower the relevant TTL in advance if your provider and workflow support it. Lowering TTL after a mistake does not immediately remove answers already cached under the old TTL. After the change is stable, restore a sensible TTL based on how frequently you expect to edit the record. Avoid repeatedly changing values while waiting; that makes the situation harder to diagnose.
Authoritative DNS versus hosting settings
Find the authoritative nameservers first. The DNS records you edit at a registrar, hosting dashboard, or third-party DNS service only matter if that service is authoritative for the domain. A common cause of apparent DNS failure is editing one dashboard while the domain points to nameservers somewhere else.
Also verify the destination inside the hosting account. Correct DNS can still lead to an error if the domain is not added to the site, the server is not listening for that hostname, or the application redirects to an outdated domain.
Rollback workflow
- Stop making additional changes and capture the current zone.
- Identify the last known working record and compare it with the intended new value.
- Restore only the affected record, not the entire zone, unless you have a verified complete backup.
- Check the authoritative answer and test the service from a separate connection.
- Document the cause and the final configuration before attempting the change again.
A DNS rollback does not instantly clear cached answers. If the problem is urgent, communicate the expected behavior to affected users while resolvers update. For related operational planning, see this website migration to cloud hosting guide.
Common mistakes
- Editing the wrong DNS zone: Confirm the active nameservers before changing records.
- Leaving an old AAAA record: Some visitors may use IPv6 and reach an outdated or unavailable server.
- Creating duplicate or conflicting records: Multiple A, CNAME, MX, or SPF entries may produce unexpected results. Multiple records can be valid in some designs, so follow the service's instructions rather than deleting blindly.
- Using an IP address where a hostname is required: CNAME and MX targets generally expect hostnames, not arbitrary IP values.
- Confusing a DNS record with a URL redirect: DNS directs traffic but does not provide ordinary page-level redirects.
- Assuming browser cache proves DNS failure: Test with another browser, device, network, or command-line lookup.
- Changing email records during a website migration: Keep mail records unchanged unless the email provider is also moving.
- Copying verification values inaccurately: Preserve punctuation, underscores, capitalization where relevant, and the complete value supplied by the provider.
For a wider maintenance routine, combine DNS checks with the website maintenance schedule and verify that backups can restore the site before a major hosting or domain change.
When to revisit
Return to this checklist before moving hosting, changing email providers, renewing or replacing SSL certificates, adding a subdomain, switching nameservers, or launching a new website. It is also useful after a domain transfer, an unexpected outage, a failed email delivery test, or a security change involving SPF, DKIM, DMARC, or CAA.
Review the provider instructions whenever a service changes its verification method or publishes new record requirements. The names and values required by hosting, email, and certificate services are provider-specific and can change over time, so use this article for the troubleshooting process rather than as a substitute for the current values supplied by those services.
For a practical final pass, save a dated copy of your DNS zone, confirm the authoritative nameservers, test the root domain and key subdomains, send and receive a test email, verify SSL in a browser, and record the expected TTL. These small steps create a reliable reference for the next launch, migration, or DNS troubleshooting session.
