DNS Lookup Tool — Check Any DNS Record Online Free

What Is DNS and Why Does It Matter?

The Domain Name System is the internet's phone book. When you type example.com into a browser, DNS translates that human-readable name into a machine-readable IP address — 93.184.216.34 — so your browser knows where to send the request. Without DNS, every website URL would need to be an IP address.

DNS records do more than just map names to addresses. They control email routing, verify domain ownership, store security policies like SPF and DKIM, and define which servers are authoritative for a zone. Knowing how to read and inspect DNS records is essential for system administrators, developers, and anyone managing a domain.

The Seven DNS Record Types This Tool Covers

How to Use the DNS Lookup Tool

1. Open the DNS Lookup tool.
2. Enter a domain name — for example github.com or google.com. You can paste a full URL; the protocol and path are stripped automatically.
3. Click Lookup. The tool queries all seven record types in parallel and returns results within a second or two.
4. Use the record type tabs to switch between A, AAAA, MX, TXT, NS, CNAME, and SOA results. Tabs for record types that returned no data are dimmed, so you can immediately see what is configured.
5. MX records are sorted by priority. TXT records each show their full string value. SOA records display all zone parameters in a labelled table.

DNS Lookup Use Cases

Advanced Workflows

Checking DKIM Records

DKIM (DomainKeys Identified Mail) records are TXT records stored on a subdomain in the format selector._domainkey.yourdomain.com. The selector is usually defined by your email provider — Google Workspace uses google._domainkey, SendGrid uses s1._domainkey. To verify a DKIM record, enter the full subdomain (e.g. google._domainkey.example.com) in the tool and inspect the TXT results. A valid DKIM record starts with v=DKIM1.

Verifying SPF Coverage

SPF records live as TXT records on the root domain. Look up TXT records for your bare domain (e.g. example.com) and find the record starting with v=spf1. It should list all the sending sources your domain is authorised to use — typically your mail provider, transactional email service, and any other systems that send mail on your behalf. A missing SPF record means emails may land in spam or be rejected by strict receivers.

Confirming DNS Propagation After a Migration

After pointing a domain to a new server, DNS changes take time to propagate — old records are cached by resolvers worldwide according to the TTL value. Use the SOA record to check the serial number: if different resolvers return different serial numbers, propagation is still in progress. The A record should eventually show the new server's IP across all resolvers. You can also pair this with the SSL Certificate Checker to confirm the new host's certificate is serving correctly.

Debugging Email Deliverability

Email deliverability problems usually trace back to DNS misconfiguration. The checklist:

• MX records — do they exist and point to the correct mail server? Is the priority order sensible (lower number = higher priority)?
• SPF — TXT record on root domain, covers all sending infrastructure
• DKIM — TXT record on the selector subdomain, starts with v=DKIM1
• DMARC — TXT record on _dmarc.yourdomain.com (enter this subdomain in the tool directly)

Checking a Subdomain Configuration

Subdomains like www.example.com, mail.example.com, or api.example.com each have their own DNS records. Enter the full subdomain in the tool to see its specific configuration — useful when a CDN, load balancer, or third-party service is attached via CNAME to a subdomain and you need to confirm the alias is resolving correctly.

Common DNS Pitfalls

CNAME records cannot be placed on the root (apex) domain

A CNAME record is an alias to another name. DNS specifications prohibit placing a CNAME on a bare apex domain (e.g. example.com) because that domain must also have an SOA and NS record — and a CNAME would conflict. This is why you see www.example.com as a CNAME but example.com itself uses an A record. Some DNS providers offer a proprietary ALIAS or ANAME record that behaves like a CNAME but is allowed at the apex; check your DNS provider's documentation.

Setting TTL too high before a migration

TTL (Time To Live) controls how long resolvers cache a DNS record. A TTL of 86400 seconds (24 hours) means it could take a full day for everyone to see an updated A record after you change it. Best practice: lower your TTL to 300 seconds (5 minutes) at least 24 hours before a planned migration. After the migration is complete and stable, raise the TTL back to something longer for performance.

Multiple TXT records and SPF conflicts

A domain can have only one SPF record. If you have multiple TXT records beginning with v=spf1, sending servers will fail SPF validation because the specification requires a single SPF record. Merge all sending sources into a single record. You can have multiple non-SPF TXT records for other purposes (DKIM, DMARC, verification tokens) without conflict.

Forgetting to check all nameservers agree

After making changes, all authoritative nameservers should return the same answer. If your domain has two NS records pointing to different providers and one is stale, some users will get old results. The SOA serial number should be identical across all nameservers.

DNS Lookup vs nslookup vs dig

Command-line tools like nslookup and dig perform the same queries as this tool but require a terminal and knowledge of the syntax. The DNS Lookup tool is faster for quick checks, returns all record types at once, and presents the results in a readable format — no parsing required.

If you also need to verify the HTTPS configuration on a domain, the SSL Certificate Checker handles that separately — it reads the TLS certificate the server presents, including expiry date, issuer, SANs, and TLS version. To check the IP address and ISP associated with a domain after resolving, use the What Is My IP tool to see your own network information.

Frequently Asked Questions

Why does a record type show no results?

Not every domain has every record type configured. No MX records means the domain does not accept email. No CNAME means no aliases are defined. The tool shows dimmed tabs for types with no records rather than errors, so the absence of a record is always visible.

Why might the results differ from what my browser sees?

Results depend on which resolver is queried. This tool uses the server-side resolver. Your browser may have cached an older result, or your ISP's resolver may have a different cached record. If a record was recently changed, different resolvers may show different results until propagation completes and caches expire according to the TTL.

Does the tool store the domains I look up?

No. The domain name is sent to the server to perform the lookup, and results are returned immediately. Nothing is logged or stored. No account is required.

Can I look up subdomains?

Yes. Enter the full subdomain — for example mail.example.com, api.example.com, or google._domainkey.example.com. The tool performs the lookup against the exact name you enter.