DNS Lookup

DNS Lookup: Check Any Domain’s DNS Records

Enter a domain in Domain name, choose a Record type and where the Answer from should come from, then click Look up.

All common types returns A, AAAA, CNAME, MX, NS, SOA, TXT, CAA and DS together. SRV, PTR, DNSKEY and HTTPS records can be looked up one type at a time. Every value has its own Copy button, and the whole answer copies as zone-file lines, ready to paste into another DNS provider’s import.

Names with underscores work too, so you can look up _dmarc.example.com or a DKIM key at selector._domainkey.example.com. Enter an IP address and it’s turned into a PTR lookup of that address’s reverse name.

Cached or fresh: where the answer comes from

Answer from gives you two sources:

• Public resolver (cached): what a normal resolver currently has. Its TTLs are the seconds left in its cache, so this is what most visitors are getting right now.
• The zone’s own nameserver (fresh): the tool finds the domain’s nameservers and asks one of them directly. You see the records exactly as published right now, with their full TTLs.

The difference is easy to spot in google.com’s NS records:

Both answers are correct. Google gives out different IPv6 addresses from query to query, and the resolver kept the set it got earlier.

When you’ve just changed a record, ask the zone’s own nameserver first. If the change isn’t there, it hasn’t been published, and waiting won’t help. If it’s there but the cached answer still shows the old value, the old TTL hasn’t run out yet.

Reading the results: google.com

A and AAAA: where the website lives

A records hold IPv4 addresses and AAAA records hold IPv6 addresses. google.com returned six of each kind of record... six A records in 142.250.154.x and four AAAA records in 2a00:1450:4001:c0f::. Browsers pick one and try another if it doesn’t respond, which spreads traffic and keeps the site up when one server fails.

The 300 s next to them is the TTL: resolvers may keep these answers for five minutes.

NS: who runs the domain’s DNS

ns1 to ns4.google.com are the authoritative nameservers, the ones that hold the real records. After moving your DNS to a new provider, this is where you confirm the switch. If a domain has only one nameserver, the result points that out: any outage there takes the whole domain offline, so at least two are the norm.

SOA: the zone’s housekeeping

The result breaks the SOA record into its fields:

• Primary server ns1.google.com and contact [email protected]. DNS stores the contact as dns-admin.google.com, with the @ written as a dot.
• Serial: goes up every time the zone changes. Zones number it in one of three ways: as a date (2026102001 = 20 October 2026, change 01), as a Unix timestamp, or as a plain counter. The result says how the number reads.
• Refresh, retry and expire: tell secondary nameservers how often to sync.
• Negative TTL: how long resolvers remember that a record doesn’t exist. Google uses 60 seconds; some zones use an hour. That’s why a record you’ve just added can stay “missing” for anyone who looked a moment too early.

MX: where email goes

google.com receives mail at smtp.google.com, priority 10. The result spells out the priority and server separately, and points out a null MX (a domain that accepts no email). MX Lookup goes further: the addresses behind each mail server, the email provider, and SPF and DMARC in plain words.

TXT: labelled by what they are

google.com has 17 TXT records, and the tool labels them: SPF, DMARC, DKIM key, MTA-STS, TLS reporting, site verification and ACME challenge.

Most of Google’s are site verification codes: Google Search Console, Microsoft (MS=), Apple, Facebook, DocuSign and others, each proving to a service that Google controls the domain. Old codes do no harm; they just pile up. One record reads Z29vZ2xl, which is “google” encoded in base64.

The one that matters for email is the SPF record, v=spf1 include:_spf.google.com ~all. A domain should have exactly one. The result warns when there are several, because two separate SPF records break SPF completely.

DMARC and DKIM records live on their own names, so they don’t appear in a lookup of the bare domain. Look up _dmarc.example.com, or selector._domainkey.example.com with your provider’s selector.

CAA: who may issue certificates

0 issue "pki.goog" means only Google Trust Services may issue SSL certificates for google.com. A CAA record is a common hidden cause of failed certificate renewals: if it names one certificate authority and you switch to another, such as Let’s Encrypt, the new one is refused. Add the new authority before switching.

DS: is the zone signed?

A DS record at the parent zone (.com here) means the domain uses DNSSEC. google.com has none, so it isn’t signed, and the result says so. Most zones aren’t. When a zone is signed, the DNSKEY type shows its keys.

Readings in plain words

Besides the records, the result points out:

• An alias, and whose records you’re really seeing. A CNAME means the answers come from the name it points to.
• A CNAME at the apex. The bare domain can’t be an alias, because it must also hold SOA and NS records. DNS providers offer workarounds under names like ALIAS, ANAME or CNAME flattening.
• A single nameserver.
• DNSSEC, signed or not, from the DS record.
• The SOA serial read as a date or a Unix time.
• Several SPF records.
• A null MX.
• SERVFAIL for a specific type. One kind of record failing while others answer usually points to a fault at the DNS provider, or a DNSSEC problem.

Not found, or not there?

Two different “nothing” answers are kept apart:

• The name doesn’t exist (NXDOMAIN). A typo, a subdomain never created, or an expired domain.
• The name exists but has no records of that type. For example, _dmarc.example.com asked for an A record.

Either way, the result names the zone the name falls under. That tells you which DNS provider to check.

When to use it

Moving to a new host

After changing the A record, ask the zone’s own nameserver to confirm the new address is published, then check the cached answer to see what visitors get. Check AAAA as well. A leftover AAAA record pointing at the old server sends IPv6 visitors to the old site while everyone else sees the new one.

If you can plan ahead, lower the TTL to 300 a day before the move, so the change spreads quickly. DNS Propagation Check shows what other public resolvers have meanwhile.

Setting up email

After adding MX, SPF, DKIM and DMARC records, look up each name, including _dmarc and your DKIM selector, and compare it with what your provider asked for. The labels confirm each TXT record is what it should be.

Verifying a domain

Before clicking Verify in Search Console or another service, look up the domain with the zone’s own nameserver to see that the verification code is published. Then check the cached answer. If the service’s resolver checked a moment too early, the negative TTL decides how long it keeps saying “not found”.

Changing DNS providers

Look up All common types before the switch and copy the zone-file lines. They’re a record of everything the old provider served, and most providers can import them. After switching nameservers at your registrar, the NS records tell you when the change has gone through. Until they show the new provider, edits you make there won’t do anything.

FAQ

I changed my DNS. Why does my site still load from the old server?

An old answer is still cached somewhere: in your browser, your computer, your router or your provider’s resolver. Each copy lasts until the TTL that was set before the change runs out. Ask the zone’s own nameserver here to make sure the change itself is published. To clear the cache on your own machine:

• Windows: run ipconfig /flushdns
• macOS: run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

How long does propagation take?

For an ordinary record change, it takes as long as the old TTL, anywhere from five minutes to a day. Nameserver changes are slower, often up to 48 hours. The registry that runs the domain’s extension (Verisign, for .com) sets long TTLs on NS records.

Can DNS affect SEO?

Mostly through reliability. If your DNS provider goes down, Googlebot can’t resolve your domain, so it can’t crawl your site. Search Console’s Crawl Stats report flags DNS resolution problems under host status.

Speed matters less than people think. DNS time counts toward Time to First Byte, but resolvers cache answers, so most visitors don’t pay that cost on every page.

What’s the difference between this and Hostname to IP?

Hostname to IP resolves a name to its addresses, following aliases, with reverse names for each address. DNS Lookup shows every kind of record published for a name. To go from an IP to a name, use IP to Hostname.

Can I do this from the command line?

Yes:

• Linux/macOS: dig google.com MX asks your resolver. dig @ns1.google.com google.com MX asks the zone’s own nameserver, like the fresh option here.
• Windows: nslookup -type=MX google.com, or nslookup -type=MX google.com ns1.google.com for the nameserver.

You’d need one query per record type. The old dig ANY shortcut is now refused or cut short by most servers.