DNS Record Checker Explained: A, AAAA, CNAME, MX, TXT, and NS Records

Overview

DNS turns a human-readable domain name into the records that browsers, mail servers, and other services actually use. When people talk about a “DNS lookup” or a “dns record checker,” they usually mean a tool that queries public DNS and shows the current records for a domain or subdomain.

For day-to-day web work, the records you will check most often are:

• A record: points a hostname to an IPv4 address.
• AAAA record: points a hostname to an IPv6 address.
• CNAME record: points one hostname to another hostname.
• MX record: tells mail systems where to deliver email for a domain.
• TXT record: stores text-based verification or policy data, often for email and third-party services.
• NS record: identifies the authoritative nameservers for a zone.

A good DNS lookup guide starts with one simple rule: always check the exact hostname you care about. example.com, www.example.com, api.example.com, and mail.example.com can all have different records. Many DNS problems come from checking the root domain when the broken service actually uses a subdomain, or the reverse.

Another helpful rule is to separate three questions:

1. Is the record present?
2. Is the value correct?
3. Is DNS actually authoritative for this value yet?

The first question catches missing records. The second catches configuration errors. The third catches nameserver mismatches and propagation confusion. If you are changing a domain during a migration, all three matter.

DNS checkers are especially useful in combination with a propagation tool and a text comparison workflow. If you are tracking old and new zone values side by side, a diff workflow can make changes much easier to review. For related troubleshooting, it also helps to understand how DNS changes spread over time; see Domain Propagation Checker Guide: What DNS Changes Really Take So Long.

Checklist by scenario

Use this section as a reusable pre-flight list. Start with the scenario that matches what you are doing, then check the relevant record types.

1. Launching or fixing a website

If a site is not loading, loading the wrong site, or working only on one version of the hostname, start here.

• Check the A record for the root domain, such as example.com.
• Check the AAAA record too, if your host supports IPv6. A stale AAAA record can break connectivity even when the A record is correct.
• Check whether www uses a CNAME to the expected hostname, or its own A/AAAA records.
• Confirm there is not a conflicting setup where a hostname has both a CNAME and other record types that should not coexist.
• Verify you are editing the DNS zone on the actual authoritative provider, not on a previous host or parked registrar DNS panel.
• After DNS resolves correctly, verify redirects at the HTTP level. DNS can be right while redirect rules are still wrong. For that step, see How to Check Redirect Chains and Fix Common 301 and 302 Problems.

What success looks like: the intended hostname resolves to the intended infrastructure, and both root and www versions behave as planned.

2. Connecting a subdomain to an app or service

This is common for docs, help centers, landing pages, CDNs, managed app platforms, and SaaS integrations.

• Check the exact subdomain, such as app.example.com or docs.example.com.
• Confirm whether the service expects a CNAME or an A record.
• If it expects a CNAME, make sure the target is a hostname, not a raw IP address.
• Make sure the subdomain is not already using another record that conflicts with the intended setup.
• Check for trailing-dot or hostname-entry differences in your DNS interface if the panel handles them oddly.
• Confirm the service itself has accepted or verified the custom domain if verification is required.

What success looks like: the subdomain resolves exactly as the vendor documentation expects, and there are no leftovers from a previous provider.

3. Setting up or troubleshooting email

Email DNS issues are often subtle because the website can work perfectly while mail delivery fails.

• Check MX records for the root domain used for email.
• Confirm the priority values are set as intended and point to valid mail hostnames.
• Check the related TXT records for SPF, domain verification, or other required mail settings.
• If your provider uses DKIM or other selector-based records, check the exact hostnames they provide.
• Remove obsolete MX records from a previous mail provider if they are no longer part of the design.
• Confirm you did not accidentally change website records while editing email records in the same zone.

What success looks like: incoming mail routes to the correct provider, and verification or policy TXT records are visible publicly.

4. Migrating DNS or switching nameservers

Nameserver changes are where DNS record checker tools become essential. A zone can look correct in one panel while public DNS still uses another set of authoritative servers.

• Check the NS records at the parent level to confirm which nameservers are currently authoritative.
• Compare the old and new zones record by record before switching.
• Verify that critical A, AAAA, CNAME, MX, and TXT records exist in the destination zone before updating nameservers.
• After the change, use a DNS checker to confirm public answers now come from the new authority.
• Keep a plain text backup of the previous zone so you can compare values if something drifts.
• For careful validation, a comparison workflow helps; see Text Diff Checker Guide for Comparing Code, Configs, and Content Changes.

What success looks like: the parent domain delegates to the intended nameservers, and the new zone contains every needed production record.

5. Verifying domain ownership for third-party tools

Many services ask you to add a TXT record or CNAME to prove control of a domain.

• Check the exact hostname the service requires. Some verifications go on the root; others use a prefixed label.
• Verify the full TXT value matches exactly, including punctuation and separators.
• If multiple TXT records exist on the same host, confirm your DNS panel stores them cleanly and does not merge values incorrectly.
• Use a public checker after saving to confirm the record is actually visible, not just present in your dashboard.

What success looks like: the verification record is publicly resolvable and the third-party service accepts it.

6. Reviewing technical SEO-related DNS basics

DNS does not replace crawl, redirect, or sitemap checks, but it affects whether search engines and users reach the right version of the site.

• Make sure the preferred hostname resolves correctly.
• Check that non-preferred hostnames are intentionally redirected rather than left split across different targets.
• If you changed infrastructure, verify the site still serves the same robots and sitemap locations afterward.
• Follow up with Robots.txt Tester Guide: Common Rules, Mistakes, and SEO Checks and XML Sitemap Validator Checklist for Developers and Site Owners.

What success looks like: DNS supports a single consistent site entry path, with no accidental hostname split or environment leak.

What to double-check

Before you save a DNS change—or before you trust a result from a checker—run through these points.

Hostname scope

Be precise about whether you mean the apex domain or a subdomain. A record checker only tells you about the name you queried. If www is broken, checking only example.com may tell you nothing useful.

Record type expectations

Check the record type against the service instructions. If a platform says to create a CNAME and you create an A record instead, the lookup may still return something, but it will not be the configuration the service expects.

Conflicting records

One of the most common issues is a hostname carrying old records from a prior setup. Watch especially for combinations that should not exist together, such as a CNAME on a host that also has other active records where your provider does not support that pattern.

IPv6 leftovers

AAAA records are easy to forget. During migrations, teams often update the A record and overlook an old AAAA record that still points to the previous server. Some clients prefer IPv6, so the result can be inconsistent failures that are hard to reproduce.

Authoritative nameservers

If your DNS panel says one thing and a public checker says another, verify the NS delegation first. You may be editing the wrong DNS provider. This is especially common after moving from registrar DNS to a hosting provider, CDN, or managed DNS service.

TTL awareness

Time to live values affect how long previous answers may stay cached. A DNS record checker can show the new answer publicly while some users still hit the old one from cache. That is not always a sign the new record is wrong; it may simply mean old answers have not expired everywhere yet.

Exact TXT formatting

TXT records often fail because of small formatting differences. Double-check quotes, spaces, host labels, and whether the value belongs at the root or a prefixed name. For verification records, exact matching matters more than interpretation.

Mail-specific dependencies

MX records rarely stand alone. If you are checking mail delivery, review the related TXT records and any provider-specific selectors as part of the same pass. Looking only at MX records can miss the actual cause of setup failure.

Common mistakes

These are the errors that show up repeatedly during launches, migrations, and routine maintenance.

• Editing records in the wrong dashboard. The interface where you bought the domain is not always where DNS is authoritative.
• Checking only one hostname. Root and www often differ, and subdomains are independent.
• Forgetting AAAA records. An old IPv6 entry can keep part of your traffic on the wrong server.
• Leaving stale MX or TXT records in place. Old email settings can cause mixed delivery behavior or failed verification.
• Using the wrong record type. A and CNAME are not interchangeable just because they both seem to “point” somewhere.
• Misreading propagation as misconfiguration. A change can be correct and still appear inconsistent for a period of time.
• Copying values without checking the host label. Many setup guides include a host like @, a blank root, or a prefixed selector; mixing these up is easy.
• Testing DNS but not application behavior. A hostname may resolve correctly while SSL, redirects, app routing, or server config still fail.

When a DNS issue feels ambiguous, reduce it to a checklist: which hostname, which record type, which expected value, which authoritative nameserver, and which public result. That sequence usually narrows the problem quickly.

When to revisit

DNS is not a one-time setup. Revisit your records whenever the underlying infrastructure, services, or domain strategy changes. In practice, that usually means checking DNS before any meaningful launch window rather than after something breaks.

Good times to run this checklist again include:

• Before moving to a new host, CDN, or deployment platform.
• Before changing nameservers or consolidating DNS providers.
• Before adding a new email provider or changing mail routing.
• Before seasonal campaigns or product launches that depend on landing pages or subdomains.
• After removing old vendors, staging environments, or temporary verification records.
• When workflows or tools change and a different team starts managing the zone.

A practical maintenance habit is to keep a small DNS inventory for your important domains: root website records, www behavior, critical subdomains, MX records, key TXT records, and current nameservers. Then, before you act, compare the intended state to the public state with a DNS record checker.

If you want a simple action plan, use this five-step routine:

1. List the exact hostnames affected by the change.
2. Write down the target record type and value for each hostname.
3. Confirm which nameservers are authoritative before editing anything.
4. Check the public DNS result after saving, not just the provider dashboard.
5. Validate the live service afterward: site response, redirects, email flow, or vendor verification.

That process is straightforward, but it prevents a large share of DNS-related mistakes. Keep this guide bookmarked as a reference whenever you need to check DNS records, compare A record, CNAME, MX, and TXT setups, or work through a migration with less guesswork.