Whether your website has stopped loading, email is bouncing, or a vendor has asked you to "verify your domain", sooner or later you will need to check DNS records. The good news is that DNS is public by design: anyone can look up the records for any domain, using either a browser-based tool or a command that is already installed on your computer. This guide shows you both approaches and, just as importantly, how to make sense of what comes back.
What you are actually looking at
The Domain Name System (DNS) is a distributed directory that turns names such as example.com into the information computers need: IP addresses, mail server names, verification strings and so on. Each piece of information is a record, and each record has a type. The ones you will check most often are:
- A and AAAA: the IPv4 and IPv6 address of a host.
- CNAME: an alias pointing one name at another name.
- MX: the mail servers that accept email for the domain.
- TXT: free text, used for SPF, DKIM, DMARC and ownership verification.
- NS: the name servers that are authoritative for the domain.
Every answer also includes a TTL (time to live), the number of seconds a resolver may cache it. Keep an eye on that number when you are troubleshooting a recent change.
Option 1: check DNS records in your browser
The quickest way, and the one that works from any device, is an online lookup tool. Enter the domain in our DNS lookup tool, choose a record type (or all of them) and the tool queries a public resolver on your behalf. This is handy when you are on a locked-down work laptop, on a phone, or helping a client who is not comfortable with a terminal.
If you have just made a change and want to know whether the rest of the world can see it yet, use the DNS propagation checker instead. It asks many resolvers in different countries at once, which tells you far more than a single lookup.
Option 2: dig on macOS and Linux
dig is the standard command-line tool for DNS. It ships with macOS and most Linux distributions (on Debian or Ubuntu it is in the dnsutils or bind9-dnsutils package). The basic form is dig name type:
dig example.com A
dig example.com MX +short
dig _dmarc.example.com TXT +short
dig example.com NSAdding +short strips the output down to just the values, which is ideal for a quick check. Without it, look at the ANSWER SECTION. A typical line reads:
example.com. 3600 IN A 192.0.2.10From left to right that is the name, the remaining TTL in seconds, the class (IN for internet, almost always), the type and the value.
Ask a specific server
By default dig uses whatever resolver your computer is configured with. To bypass caches and see what the domain's own authoritative server says, first find the name servers, then query one directly with @:
dig example.com NS +short
dig @ns1.your-dns-host.net example.com AIf the authoritative server returns the new value but your normal resolver returns the old one, your change is correct and you are simply waiting for caches to expire. You can also compare public resolvers, for example dig @8.8.8.8 and dig @1.1.1.1.
Follow the whole chain
dig +trace example.com starts at the root servers and walks down through the top-level domain to your name servers, printing each step. It is the best way to spot a delegation problem, such as the registrar pointing at name servers that no longer host your zone.
Option 3: nslookup and PowerShell on Windows
Windows does not include dig, but it has two built-in alternatives. nslookup works in Command Prompt and PowerShell:
nslookup example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8The optional last argument is the server to ask. Ignore the "Non-authoritative answer" line; it just means the reply came from a resolver's cache rather than directly from the domain's own name server, which is normal.
PowerShell's Resolve-DnsName gives tidier, more structured output and shows the TTL clearly:
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type MX -Server 1.1.1.1
Resolve-DnsName example.com -Type TXT -DnsOnlyThe -DnsOnly switch stops Windows from also consulting its hosts file and local name services, so you see what DNS alone returns.
Reading the results: common situations
| What you see | What it usually means |
|---|---|
| NXDOMAIN | The name does not exist at all. Check spelling, or the domain may have expired. |
| NOERROR with an empty answer | The name exists but has no record of the type you asked for. |
| SERVFAIL | The resolver could not get a valid answer, often a broken delegation or a DNSSEC validation failure. |
| A CNAME followed by an A record | The name is an alias; the resolver has followed it to the final address for you. |
| Different answers from different resolvers | A recent change is still propagating, or someone is using geo-based DNS. |
Practical checks worth knowing
- Email authentication. SPF lives in a TXT record at the domain itself, DMARC at
_dmarc.yourdomain, and DKIM atselector._domainkey.yourdomain. Our SPF, DKIM and DMARC checker looks all three up and flags common mistakes. - Who controls DNS. If a record you edited is not showing up anywhere, compare the NS records with where you made the change. Editing the zone at a provider your domain no longer uses is a very common mistake.
- Long TXT values. TXT strings longer than 255 characters are split into several quoted chunks. That is expected; they are joined back together when read.
- Trailing dots. A dot at the end of a name, such as
mail.example.com., means the name is fully qualified. Tools display it; you do not need to worry about it.
Key takeaways
- DNS records are public, so you can check them for any domain without logging in anywhere.
- Use an online lookup for convenience,
digon macOS and Linux, andnslookuporResolve-DnsNameon Windows. - Query the authoritative name server directly to separate a wrong record from a caching delay.
- Status codes such as NXDOMAIN and SERVFAIL tell you as much as the answers themselves.