Every time you type a domain name into a browser, the Domain Name System translates that name into the addresses computers need. DNS records are the individual entries that make this work: A records point a domain to an IPv4 address, AAAA records do the same for IPv6, MX records tell mail servers where to deliver email, CNAME records create aliases from one name to another, and TXT records carry verification strings and email security policies.

Checking a domain's DNS records is a routine diagnostic skill. You do it when a site goes down after a hosting move, when email stops arriving, when a service asks you to verify domain ownership, or when you inherit a domain and want to see how it is configured before changing anything. The check itself takes less than a minute once you know the tools.

The easiest way to check DNS records is a free online lookup tool. Enter the domain name, choose the record type or select all records, and the tool queries the domain's authoritative name server and displays the results. This is the best option when you are on a phone, on a computer without terminal access, or checking a domain you do not own.

Look for tools that let you pick which DNS server to query, because results can differ between the authoritative server and a cached public resolver. If a record you just changed does not show up, it may be cached rather than wrong. Repeating the lookup against the authoritative server tells you whether the change is live or still waiting to propagate.

On a computer with a terminal, the classic tools give you more control. The dig command is the most detailed: running dig A example.com shows the answer section, the time to live in seconds, and which server answered. Replace A with MX, TXT, NS, or any other type to inspect that record, and add the address of a specific server after the domain to query it directly, for example by adding @8.8.8.8 to use Google's resolver.

Nslookup is available on Windows, macOS, and Linux and works interactively: type nslookup, then set the query type, then enter the domain. The host command is the simplest of the three, printing a one-line answer per record. All three are preinstalled on most systems, so there is nothing to download, and learning one of them covers nearly every DNS question you will meet in practice.

Start with the NS records, which name the servers responsible for the domain. If those servers are not the ones your DNS host expects, then changes made at your host will never take effect, which is the single most common cause of mysterious DNS failures after a transfer or hosting switch. Next, confirm the A record points to your hosting server's address and the MX records point to your mail provider.

Watch the TTL value as well. A long TTL means resolvers around the world may cache the old answer for hours after a change, which is why lowering the TTL a day before a planned migration is standard practice. If records look right at the authoritative server but wrong everywhere else, you are almost certainly looking at caching, and waiting out the TTL is the correct fix rather than changing records again.

One honest limitation: a normal lookup only shows records that are published and queryable. You cannot list every record for a domain in one shot, because full zone transfers are blocked on virtually all public DNS servers for security reasons. You query one record type at a time and assemble the picture yourself, which is fine for diagnostics but means you should keep your own copy of the zone file whenever you manage a domain.

With that caveat in mind, a DNS lookup is still the fastest first step in almost any domain troubleshooting workflow. Check the name servers, check the address and mail records, note the TTL, and you will know within a minute whether the problem is DNS at all — and if it is, exactly which record needs attention.