How to Check DNS Records for Any Domain: 5 Ways (2026)

Your site loads on your laptop but not on your phone. Emails to your shiny new address bounce. A verification TXT record "can't be found" even though you pasted it an hour ago. Nearly every one of these headaches comes down to one question: what does the internet actually see for this domain right now? Learning how to check DNS records answers that in under a minute, and it stops you guessing at fixes.

Quick Answer: To check a domain's DNS records, type the domain into a free DNS lookup tool, or run nslookup -type=MX example.com on Windows and dig example.com A +short on Mac or Linux. Choose the record type you need (A, CNAME, MX, TXT or NS), then query a public resolver such as 1.1.1.1 to confirm what visitors see. This method still holds as of September 2026.

This guide comes from the support desk at Hostaccent, a UK-registered host (hosting since 2016, UK-incorporated 2018) whose engineers resolve 20-30 client site issues every day. Roughly half of those tickets start with the exact checks below. We've written them out so you can run them yourself, and so that when a support engineer anywhere says "your DNS is pointing somewhere else," you can verify it in seconds instead of taking it on faith.

You'll get five methods, ordered from easiest to most precise, plus the checks that prove a change has really gone live and the mistakes that send people chasing the wrong fix. If record types like MX and CNAME still feel fuzzy, our plain-English primer, DNS records explained, is a good five-minute warm-up.

What a DNS Check Actually Tells You

A DNS check shows the records a domain publishes: which server hosts the website, which servers accept its email, and which text values prove ownership to services like Google. It also shows who answered and how long that answer may be cached, which matters just as much when something looks wrong.

Think of the Domain Name System as a directory split across thousands of servers. The Cloudflare Learning Center's overview of DNS walks through the full journey, but for troubleshooting you only need to know about two kinds of server:

• Authoritative nameservers hold the real zone for a domain. When you save a record in your control panel, this is where it lands, and it's live there within seconds.
• Recursive resolvers (your ISP's, Google's 8.8.8.8, Cloudflare's 1.1.1.1) fetch answers from the authoritative servers and cache them for as long as the record's TTL allows.

The ground rules for both were written down in 1987 in RFC 1035, the core DNS specification, and the basics haven't moved much since. These are the record types you'll look up most often:

| Record type | What it contains | Check it when | |---|---|---| | A / AAAA | The IPv4 / IPv6 address of the server | The site won't load, or loads the old server | | CNAME | An alias pointing to another hostname | www or a subdomain behaves differently from the root | | MX | Mail servers and their priority numbers | Email bounces or never arrives | | TXT | Free-form text (SPF, DKIM, DMARC, verification codes) | Verification fails or mail lands in spam | | NS | The authoritative nameservers for the zone | Your edits don't seem to do anything | | SOA | Zone serial number and timing values | You need proof that a zone actually updated |

A TTL (time to live) is the number of seconds a resolver may reuse a cached answer. A TTL of 3600 means one hour; 86400 means a full 24 hours. As of September 2026, most control panels default to somewhere between 300 seconds and 14400 seconds (4 hours), which is why two people can see different answers for the same domain on the same afternoon.

Why does my DNS look right to me but wrong to everyone else?

Because you and "everyone else" are asking different servers. Your laptop may still hold a cached answer from yesterday, your office network may use an internal resolver, and a visitor in another country may hit a resolver that refreshed ten minutes ago. None of those answers is wrong in a technical sense. They're just different ages.

So a useful DNS check always names the server it asked. A lookup against your domain's authoritative nameserver tells you what you configured. A lookup against a public resolver tells you what a typical visitor will get. When the two match, DNS isn't your problem, and you can move on to the web server, PHP, the SSL certificate, or the application itself.

How to Check DNS Records Online and on Windows

The fastest way to check any domain is a browser-based DNS lookup tool: type the domain, pick a record type, read the result. On Windows, the built-in nslookup command does the same job without a website in the middle, and it's already installed on Windows 10 and 11.

Method 1: A free DNS lookup tool in your browser

Any reputable DNS lookup tool works the same way. Enter the bare domain (example.com, without https:// or a trailing slash), choose a record type or "All", and pick which DNS server should answer. The better tools let you query the domain's authoritative server directly, which is the setting you want when you've just made a change.

This method suits beginners, phones, and locked-down work computers. It has two honest limits. First, some tools cache their own results for a few minutes, so a record you saved 60 seconds ago may not appear yet. Second, "All" queries often skip records they don't know to ask for, such as DKIM keys that live under a selector name. When a record seems missing, search for its exact hostname rather than trusting the "All" view.

A global propagation checker is a close cousin. Instead of asking one server, it asks resolvers in 20 or more locations and shows the answers side by side on a map. It's handy after a migration, as long as you remember that a red cross in one city usually means "cached old answer" and rarely means "broken."

Method 2: nslookup in Windows Command Prompt

Open Command Prompt (press Win + R, type cmd, press Enter) and run:

bashCopy
nslookup example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com

To ask a specific resolver instead of your default one, add its address at the end:

bashCopy
nslookup example.com 1.1.1.1

The first two lines of the output name the server that answered. The rest lists the records. If you see "Non-authoritative answer," the response simply came from a resolver's cache rather than from the domain's own nameservers. That's normal and doesn't mean anything is broken.

Pro Tip: To get an authoritative answer on Windows, first run nslookup -type=NS example.com, copy one of the nameserver hostnames, then run nslookup example.com ns1.yourprovider.com. The "Non-authoritative" line disappears, and you're looking at exactly what's stored in the zone right now, with no cache in the way.

PowerShell users get a cleaner option. Resolve-DnsName example.com -Type MX returns tidy columns (name, type, TTL and value), and adding -Server 8.8.8.8 picks the resolver. Because the output is structured, it's also easy to drop into a small script if you check the same handful of domains every week.

Using the dig Command: DNS Records on Mac and Linux

On macOS and Linux, dig is the most precise way to check DNS because it shows the full answer: the record, its remaining TTL, the status code, and which server replied. It ships with macOS, and on Ubuntu or Debian you can install it in about 10 seconds with sudo apt install dnsutils.

Method 3: dig, the tool engineers reach for first

dig comes from the BIND project maintained by the Internet Systems Consortium, and it's the command our own team opens before anything else. Learning to read dig command DNS records output takes about five minutes, and it pays off on every problem after that. These are the lines you'll use most:

bashCopy
dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com TXT +short
dig example.com NS +short
dig @1.1.1.1 example.com A
dig @ns1.yourprovider.com example.com A

The +short flag strips everything except the value, which is ideal for a quick look. Drop it when you need detail. A full response contains a few lines worth learning to read:

• status: NOERROR means the name exists. NXDOMAIN means it doesn't exist at all. SERVFAIL usually points to a broken DNSSEC chain or unreachable nameservers.
• flags: an aa flag means the answer is authoritative, straight from the zone, with no cache involved.
• ANSWER SECTION: the records themselves, with the remaining TTL in seconds in the second column.
• Query time: how long the lookup took in ms. It's a rough performance signal for the resolver, and a nearby public resolver often answers in well under 100 ms.

For stubborn problems, dig +trace example.com follows the lookup from the root servers, through the .com servers, down to the domain's own nameservers. If a delegation is broken, the trace shows exactly which step fails.

Insider Insight: Don't rely on dig example.com ANY. Since RFC 8482 was published in 2019, nameservers are allowed to send a minimal reply to ANY queries, and many large DNS providers do exactly that. An ANY lookup that returns one odd record doesn't mean the zone is empty. Query each record type separately instead.

Method 4: host, for a quick readable answer

host is the plain-spoken sibling of dig, installed alongside it. Running host example.com prints the A, AAAA and MX records as readable sentences, and host -t TXT example.com 8.8.8.8 asks Google's resolver for TXT records specifically. Use it when you want a yes-or-no answer without scanning a wall of output.

Windows users aren't locked out of either tool. The Windows Subsystem for Linux (WSL) gives you a full Ubuntu shell where dig and host behave exactly as shown here. ISC stopped shipping Windows builds of BIND some years ago, so WSL is the cleaner route in 2026.

◆ Professional help available

Still blocked at Cloudflare?

Send the error code, affected hostname, and recent DNS or SSL changes. We will separate edge, origin, firewall, and certificate causes before proposing work.

Request Cloudflare help→Explore Cloudflare support↗Hosted elsewhere? One-time paid support is available after scope and price confirmation.

Method 5: Your Control Panel, and How to Verify DNS Changes Propagated

Your hosting or DNS control panel shows the records stored in a zone, but those records only matter if the domain's nameservers point to that panel. Always run dig NS example.com +short first. If the nameservers belong to a different provider, edits made in this panel change nothing visitors will see.

Where to find the zone editor

In cPanel, open Domains, then Zone Editor, and click Manage next to the domain. In Plesk, go to Websites & Domains and open the domain's DNS Settings (under the Hosting & DNS tab in current versions). On Cloudflare it's DNS, then Records. At most registrars you'll find a "Manage DNS" or "DNS Zone" link beside the domain name.

The panel view is great for spotting typos and duplicates, since every record sits in one list. It can't tell you what resolvers have cached, though, and that's what the next step covers.

How to verify DNS changes propagated

"Propagation" is a slightly misleading word, because nothing gets pushed around the internet. Your authoritative server has the new record almost instantly, and every resolver that cached the old one keeps serving it until its TTL runs out. The only reliable way to verify DNS changes propagated is to compare the authoritative answer with what public resolvers return.

Across the 4,000+ site migrations Hostaccent has completed since 2016, the step people most often get wrong is switching nameservers before the new zone contains every record, especially MX and TXT. The website comes up fine, and email quietly breaks for a day. That pattern shaped the routine our engineers run first on any "I changed my DNS and nothing happened" ticket. We call it The Three-Server Check:

1. Ask the source. Run dig @ns1.yourprovider.com example.com A +short. If this shows the old value, the change was never saved, and waiting won't help.
2. Ask two big public resolvers. Run dig @8.8.8.8 example.com A +short and dig @1.1.1.1 example.com A +short. If both match the source, the change is live for most of the world.
3. Ask your own machine. Run dig example.com A +short with no server specified. If only this one is stale, the problem is local cache, not your DNS.

When a record with a TTL of 86400 seconds is changed, some resolvers can keep serving the old value for up to 24 hours after the edit. Nameserver changes take longer again, because the .com registry's delegation records carry a TTL of 172800 seconds, so a nameserver switch can take up to 48 hours to reach every resolver. Our guide on how to change nameservers covers that process step by step.

Pro Tip: Planning a move? Copy every existing record into a text file as a backup, then lower the TTL on your A and MX records to 300 seconds at least 24 hours before the switch. Once the old, long TTL has expired everywhere, your cutover reaches most visitors within about 5 minutes. Raise the TTL again a day later.

How to Check MX Record for Domain Email (Plus SPF, DKIM and DMARC)

To check the MX record for a domain, run dig example.com MX +short or nslookup -type=MX example.com, then confirm every listed hostname belongs to your actual mail provider. Email also depends on three TXT-based records (SPF, DKIM and DMARC), and a large share of delivery problems trace back to one of those four.

An MX answer looks like 10 mail.example.com. and the number is the priority. Lower numbers are tried first, so a server at 10 gets mail before a backup at 20. A few rules regularly trip people up:

• An MX record must point to a hostname, never directly to an IP address.
• That hostname needs its own A (or AAAA) record, and it shouldn't be a CNAME.
• If you moved email to a new provider, delete the old provider's MX entries rather than just giving them a higher number. Some sending servers will still try them.

Check the email authentication records

These live in TXT records, so the same tools work:

bashCopy
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig selector._domainkey.example.com TXT +short

Replace selector with the DKIM selector your mail provider gave you (common ones include default, google and mail). With the wrong selector the lookup returns nothing, which is a very common reason people wrongly decide their DKIM key is missing.

When you read the results, look for these specific problems:

1. Two SPF records. A domain must publish exactly one TXT record starting with v=spf1. Two of them cause a permanent error, and receiving servers may treat all your mail as unauthenticated.
2. Too many lookups. SPF allows a maximum of 10 DNS lookups per check. Stacking include: entries for a newsletter tool, a CRM and a helpdesk can quietly push you past the limit.
3. Split DKIM keys. A single TXT string holds at most 255 characters, so 2048-bit DKIM keys are split into several quoted chunks. That's normal. A missing chunk or a stray space is not.
4. No DMARC at all. Gmail and Yahoo have required DMARC from bulk senders since February 2024, so an empty _dmarc lookup is worth fixing even if you only send a few emails a day.

As of September 2026, a tidy small-business domain typically publishes one or two MX records, one SPF record, at least one DKIM key and one DMARC policy. If your checks show something more tangled than that, clean it up carefully before you blame the mail server.

Common DNS Checking Mistakes We See in Support Tickets

Most DNS "mysteries" come from checking the wrong thing. In our experience, the mistakes below explain a big share of DNS tickets that end up needing no server-side fix at all, and each takes under a minute to rule out once you know to look for it.

Editing the zone that isn't in charge. This is the pattern we see most often. Someone updates records at their registrar while the nameservers point to their host or to Cloudflare (or the other way round). The panel shows the new value, lookups show the old one, and nothing ever changes. Run dig NS before you edit anything.

Reading Cloudflare's IPs as a fault. When a record is proxied through Cloudflare (the orange cloud), an A lookup returns Cloudflare edge addresses, often starting with 104. or 172.67., rather than your server's IP. On Hostaccent's own stack, traffic passes through Cloudflare's WAF before it reaches Nginx and Apache, so this is expected behaviour. To confirm the origin, check the record in the Cloudflare dashboard instead of a public lookup.

Checking www and forgetting the root. example.com and www.example.com are separate names with separate records, and it's common to find the root on the new server while www still aliases to the old one. A plain CNAME also isn't allowed at the root of a zone, so some providers "flatten" it into A records. That can make a lookup look different from what you typed in the panel.

The trailing-dot trap. In many zone editors, a hostname without a final dot gets the domain appended automatically. Type mail.example.com into the wrong field and you may have created mail.example.com.example.com. A lookup of the name you intended shows nothing, which is your clue.

Trusting your own cache. Your computer and browser keep their own copies of DNS answers. Flush them before you conclude anything: ipconfig /flushdns on Windows, or sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS. Then test against a neutral resolver such as Google Public DNS to take your ISP out of the picture.

Forgetting negative caching. If you looked up a subdomain before you created it, resolvers may remember the "doesn't exist" answer for as long as the zone's SOA minimum allows, often 3600 seconds or more. Nothing is broken. It needs time, or a check against the authoritative server.

Missing the expired-domain case. When a domain lapses, the delegation can be pulled or swapped for a parking page, and every record seems to vanish overnight. If lookups suddenly return NXDOMAIN, check the expiry date first; our breakdown of domain renewal cost explains how to avoid that surprise. For the browser-side symptom of the same problem, see how to fix dns_probe_finished_nxdomain.

Your Next Step: A Host That Explains DNS in Plain English

Now that you know how to check DNS records yourself, you can prove in about a minute whether a problem sits in your DNS or on the server behind it. If it's the server, that's where a good host earns its fee. Economy — $1.99/mo gives you NVMe SSD storage, free SSL, and 24/7 support from engineers who read dig output as fluently as you now can, backed by a 99.99% uptime guarantee and a 30-day money-back window. One honest caveat: it's sized for a single website, so if you run several, Standard at $4.58/mo fits better. Your renewal price matches your signup price, which is how Hostaccent prices every plan. When you're ready, start on the Economy plan at $1.99/mo.

Frequently Asked Questions

How long does it take for DNS changes to show up?

Record changes usually appear within the old record's TTL, which is often 300 seconds to 4 hours, though some resolvers hold answers for up to 24 hours when the TTL is 86400. Nameserver changes are slower because the .com registry's delegation TTL is 48 hours. To see where things stand, compare your authoritative nameserver's answer with 8.8.8.8 and 1.1.1.1. If the source already shows the new value, you're simply waiting for caches to expire.

How to check DNS records from a phone or tablet?

Open any browser-based DNS lookup tool, type the bare domain without https://, choose a record type and run the query. That works on Android and iOS with no app to install. If you want command-line precision, several free network utility apps include dig-style lookups and let you pick the resolver. Remember your phone may use your mobile carrier's DNS, so switch off Wi-Fi or choose a public resolver when you compare results with a desktop test.

Why do different DNS lookup tools show different results?

Each tool asks a different resolver, and each resolver cached the record at a different moment. One might keep the old IP for another two hours while another refreshed five minutes ago. Some tools also cache their own results. Neither answer is lying; they're just different ages. To settle it, query the domain's authoritative nameserver directly with dig @ns1.provider.com example.com. That answer is the current truth, and everything else will catch up with it.

Can I check DNS records for a domain I don't own?

Yes. DNS is public by design, so anyone can look up the A, MX, TXT and NS records of any registered domain with the tools in this guide. That's useful for confirming a vendor's email setup, seeing where another company's site points, or checking a domain before you buy it. What you can't do is list every subdomain. Modern nameservers block full zone transfers, so you only see the names you specifically ask about.

What does NXDOMAIN or SERVFAIL mean in a DNS lookup?

NXDOMAIN means the name you asked about doesn't exist in DNS. The usual causes are a typo, a subdomain that was never created, or an expired domain whose delegation has been removed. SERVFAIL means the resolver tried but couldn't get a valid answer, typically because the nameservers are unreachable or a DNSSEC signature doesn't validate. As a rule of thumb, check spelling and expiry first for NXDOMAIN, and check nameserver health and DNSSEC settings for SERVFAIL.

Should my registrar or my host manage my DNS records?

Either can work, as long as only one of them is authoritative and you know which one it is. Trouble starts when records get edited in both places. When a Hostaccent customer's site breaks after a move, the first thing our engineers confirm is which provider the nameservers point to, because edits in the other panel do nothing. If you keep your domain and hosting separate, as described in buying a domain without hosting, write down which side runs your DNS.