What does a DNS lookup return?
A DNS lookup asks the Domain Name System for records of one type stored at a name. Ask for A and you get IPv4 addresses; ask for MX and you get the mail servers that accept email for the domain. This tool sends your hostname and chosen type to our server, which queries its DNS resolver and prints each record it gets back on its own line.
Pick the record type from the menu (A is the default), enter a hostname like example.com, and click Test.
The six record types
| Type | Holds | Defined in | Output format here |
|---|---|---|---|
| A | An IPv4 address | RFC 1035 | 192.0.2.10 |
| AAAA | An IPv6 address | RFC 3596 | 2001:db8::10 |
| MX | A mail server and its preference number | RFC 1035 | 10 mx1.example.com |
| TXT | Free-form text, used for SPF and site verification | RFC 1035 | v=spf1 ... |
| NS | An authoritative name server for the zone | RFC 1035 | ns1.example.net |
| CNAME | An alias pointing at another name | RFC 1035 | example-shop.cdn.example.net |
The DNS concepts behind these (zones, delegation, aliases, caching) are described in RFC 1034, with the record formats in RFC 1035.
Sample outputs
The values below use documentation-only names and addresses to show the format exactly. Your real results will differ and can change at any time.
MX records for a domain with a primary and backup mail server:
10 mx1.example.com
20 mx2.example.com
The number is the preference. Mail senders try the lowest value first and fall back to higher ones (RFC 5321, section 5.1), so 10 is the primary here. Equal numbers share the load.
TXT records for the same domain, one per line:
v=spf1 include:_spf.example.net -all
google-site-verification=abc123
A TXT record can be stored as several strings of up to 255 characters each. They're joined into a single line here, which is how SPF expects them to be read (RFC 7208, section 3.3).
NS records list the servers authoritative for the zone:
ns1.example.net
ns2.example.net
Why CNAME lookups often come back empty
Searching example.com for a CNAME usually returns No CNAME records found for "example.com". That's expected. RFC 1034, section 3.6.2 says that if a CNAME is present at a name, no other data should be present. A zone's root name must carry NS and SOA records, so it can't also be a CNAME. Aliases belong on subdomains: looking up www.example.com with type CNAME is where you'd find a CDN target. Some DNS providers offer "ALIAS" or "flattened" records at the root, but those answer as ordinary A records, so they show up under A here, not CNAME.
Checking a domain's email setup
- Look up MX for the domain. No result means nothing tells other servers where to deliver mail for it.
- Run hostname to IP on each MX hostname to confirm it resolves.
- Look up TXT and find the line starting
v=spf1. There should be exactly one. - For outbound mail, check that your sending server's IP has a matching PTR record with IP to hostname.
- Look up TXT on
_dmarc.example.comfor the DMARC policy, and onselector._domainkey.example.comfor each DKIM key your mail provider publishes.
Limits of this tool
- Hostnames only. Enter a name with at least two dot-separated labels made of letters, digits, hyphens and underscores, so
_dmarc.example.comworks. A single trailing dot is accepted and dropped, and a Unicode name such asbücher.deis converted to itsxn--form before the query.https://prefixes and paths fail with "Enter a valid hostname". - Six types only. Other types return "Unsupported record type".
- No TTLs, no raw answer. You get the record data only, not time-to-live values, classes or the full DNS response.
- Cached, recursive answers. Results come from our server's configured resolver, not straight from your authoritative name servers. A just-changed record can lag until the old TTL expires, and providers that answer differently by location give the answer for our server's region.
If you're looking into a domain itself rather than its records, the domain age checker reads its registry creation date.
Last updated