DNS Lookup Tool

How to Look Up a Domain's DNS Records

Features

"Did You Check the DNS?"

It's usually the second question in any outage, right after "is the server up." A domain doesn't point anywhere on its own — it's a small stack of records telling the rest of the internet which server hosts the site, which servers are allowed to accept its email, and which nameservers get the final say. Type a domain in above and this tool pulls that stack directly from the source, so you're looking at what's actually published right now instead of guessing from a support ticket.

Who Actually Reaches for This

• Website administrators — confirming a domain resolves to the right server after a hosting migration
• Email administrators — checking MX and TXT records constantly while setting up SPF, DKIM and DMARC
• Developers — verifying a staging subdomain's CNAME before deploying, or checking CAA before requesting a certificate
• Domain buyers — confirming NS records show a transfer has genuinely completed, not just that the seller says it has
• Support teams — ruling DNS in or out as the cause of a "the site won't load for me" ticket, in under a minute

Reading the Record Types

An A record is the plainest one — it's the IPv4 address a name resolves to. Its sibling AAAA does the same job for IPv6, and plenty of domains simply don't have one yet. CNAME is an alias rather than an address, pointing one name at another — which is exactly why DNS won't let it sit alongside any other record at that same name. MX decides where mail for the domain actually goes, ranked by priority. TXT is the odd one out: free-form text that in practice almost always turns out to be SPF, DKIM or a site-verification string. And NS is the one that matters most during a migration, since it's what your domain registrar points to before anything else can be resolved at all.

Turn on Advanced Records and three more show up. SOA names the primary nameserver and a serial number that should tick upward every time the zone changes — useful for confirming an edit actually saved. CAA restricts which certificate authorities may issue an SSL certificate for the domain, and is worth checking first when a certificate request gets rejected for no obvious reason. SRV points at the host and port for a specific service, like internal chat or VoIP infrastructure, rather than the domain as a whole.

Two Opinions Are Better Than One

Most free lookup tools ask a single resolver and take its word for it — which is exactly how "the record looks wrong" turns into an hour of confusion that a DNS change actually caused, just not the way anyone expected. One resolver cached the old answer, the other already picked up the new one, and nothing about either is actually broken. Flip on Compare Two Resolvers and this tool asks Google and Cloudflare at the same time, flagging a mismatch the moment it sees one instead of leaving you to wonder whether the record was even saved correctly at your DNS provider.

The Two Moments This Actually Gets Used

The first is a migration cutover — a domain gets pointed at a new server, and someone needs to know whether the new A record is live everywhere or just on the one machine they're sitting at. If that machine happens to be a home server, our My IP Address tool confirms the public IP you're actually broadcasting, and IP Address Lookup tells you who owns whatever IP the domain resolves to on the other end.

The second is a deliverability complaint — customers say the emails never arrived, or landed straight in spam. TXT records are the first stop: a missing SPF entry, a broken DKIM selector, or a DMARC policy set to reject anything that fails authentication account for the overwhelming majority of these reports. The MX records confirm mail is even being routed to the right provider before you go looking any further.

Tips for Getting Reliable Results

• Drop the TTL a day ahead of any planned change, down to around 300 seconds. Resolvers won't hold onto the old value nearly as long, so the real cutover propagates in minutes instead of hours.
• Only one SPF record should ever exist per domain. Two separate "v=spf1" TXT entries is invalid by spec and can make mail providers fail authentication entirely, not just partially.
• A "resolvers differ" flag usually isn't an emergency. Give it the length of the old record's TTL and check again before assuming something's wrong.
• Check CAA before requesting a new certificate, not after it fails — it takes seconds here and rules out one of the most common silent causes of issuance errors.
• Chasing a webhook or API tied to this domain? Our URL Encoder/Decoder builds correctly encoded test request URLs against whatever host it resolves to.

When the Answer Looks Wrong (But Isn't)

An empty result for one record type almost never means the domain is broken — it usually just means that type was never configured, the same way most domains simply never bothered setting up IPv6. NXDOMAIN across every single type is a different story: that's a domain that isn't registered, lapsed, or had its zone deleted outright. And if a subdomain refuses to take a CNAME, check whether another record — often a leftover TXT verification entry — already occupies that exact name; DNS rules won't let the two coexist.

None of this reaches an authoritative nameserver directly, and it isn't a map of how a change looks from a dozen countries at once — it's two major public resolvers, which covers the overwhelming majority of real-world troubleshooting. For a genuine worldwide propagation map, or to query one specific authoritative nameserver before it's even reachable through public caches, a command-line tool like dig pointed straight at that nameserver is the next step up.