DNS Records Explained: A Practical Troubleshooting Guide for A, CNAME, MX, TXT, and NS Records

Overview

DNS, or the Domain Name System, translates human-readable names such as example.com into information that networks can use. A DNS zone is the set of records managed for a domain. Depending on the provider, that zone may be hosted by your domain registrar, web host, dedicated DNS hosting provider, email platform, or another infrastructure service.

DNS records do not all perform the same job. An A record points a hostname to an IPv4 address. An AAAA record does the equivalent for an IPv6 address. A CNAME record points one hostname to another hostname. MX records identify the servers that receive email. TXT records hold text-based instructions or verification data. NS records identify the authoritative name servers responsible for a domain or delegated subdomain.

A common source of confusion is the difference between a registrar and DNS hosting. The registrar manages the domain registration, while DNS hosting manages the zone records. One company may provide both services, but they are separate functions. Before changing anything, confirm which name servers are authoritative. Editing records in a dashboard that is not authoritative will not change the public DNS answers.

DNS changes can also appear inconsistent for a while. Recursive DNS resolvers may retain earlier answers until the record's time to live, or TTL, expires. This is why a DNS propagation checker can show different results during a change. It is also why testing from only one device or network can produce a misleading conclusion.

Step-by-step workflow

1. Record the current configuration

Before editing a zone, export or copy the existing records. Include the record name, type, value, priority where applicable, and TTL. Pay particular attention to MX, TXT, and verification records. Deleting an unfamiliar TXT record or replacing an MX record can interrupt email or remove a service verification.

Also write down the intended result in plain language. For example: “The root domain should load the new hosting account, www should follow the same website, and email should remain with the existing mail provider.” This separates the goal from the provider's terminology.

2. Identify the authoritative name servers

Check the domain's NS delegation at the registrar or use a DNS lookup tool. The listed authoritative name servers determine where the zone is managed. If the registrar points to a hosting provider's name servers, changes made in the registrar's separate DNS editor may have no effect. If you recently transferred a domain, verify that the name server delegation did not change unexpectedly.

3. Map the required records

For a typical website, the root or apex name may use an A record supplied by the host. The www hostname may use a CNAME pointing to the host's assigned hostname. Not every DNS platform supports a CNAME at the apex, and some platforms use provider-specific features such as an alias or flattened record instead. Follow the hosting provider's documented target and record type rather than guessing.

For email, enter every MX record supplied by the mail provider and preserve the stated priority values. Lower numerical priority commonly indicates preference, but the provider's instructions should control. Do not point MX records at the website server simply because the website and email use the same domain.

For TXT records, add the exact value supplied by the relevant service. Common uses include domain ownership verification and email authentication policies such as SPF, DKIM, and DMARC. SPF is generally published as a TXT record, while DKIM often uses a provider-specified selector as part of the hostname. These records are sensitive to spelling, punctuation, quoting, and line wrapping.

4. Make one controlled change at a time

Use the DNS provider's normal editor and keep a change log. Avoid changing unrelated records during a website launch or domain transfer. If a provider asks you to replace an existing record, compare the old and new values first. Some services require several TXT values to coexist; replacing the entire TXT set without checking can break another integration.

When moving a website, configure the new hosting account before changing DNS whenever possible. Confirm that the site works through a temporary URL, hosts-file test, staging address, or provider preview method. Then update the relevant A, AAAA, or CNAME record. For a broader launch plan, use the website launch and hosting setup checklist.

5. Validate both authoritative and public answers

First query the authoritative name servers directly. This tells you whether the change was saved correctly in the zone. Then query one or more public recursive resolvers. If the authoritative answer is correct but a public resolver still returns the old value, caching is a likely explanation. If the authoritative answer is wrong, waiting will not fix the configuration.

Tools and handoffs

DNS work usually involves several systems, so define which system owns each handoff:

• Registrar: domain registration, renewal, locks, contact settings, and name server delegation.
• DNS host: the authoritative zone and its A, CNAME, MX, TXT, NS, and related records.
• Web host or CDN: the destination hostname, IP address, SSL setup, redirects, and origin configuration.
• Email provider: MX, SPF, DKIM, DMARC, mailbox, and delivery requirements.
• Verification service: a requested TXT or CNAME token and confirmation status.

Useful tools include command-line utilities such as dig and nslookup, provider dashboards, and browser-based DNS lookup services. A DNS propagation checker can compare answers from multiple locations, but treat it as a comparison aid rather than proof that every resolver has updated. For a website problem, also test the HTTPS certificate, redirects, origin server, and CDN configuration; correct DNS alone does not guarantee a working site.

If email is involved, use the mail provider's setup and diagnostic tools in addition to DNS lookups. For a full email workflow, see how to set up business email on your domain. During a migration, preserve the old mail service until the new MX records and mailboxes have been tested.

Quality checks

Use this checklist before declaring a DNS change complete:

• Confirm that you edited the authoritative DNS provider.
• Check the exact spelling of every hostname and target.
• Check whether the provider expects an apex name, an empty name field, or a fully qualified hostname.
• Make sure an intended CNAME is not conflicting with other records at the same name.
• Verify that A and AAAA records lead to the intended infrastructure.
• Confirm all required MX records and priorities are present.
• Check TXT values for missing characters, accidental spaces, and incorrect quotes.
• Test the root domain and important subdomains separately.
• Test website HTTPS, redirects, and both desktop and mobile access.
• Send and receive a test email if mail records changed.
• Keep a dated copy of the final zone or change log.

For a wrong-site error, start with A, AAAA, and CNAME answers, then check whether the web host recognizes the domain. For an email failure, start with MX and provider-required authentication records. For a verification failure, compare the requested token character by character and check that no conflicting record or proxy feature is altering the expected response.

When to revisit

Revisit your DNS documentation whenever you change registrars, DNS hosts, web hosts, CDNs, email providers, or security services. A domain transfer can preserve or replace name server settings depending on the process, so include DNS review in any domain transfer checklist. Website migrations should also include DNS, SSL, email, redirects, and backups rather than treating the A record as the entire move.

Review records after adding a subdomain, launching a third-party service, changing email platforms, or enabling a CDN. Remove obsolete verification tokens and old hosting records only after confirming that no active service depends on them. Keep the final record inventory with your infrastructure documentation so the next change starts from known information.

When a problem appears, follow the same order each time: identify the authoritative servers, inspect the authoritative answer, compare public resolver answers, verify the service configuration, and then allow for caching where appropriate. That disciplined sequence is safer than repeatedly changing records while waiting for an unexplained result.