DNS Lookup & WHOIS at a glance
- What it does
- Look up DNS records for any domain - A, AAAA, MX, TXT, NS and CNAME - and understand what each record type does and why changes take time to appear.
- Where it runs
- In your browser, plus one request to a public DNS-over-HTTPS resolver
- Works offline
- No — it needs a live service to answer
- Cost
- Free, with no account and no usage limit
- Category
- Browser & Network
How to use the DNS lookup
- Enter a domain name without
http://- justexample.com. - Choose a record type, or look up the common ones together.
- Read the results. Each record shows its value and its TTL, the number of seconds resolvers may cache it.
What each record type does
| Type | Purpose |
|---|---|
A | Maps a name to an IPv4 address. The fundamental record. |
AAAA | The same for IPv6. |
CNAME | An alias pointing at another name. Cannot coexist with other records on the same name, which is why it is not allowed at a root domain. |
MX | Where email for this domain should be delivered, with a priority number - lower is preferred. |
TXT | Free-form text. In practice: SPF, DKIM and DMARC email authentication, plus domain ownership verification for various services. |
NS | Which name servers are authoritative for the domain. Changing these moves DNS hosting. |
SOA | Administrative metadata - the primary name server, an admin contact and timing values. |
CAA | Which certificate authorities may issue certificates for the domain. Cheap protection against mis-issuance. |
PTR | Reverse lookup, address to name. Mail servers check it and reject senders without one. |
Why DNS changes take time
"DNS propagation" is a slightly misleading phrase - nothing is pushed anywhere. What happens is that resolvers around the world hold cached answers until the TTL expires, and only then ask again. If your A record had a TTL of 86400, some resolvers will serve the old address for a full day after you change it.
The practical procedure for a planned migration: lower the TTL to 300 seconds at least 24 hours before the change, so caches everywhere are holding short-lived copies; make the change; verify; then raise the TTL again once you are confident.
Different people seeing different results during this window is expected, not a fault. It also explains why clearing your own DNS cache sometimes fixes what looks like a server problem - your resolver was holding a stale answer.
The TXT records that decide whether your email arrives
Three records now determine whether major providers accept mail from your domain. Missing or wrong, your messages land in spam regardless of content.
SPF lists which servers may send mail as your domain, as a single TXT record beginning v=spf1. Two SPF records is a configuration error that causes both to be ignored, and there is a hard limit of ten DNS lookups within one policy.
DKIM publishes a public key so receivers can verify a cryptographic signature your mail server adds to each message. It survives forwarding, which SPF does not.
DMARC tells receivers what to do when SPF and DKIM fail - none to monitor, quarantine to send to spam, reject to refuse outright - and where to send reports. Start at p=none, read the reports for a few weeks to find legitimate senders you had forgotten, then tighten.
Common DNS problems
- A CNAME at the root domain. Not permitted by the specification. Providers offer ALIAS or ANAME records that behave similarly, or use a redirect from the root to
www. - Records added at the wrong provider. If the NS records point at Cloudflare, changes made in your registrar's own DNS panel have no effect. Check NS first when a change seems to do nothing.
- A trailing dot mistake. Most panels append the domain to a bare name, so entering
mail.example.comcan silently createmail.example.com.example.com. - An expired domain. If everything vanishes at once, check the registration date before debugging anything else.
This tool queries a public DNS-over-HTTPS resolver, so the domain you look up is sent to that resolver. It is one of the few tools here that must make a network request - listed as an exception in our privacy policy.
Frequently asked questions
Up to the TTL of the record you changed, and sometimes longer where a resolver ignores short TTLs. Lower the TTL a day in advance of any planned change and the switch becomes near-instant.
Because you are asking different resolvers, and they cached the answer at different moments. During a change this is normal. Querying the authoritative name server directly gives the current truth.
An A record points at an IP address. A CNAME points at another name, which must then be resolved. Use CNAME for subdomains pointing at a service whose address may change; use A at the root, where CNAME is not allowed.
Most often missing or misconfigured SPF, DKIM and DMARC records. Check all three here, confirm there is exactly one SPF record, and that DMARC exists at _dmarc.yourdomain.com.
Yes. DNS is public by design - anyone can query any domain's records, and that openness is what makes the system work.
What this tool sends, and what it does not
Most OmniTool utilities make no network request at all. This one is an exception, and it is worth being precise about it: to do its job, this tool contacts a public DNS-over-HTTPS resolver, which receives the domain name you look up. That request goes directly from your browser to that service — we do not proxy it, and we never receive a copy of it or of the response.
Nothing else on this page is transmitted, and we keep no record of what you looked up. The privacy policy lists every tool on the site that makes an outside request, along with what our advertising partner collects.