DNS problems often look mysterious, but most can be narrowed down with a repeatable process. This guide explains how to troubleshoot A, CNAME, MX, and TXT records, verify the authoritative nameservers, separate configuration errors from propagation delays, and know what to check before changing anything.
Overview
DNS, or the Domain Name System, connects human-readable names such as example.com to services such as a website, mail server, or verification system. When DNS is not working, begin by identifying which service is affected. A website problem, a missing email message, and a failed domain verification may all involve DNS, but they usually require different records.
Four record types account for many everyday troubleshooting cases:
- A record: Points a hostname to an IPv4 address. A typical website record might connect
example.comto an address such as203.0.113.10. - CNAME record: Points one hostname to another hostname, such as
www.example.comtoexample.comor to a hosting provider’s target. - MX record: Tells sending mail servers where to deliver email for a domain. MX records include a destination and a priority value.
- TXT record: Stores text used for tasks such as domain verification, sender authentication, and other service instructions.
The first question is not “Which record should I change?” It is “Which nameservers are authoritative for this domain?” The registrar, DNS provider, hosting company, and website builder may all be different businesses. A record edited in the wrong control panel will not affect the live DNS zone.
For background on the larger setup process, see the domain and hosting setup checklist and guide to connecting a domain to web hosting.
Checklist by scenario
When the website does not load
- Confirm the exact hostname with the problem: the root domain,
www, or another subdomain. - Check the domain’s authoritative nameservers at the registrar. They should match the DNS provider where you are making changes.
- Look up the A record for the root domain. Compare the returned address with the address supplied by your host.
- Look up the CNAME or A record for
www. Do not assume that the root domain andwwwuse the same configuration. - Check for conflicting records. Multiple A records can be intentional, but an old address mixed with a new address can send visitors to different destinations.
- Confirm that the hosting account accepts the domain and that the site is configured for the requested hostname. Correct DNS alone does not create a website at the server.
If a hosting provider gives you a hostname rather than an IP address, it may expect a CNAME. If it gives you an IP address, it may expect an A record. Follow the provider’s stated format rather than converting one record type into another.
When www works but the root domain does not
- Check the root domain’s A, AAAA, or provider-specific alias configuration.
- Check the
wwwrecord separately. A working CNAME forwwwdoes not automatically configure the root domain. - Review the website platform’s domain instructions. Support for CNAME-like records at the root varies by DNS provider.
- Make sure both hostnames are added to the hosting or website-builder account and covered by its SSL configuration.
When email is not arriving
- List the domain’s MX records and compare them with the records required by the email provider.
- Check the priority values. Lower numbers generally indicate higher delivery preference, so do not change priorities without knowing the provider’s intended design.
- Remove obsolete MX records only after confirming that they are no longer needed. An old record can cause some messages to go to the wrong system.
- Confirm that the mailbox exists with the receiving provider and that the domain has been verified there.
- Review TXT records required for email authentication, such as the provider’s sender-policy or signing instructions. These records help with sending, but they do not replace MX records for receiving.
For a custom-domain email setup, test both sending and receiving. A domain can have correct MX records while outgoing mail still needs a separate TXT-based configuration.
When a service says the domain cannot be verified
- Copy the required TXT or CNAME record exactly, including the host or name field.
- Check whether your DNS panel automatically appends the domain. Entering a full name in a panel that appends the domain can create a duplicated hostname.
- Preserve punctuation and spacing in TXT values. Some panels display long values across multiple lines; that does not necessarily mean they should be entered as separate records.
- Check for an existing record with the same name. Multiple TXT records can be valid, but replacing an existing verification or email record may break another service.
- Use a DNS lookup tool to confirm that the public answer matches the requested value before retrying verification.
What to double-check
Use at least two views of the DNS data when troubleshooting: the control panel where you edit records and an independent public lookup. A DNS propagation checker or command-line lookup can reveal whether the change is visible outside your account.
- Authoritative source: Verify the nameservers first. This is the DNS equivalent of checking that you are editing the correct server.
- Hostname formatting: A panel may display the root as
@, a blank field, or the full domain. Follow that panel’s convention. Avoid adding the domain twice. - Record conflicts: A hostname generally should not have a CNAME alongside other record types. Review duplicates and stale records before adding new ones.
- IPv4 versus IPv6: An A record controls IPv4, while an AAAA record controls IPv6. A correct A record may not fix a client that receives an incorrect AAAA answer.
- TTL and cached answers: DNS resolvers may retain an earlier answer until its time to live expires. A lookup from one network can differ temporarily from a lookup elsewhere.
- HTTPS configuration: DNS points a hostname to a service; it does not by itself install an SSL certificate or configure redirects. Check the hosting platform separately.
When testing, record the hostname, record type, returned value, resolver or lookup location, and time of the test. This simple log prevents repeated changes based on incomplete observations.
Common mistakes
| Symptom | Likely cause | Practical next step |
|---|---|---|
| Changes appear to do nothing | Records were edited at a non-authoritative provider | Compare the domain’s registered nameservers with the DNS panel in use. |
| Some visitors see the old site | Cached DNS answers or inconsistent records | Check authoritative data and several public resolvers before changing the record again. |
| Mail goes to the old provider | An obsolete MX record remains | Review every MX record and compare it with the current email provider’s instructions. |
| Verification fails despite a TXT record | Wrong hostname, extra domain suffix, or altered value | Compare the public TXT answer character by character with the requested value. |
| A subdomain resolves unexpectedly | A stale CNAME, wildcard, or inherited platform setting | Inspect the exact subdomain and any wildcard record affecting it. |
Avoid making several unrelated changes at once. Change one record, note the original value, and test the intended hostname. Before deleting a record, save a copy of the existing zone or export it if your provider supports that option.
When to revisit
Return to this checklist whenever you move a website, change hosting providers, switch email platforms, add a subdomain, enable a CDN, or move DNS management to a service such as Cloudflare. Recheck records before a planned launch or seasonal campaign rather than waiting for a visible outage.
After a migration, verify the root domain, www, important subdomains, MX records, key TXT records, and both HTTP and HTTPS behavior. Keep a dated inventory of the intended records, their purpose, and the system responsible for each one. Review that inventory whenever a team member, registrar, hosting account, or security service changes.
If the public DNS answer is correct but the website or email service still fails, stop changing DNS and investigate the destination service: hosting configuration, application settings, mailbox status, firewall rules, SSL setup, or provider-side verification. That boundary keeps DNS troubleshooting focused and reduces accidental outages.
For related launch checks, use the domain and hosting launch checklist. If you are changing DNS architecture, the Cloudflare setup guide explains the separate considerations for nameservers, DNS, SSL, and caching.
