How to Look Up DNS Records for Any Domain

October 17, 2026 • NOFYI Editorial Team

Every time you type a web address into a browser, a quiet lookup happens behind the scenes. The browser needs an Internet Protocol address, a mail server needs to know where to deliver a message, and a website owner needs to know which records are pointing where. All of that information lives in the Domain Name System, usually called DNS. Learning how to look up DNS records for any domain is a useful skill whether you are setting up a website, moving a site to a new host, troubleshooting email, or simply trying to understand how the web fits together.

This guide explains what the main DNS record types mean, shows several ways to look them up, and walks through a worked example using example.com. It also explains propagation and caching, because those two ideas explain most of the confusion people run into after they change a record. You do not need to be a system administrator to follow along, and you do not need to install anything for the basic methods. You only need a domain name and a way to run a lookup.

What DNS Records Are

DNS is often described as a phone book for the internet. That comparison is helpful, but it leaves out an important detail. A phone book has one kind of entry. DNS has many kinds of records, and each kind answers a different question. When you look up a domain, you are asking a DNS server to return the records of a particular type for that name. The server may answer from its own data, or it may ask other servers until it finds an authoritative answer.

The records that most people meet first are A, CNAME, MX, and TXT. An A record maps a name to an IPv4 address, which is the numeric address a browser or another program uses to reach a server. An AAAA record does the same job for IPv6 addresses, which are longer addresses used by newer networks. A CNAME record maps one name to another name, so that one name can act as an alias for another. An MX record identifies the mail servers that accept email for a domain, and it includes a priority number so that mail can try one server before another. A TXT record stores text, and it is commonly used to prove ownership of a domain and to publish policies for email authentication.

There are other record types too. An NS record names the authoritative name servers for a domain. An SOA record holds administrative information about a zone, including how often secondary servers should check for changes. A PTR record is used for reverse lookups, which map an IP address back to a name. A CAA record can state which certificate authorities are allowed to issue certificates for a domain. For most everyday checks, however, A, CNAME, MX, and TXT cover the questions that matter.

How to Look Up DNS Records

There are three common ways to look up DNS records: an online DNS lookup tool, a built-in command on your computer, and your domain registrar or hosting control panel. The first two show public records. The third shows the records that your provider holds for a domain you control, which is useful when you want to compare what is published with what you intended to publish.

Using an online lookup tool is the simplest starting point. Search for a reputable DNS lookup tool, enter the domain name without a protocol such as https://, choose the record type you want, and run the search. Many tools let you choose A, AAAA, CNAME, MX, TXT, NS, and SOA in a dropdown menu. The result usually lists each record, its value, and its time to live, often written as TTL. The time to live tells other servers how long they may cache the answer before asking again. A short TTL means changes can spread faster, while a long TTL means answers may be reused for longer.

If you prefer a command line, the tools built into most operating systems work well. On Windows, you can open Command Prompt and run nslookup, followed by the domain name. You can also ask for a specific type by using a command such as set type=MX before the query, or by using nslookup with a type option depending on the version. On macOS and Linux, you can use dig, followed by the domain name and the record type, for example dig example.com MX. Another common command is host, followed by the domain and the type. These commands show the answer section, the query time, and the server that answered, which helps you tell whether you are seeing a cached answer or a fresh one.

When you are checking a domain you own, also look at the DNS settings in your registrar or hosting account. Those settings are the source of truth for what you have configured, even if the public internet has not picked up a recent change yet. Compare the provider panel with the public lookup. If the panel and the public result disagree, the difference is often caching or propagation, which are explained below. If they agree and the result is still wrong, the record itself probably needs to be corrected.

What Each Main Record Type Tells You

An A record answers the question, which IPv4 address should this name point to? If you look up the A record for a website and get an address, that address is where browsers will try to connect. If a domain has several A records, the name may be served by several addresses, and clients may use more than one of them. An AAAA record answers the same question for IPv6. Some domains have both A and AAAA records, which means they can be reached over both kinds of network.

A CNAME record answers the question, is this name an alias for another name? For example, a common setup is for www to be a CNAME that points to the main domain name. That way, when the main name changes its address, the www name follows it without a separate edit. A CNAME should not be mixed with other records for the same name in most setups, and it should not point to itself, because that creates a loop. If you see a CNAME that points to a name that does not resolve, that is a likely cause of an error.

An MX record answers the question, where should email for this domain go? The answer includes a priority, sometimes called preference, and a mail server name. Lower priority numbers are tried first. A domain may have several MX records, which gives mail a fallback if the first server is unavailable. The MX record points to a name, not directly to an IP address, so you may need a second lookup to find the address of that mail server.

A TXT record answers the question, what text has the owner published for this name? TXT records are used for many purposes, including sender authentication frameworks such as SPF, domain-based message authentication, and domain keys for email. They are also used for site verification, where a service asks you to add a unique string to prove that you control the domain. TXT records can be long, and they are sometimes split into quoted parts. When you read one, join the parts together in your mind to get the full value.

Worked Example: Looking Up Records for Example.com

Example.com is a domain reserved for use in documentation and examples. It is a safe choice for practice because it is not a real business site that you might disturb. The steps below show how to run the same check in a general way. Your exact numbers will change over time, because the people who maintain example.com can change its records, but the method stays the same.

First, look up the A record. Enter example.com and choose A. You should see one or more IPv4 addresses. Those addresses are the destination that a browser would use for the bare domain. Next, look up the AAAA record. You may see IPv6 addresses, or you may see no answer if IPv6 is not configured for that name at the time you check. Either result is informative. It tells you which network versions the name supports.

Next, look up the MX record. You should see mail server names and their priorities. Notice that the result is a name rather than an address. If you then look up the A record for that mail server name, you can see the address that mail would reach. This two-step pattern is common with MX records, and it is worth remembering when you are troubleshooting email delivery.

Next, look up the TXT record. You may see one or more text strings. Read them carefully. Some strings describe email policies, and others may be for verification. Finally, look up the NS record. The NS records name the authoritative servers for the domain. If you are ever unsure whether a public tool is showing a fresh answer, you can ask one of those authoritative servers directly with a command line tool. That comparison often settles the question of whether a change has been published or is still waiting to spread.

As you work through this example, write down three things for each record type: the question you asked, the answer you received, and the TTL. That small habit makes troubleshooting much easier. When a website or email service stops working after a change, your notes let you compare the old and new values instead of relying on memory.

Propagation, Caching, and Why Changes Take Time

When you change a DNS record, the change does not reach every computer at once. The change is made on the authoritative server, and other servers learn about it as their cached copies expire. The TTL controls how long a cached copy may be kept. A TTL of 3600 seconds means a server may reuse its cached answer for up to one hour. A TTL of 300 seconds means up to five minutes. This process is often called propagation, although it is really a mix of caching and the time it takes for servers to ask again.

Propagation explains a common experience: a site works for one person and not for another after a change. The two people may be using different resolvers, and one resolver may still hold the old answer. It also explains why a change can appear to undo itself for a while. A device or browser may hold an old answer in its own cache, even after the public servers have moved on. Clearing a local cache, trying a different network, or waiting for the TTL to pass are common ways to test whether you are seeing a stale answer.

Before you change a record, consider lowering its TTL in advance, if your provider allows it. A lower TTL means a future change will spread sooner, because servers will not hold the old answer as long. Lowering the TTL does not make the current change instant, because servers that already cached the old answer will keep it until it expires. It helps the next change. After the change is stable, you can raise the TTL again if you want longer caching.

Limitations of DNS Lookups

A DNS lookup tells you what is published, not why it was published. It cannot tell you whether a record is correct for your business, whether an IP address belongs to a trustworthy host, or whether a website is safe. An attacker can publish DNS records too, so the presence of a record is not proof that a site is legitimate. Use DNS lookups as one check among others, not as a complete security review.

DNS lookups also do not show private or internal records. Many organisations run internal DNS that is only visible inside their own network. A public lookup will not reveal those records, and that is by design. Similarly, a lookup cannot tell you who owns a server, how a site is built, or what data it collects. For those questions, you need other tools and sources, such as the site itself, its privacy notice, and its hosting information.

Another limitation is that a single lookup is a snapshot. DNS answers can vary by location, by resolver, and by time. If you need a fuller picture, check more than one record type, check more than one tool, and check again after the TTL has passed. If the answers disagree, note which server gave each answer and when. That context often explains the disagreement.

Do Not Change DNS Without a Backup

DNS changes can take a website offline or stop email delivery, even when the change looks small. Before you edit anything, take a backup of your current records. You can do this by taking a screenshot, exporting the zone file if your provider offers that option, or copying each record into a document. Record the name, type, value, priority if any, and TTL for every record. Keep that backup somewhere you can find it if you need to undo a change quickly.

Change one record at a time when you can, and test after each change. If you change several records at once and something breaks, it is harder to know which change caused the problem. After a change, check the public records, test the website, and test email if you changed an MX record. If something is wrong, restore the backed-up value and allow time for the old answer to spread again. Do not keep editing in a panic, because each new edit starts another waiting period.

If you are unsure whether a change is safe, ask your hosting provider or registrar for guidance before you save it. A short question can save hours of downtime. DNS is powerful and forgiving when you work slowly, but it punishes rushed edits.

Frequently Asked Questions

How long does it take for a DNS change to take effect?

It depends on the TTL and on caching at each level. A change can appear within minutes, but it can also take several hours for all resolvers to pick it up. As a rule, allow at least the length of the old TTL before you conclude that a change has failed. If you lowered the TTL before the change, the wait is usually shorter.

Why does a DNS lookup show a different result than my provider panel?

The most common reason is caching. Your provider panel shows what you configured. A public lookup shows what a particular resolver has cached or retrieved. Wait for the TTL to expire, try a different lookup tool, or query the authoritative server directly. If the answers still differ after that, check whether you edited the right domain or the right record.

Can I look up DNS records for any domain?

You can look up public DNS records for any domain that has them published. You do not need permission to run a normal public lookup, because DNS is designed to answer those questions. You should not use the information to harass anyone, to probe a system without permission, or to impersonate a domain. Use the results for learning, troubleshooting, and managing domains you control.

What should I do if a record looks wrong?

Do not edit a record for a domain you do not control. If the domain is yours, compare the public result with your backup, correct the value in your provider panel, and allow time for the change to spread. If the domain belongs to someone else and you are reporting a problem, share the record type, the value you saw, and the time you checked, so the owner can investigate.

Conclusion

Looking up DNS records is a practical skill that turns a mysterious error into a clear question. Start with the record type that matches your problem, check the answer and its TTL, and compare what is published with what you expected. Work through example.com to practise the steps, and keep a backup before you change anything on a domain you own. With that habit, DNS becomes less intimidating and much easier to troubleshoot.