A DNS lookup queries the record types a domain publishes - A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA - and returns what is actually live on the authoritative nameservers right now.
What a DNS lookup covers
DNS is not one record type - it's a set of independent record types stored under the same domain name, each answering a different question. An A record answers "what IPv4 address hosts this name." An MX record answers "where does mail for this domain go." A TXT record answers "what arbitrary text has someone attached here," which is how SPF, DKIM, and domain-verification strings piggyback on DNS without needing a record type of their own. Querying all of them at once is the fastest way to get a full picture of how a domain is wired, rather than guessing which single record type is relevant.
Every record type this tool queries is defined by its own RFC: A and CNAME by RFC 1035, AAAA by RFC 3596, MX by RFC 1035 and RFC 5321, SOA by RFC 1035, NS by RFC 1035, PTR by RFC 1035, SRV by RFC 2782, CAA by RFC 8659. None of these records depend on each other to exist - a domain can have an MX record with no website, a website with no mail, or a CAA record restricting certificate issuance on a domain that otherwise resolves to nothing at all.
A lookup only reflects what resolvers see through the authoritative chain at query time. It is not a change log and does not show a record that existed yesterday but was edited or removed since - for that, a domain's registrar or DNS host is the source of truth, not a point-in-time query.
- A / AAAA - IPv4 and IPv6 addresses a hostname resolves to
- MX - mail exchange servers and their delivery priority
- TXT - arbitrary text used for SPF, DKIM, domain verification, and more
- NS - the nameservers authoritative for the zone
- CNAME - an alias pointing one name at another canonical name
- SOA - zone metadata: primary nameserver, serial number, refresh/retry/expire timers
- PTR - reverse mapping from an IP address back to a hostname
- SRV - service location records (port, weight, priority) for protocols that publish them
- CAA - which certificate authorities are allowed to issue certificates for the domain
Reading the results
Results are grouped by record type, with each record shown as a full line: the value, and where it applies, a TTL in seconds and a priority number. A domain that hosts a website and email will typically return an A (or AAAA) record for the site, MX records for mail, TXT records for sender verification, and NS records naming its nameservers - all in the same query, since these are independent record sets living under one name.
A TTL (time-to-live) is the number of seconds a resolver is allowed to cache that specific record before re-querying it. A low TTL (60-300s) means changes propagate fast but the authoritative servers get queried more often; a high TTL (3600s+) means fewer queries but slower propagation if the record changes. TTL is set per record, not per domain, so an A record and its domain's MX records can carry completely different TTLs.
MX and SRV records additionally carry a priority (and SRV a weight) that determines try order - lower numbers are attempted first. A CNAME record, if present, replaces every other record type at that exact name per RFC 1034 section 3.6.2: a name cannot have both a CNAME and an A record, for instance, which is why CNAME often shows up alone when it appears at all.
If nothing comes back for a record type, that means no record of that type is published - not that the lookup failed. A domain with no MX record simply has no configured mail; a domain with no CAA record has not restricted certificate issuance and any public CA can issue for it.
| Record type | Example value | What it tells you |
|---|---|---|
| A | 203.0.113.10 | IPv4 address the name resolves to |
| MX | 10 mail.example.com | Priority 10, mail handled by mail.example.com |
| TXT | v=spf1 include:_spf.example.com ~all | SPF policy authorizing senders |
| NS | ns1.example.com | Authoritative nameserver for the zone |
| CAA | 0 issue "letsencrypt.org" | Only this CA may issue certificates |
Why the same domain can show different things over time
DNS caching means a query run from two different networks, or the same network minutes apart, can return records that differ if a change was made recently and old values are still cached somewhere along the chain. This is normal and expected - it is what TTLs are designed to control, not a fault in the lookup itself.
A domain migrating providers - moving from one DNS host to another, or one mail platform to another - will show old and new values side by side for a window equal to roughly the longest TTL involved, before the old values fully age out of every resolver's cache. Checking A, MX, and NS together during a migration is the fastest way to confirm which parts have already cut over and which are still pointing at the old provider.
FAQ
What is the difference between a DNS lookup and a WHOIS lookup?
A DNS lookup queries the records a domain publishes - its IP addresses, mail servers, nameservers, and so on. A WHOIS lookup queries registration data instead: who registered the domain, through which registrar, and when it expires. The two draw from entirely separate systems; a domain can have complete DNS records and still show privacy-redacted WHOIS data, or vice versa.
Why does a domain sometimes have no A record but still resolves in a browser?
A hostname can resolve through a CNAME pointing at another domain that carries the actual A record, rather than having its own. Per RFC 1034, a name with a CNAME cannot also have an A record at the same name - the browser follows the CNAME chain to whatever A record sits at the end of it.
Can one name carry several different record types at the same time?
Yes, and most active domains do. The same name commonly holds A and AAAA (IPv4 and IPv6), MX for mail, and TXT for verification all at once, each answered independently for the query type asked. The one hard exclusion is CNAME: RFC 1034 forbids a name that has a CNAME from carrying any other type, which is why a CNAME always appears alone.
What does a missing NS record mean?
It usually means the query hit a name that is not itself a delegated zone - for instance, a subdomain served entirely from the parent zone's records rather than delegated to its own nameservers. The parent domain almost always still has its own NS records; the absence is specific to the queried name, not to DNS working at all.
Why does this lookup still show the old value right after I changed a record?
The lookup answers from whichever resolver it went through, and that resolver may still be holding the previous value in cache until the record's TTL expires. The edit is live at the authoritative nameservers the moment you save it - to confirm that, query the domain's own nameservers directly rather than a public resolver, which sidesteps the cached copy entirely.
Why does a TXT record query sometimes return more than one line for what looks like a single SPF record?
RFC 1035 caps a single TXT character-string at 255 bytes on the wire, but multiple quoted strings can be concatenated into one longer TXT record. A DNS lookup shows the full concatenated value; a value that looks split across quotes in raw zone-file form is still one logical record.