How to Check DNS Records: A, AAAA, MX, NS and CNAME

A DNS checker is a convenient way to inspect the records a resolver can currently retrieve for a domain. People use one after changing a website host, configuring email, moving DNS providers, or investigating a name that fails to resolve. The result is a snapshot, not a guarantee that every recursive resolver has updated or that the underlying service is available. To make the check useful, choose the exact hostname, select the record type that matches the symptom, and interpret an empty answer differently from a DNS error. Those three steps prevent many false alarms and help you identify which configuration layer deserves attention.

Choose the record that answers your question

For a website's IPv4 address, inspect A; for IPv6, inspect AAAA. A subdomain may use a CNAME to point at a hosting provider's hostname rather than carrying an address directly. Email delivery depends first on MX records, while TXT records often publish SPF, DKIM, DMARC, and ownership-verification data. NS records show which nameservers are listed for a zone, and SOA gives administrative and timing fields associated with that zone. Checking only A records is therefore insufficient when the issue is mail delivery, a delegated subdomain, or a verification step. Start from the affected service and map that symptom to its record types.

Next, verify the queried name exactly. example.com, www.example.com, and api.example.com are separate DNS names and can return completely different answers. A trailing dot in fully qualified DNS notation represents the root and is usually optional in user interfaces. Do not paste an entire URL with a path and assume the checker will know which hostname matters; extract the hostname first. If you are validating a new record, compare the returned value character for character with the provider's instructions. TXT policies often contain punctuation, separators, or long strings where a seemingly minor typo can invalidate the record.

Understand where different answers come from

DNS is distributed and cached. An authoritative nameserver holds the zone's published data, while recursive resolvers answer users and may cache earlier responses until their TTL expires. Two checkers can therefore show different values temporarily if they query different resolvers, locations, or record versions. A checker that queries a collection of locations can help illustrate variation, but it does not prove that every network has converged. If a result disagrees with the intended configuration, identify which resolver answered and compare it with the authoritative nameservers. Then consider the TTL and when the previous value was cached before making another change.

• NOERROR with no requested record can mean the name exists but has no data of that type.
• NXDOMAIN means the queried name was reported as nonexistent.
• SERVFAIL signals that a resolver could not complete the query successfully.
• A timeout means no response arrived within the checker's wait period.
• Multiple A or AAAA answers can be intentional for redundancy or traffic distribution.

Turn a DNS check into a safe troubleshooting step

Keep a before-and-after record when changing DNS. Capture the name, type, value, TTL, resolver, and time, then repeat the same query after the update. If the authoritative server returns the new value but one recursive resolver returns the old value, waiting for caches to expire may be appropriate; changing the record repeatedly can make the situation harder to diagnose. If authoritative servers disagree, investigate zone replication or provider configuration. If all DNS answers look correct but a website still fails, move on to connectivity, TLS, routing, or application health instead of continuing to change DNS blindly.

Finally, treat the answer according to its scope. Public DNS checks are suitable for domains and records intended to be visible on the public internet; they are not a method for examining an organization's internal-only namespace. An IP returned by DNS may be a CDN edge, load balancer, or reverse proxy rather than the machine hosting the application. If you only need public address answers, the domain-to-IP lookup is a focused next step. For terminology and examples of A, AAAA, MX, TXT, and NS, see DNS record types explained.

Read a checker report with healthy skepticism

A DNS checker may present a green indicator when it receives any response, even if the returned value is not the value your service requires. Read the raw owner, type, and data instead of relying only on a summary badge. A response from one location is also a sample, not a guarantee of global agreement. If the tool lists many locations, remember that each location can represent a particular resolver and cache state rather than every user in that region. Use the report to select a next diagnostic step: compare to authority, inspect the TTL, or test the service. Avoid copying an IP into production configuration without confirming that it is the provider's supported endpoint. Good troubleshooting is based on an expected value and a reason for that expectation, not simply on whether a checker calls the result “valid.”