Use our free DNS lookup online tool to check DNS records for any domain. This DNS checker tool queries from our server rather than your browser and returns A records, AAAA (IPv6), MX (mail), CNAME, TXT, NS, SOA, PTR (reverse DNS) and CAA records with TTL values. Verify SPF, DKIM and DMARC entries, and see exactly what a domain publishes.
Quick Answer: What Is a DNS Lookup?
A DNS lookup online queries the Domain Name System to translate a domain name into IP addresses and return the other records published under it. This DNS checker tool fetches A, AAAA, MX, CNAME, TXT, NS, SOA, PTR and CAA records in one request, from our server rather than your browser, and shows the TTL on each one so you can see how long a resolver is allowed to keep it.
Enter a domain to dig DNS online and retrieve every record type with TTL values.

OSINT & Network Utility Expert
Robert specialises in DNS management, port scanning, network forensics and OSINT investigations. He helps system administrators and security professionals audit domain infrastructure and read what the protocol is actually reporting.
This page was rebuilt in September 2026 after an audit found that selecting a record type a domain does not publish produced a “DNS Resolution Failed” error on perfectly healthy domains. That is now three separate messages, and several claims the page could not support were removed rather than reworded.
Last reviewed 24 September 2026
View All Articles by Robert HarrisonA DNS lookup online queries the Domain Name System — the internet’s phone book — to translate human-readable domain names into machine-readable IP addresses and to retrieve the other records published under that name. When you type “google.com” into your browser, a DNS query happens behind the scenes to find the server’s address so your browser knows where to connect.
Our DNS checker tool goes beyond basic resolution. It fetches every record type configured for a domain: A records (IPv4 addresses), AAAA records (IPv6 addresses), MX records (mail servers), CNAME records (aliases), TXT records (security and verification), NS records (authoritative nameservers), SOA records (zone authority), PTR records (reverse DNS) and CAA records (SSL certificate authority). That complete picture is what you need to diagnose email delivery failures, verify domain ownership, troubleshoot a hosting migration or audit your security posture.
DNS is one of the few systems on the internet where a single wrong character has whole-site consequences: a misconfigured record can take a website offline, stop every incoming email, or let someone else’s mail claim to come from your domain. The Domain Name System has been doing that job, largely unchanged in shape, since the early 1980s.
How this tool asks: the query is sent from our server, not from your browser, so the answer is not your own machine’s cached copy. It still travels through a resolver, though, so what you see can be up to one TTL old. If you need to know what your own nameservers are serving right now, that is a different question and it has its own tool.
Understanding each DNS record type is essential for managing your domain infrastructure. Our dig DNS online tool returns all of these with their values and TTL information.
The A record is the most fundamental DNS record. It maps a domain directly to an IPv4 address such as 142.251.46.206. Every website needs at least one. Multiple A records enable round-robin distribution across servers. If your A record points to the wrong address after a hosting migration, your domain shows someone else’s content or a connection error.
The AAAA record (Quad-A) maps a domain to an IPv6 address such as 2001:4860:4860::8888. With IPv4 addresses exhausted at the registry level, IPv6 adoption keeps rising, and a modern site should publish both A and AAAA so that visitors on either protocol can reach it.
MX (Mail Exchange) records tell the internet which servers handle email for your domain. Each carries a priority value, and sending servers try the lowest number first. If your primary mail server (priority 10) is unreachable, backups at 20 and 30 receive the message instead, which is what stops mail bouncing during an outage.
A CNAME (Canonical Name) record makes one name an alias for another — pointing blog.example.com at example.ghost.io, for instance. A CNAME cannot coexist with other record types at the same name; RFC 1034 section 3.6.2 puts it plainly: “If a CNAME RR is present at a node, no other data should be present.” That is why an apex domain can never be a CNAME, and why adding one to a hostname makes its MX records stop working.
TXT records hold text used for domain verification, email authentication and security policies. The three most important are SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication). Without them your mail is far more likely to be filtered or rejected.
NS (Nameserver) records declare which DNS servers are authoritative for your domain. When you point a domain at Cloudflare or at your host, you are setting nameservers — and every other record you publish lives at whichever nameservers those point to.
The SOA (Start of Authority) record carries metadata about the zone: the primary nameserver, the responsible administrator’s address, a serial number that increases with every change, and the refresh, retry, expire and minimum timers. The serial is how secondary nameservers decide whether they need a fresh copy of your zone.
PTR (Pointer) records do the reverse: they translate an IP address back into a host name. Receiving mail servers use them to check that a sending server’s address matches the name it claims, and a missing PTR is a common cause of deliverability trouble. Check one directly with our reverse IP lookup tool.
CAA (Certification Authority Authorization) records name the certificate authorities permitted to issue SSL certificates for your domain. Without one, any CA in the world can issue a certificate for it. Use the filter above to check whether a domain publishes any, and confirm the certificate itself with our SSL certificate checker.
Every record above carries a TTL, in seconds. It is not a countdown to anything happening on your server. It is permission: it tells any resolver that asks how long it may keep this answer before coming back for a fresh one. RFC 1035 section 4.1.3 defines it as “a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded.”
So a record with a TTL of 3600 can sit in a resolver’s memory for an hour after you change it, and once that answer has been handed out there is nothing you can do from your side to shorten the hour. That is why a record you have already corrected can still be served in its old form, and why this page and your browser can disagree about the same domain.
A TTL of zero is a real instruction rather than an empty field. RFC 1035 section 3.2.1: “Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached.”
Waiting on a change you just made? That is a different question from “what does this domain publish”, and it has its own tool. Our DNS propagation checker asks seven public resolvers and every one of your own nameservers what they are handing out right now, and shows the seconds left on each cached copy. For the step-by-step fix, read how to fix DNS propagation delay for new domains.
TXT records do far more than store text. Our DNS checker tool reveals all of them, including the email authentication and verification entries that many basic tools skip over.
An SPF record lists the servers authorised to send email using your domain in the envelope sender. A correct one makes it much harder for a spammer to forge mail that appears to come from you. The record begins with v=spf1 and names authorised sources, for example include:_spf.google.com for a Google Workspace domain.
DKIM adds a cryptographic signature to every outgoing message. The receiving server checks that signature against a public key published in your DNS as a TXT record. DKIM keys live on a subdomain of the form selector._domainkey.yourdomain.com, which is why they do not appear in a lookup of the domain itself — you have to know the selector to find the key.
DMARC builds on SPF and DKIM and tells receiving servers what to do when authentication fails: report it, quarantine the message, or reject it outright. The record is a TXT record published at _dmarc.yourdomain.com. To read and validate an existing policy rather than just view the raw text, use our DMARC checker.
# Example SPF record (Google Workspace):
"v=spf1 include:_spf.google.com ~all"
# Example DMARC record, published at _dmarc.yourdomain.com:
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"
# To find them here: enter the domain, then set the filter to TXT
If your mail is landing in spam, the first step is to check DNS records for missing or malformed SPF and DMARC entries. The filter above labels each one it recognises by the version tag the record itself declares, so nothing is guessed from a keyword.
DNS was designed in the 1980s without built-in authentication. That opens the door to DNS spoofing (cache poisoning), man-in-the-middle interception and DNS hijacking. Three later additions address different parts of the problem.
DNSSEC (DNS Security Extensions) adds signatures to DNS records. A validating resolver checks each signature against the zone’s own public key, published as a DNSKEY record inside the zone; the parent zone vouches for that key by publishing a DS record, which is a hash of it. Follow the chain up to the root and a forged answer fails validation instead of being believed.
What this tool does not do: it does not validate DNSSEC. It reads the records a resolver returns and reports them. If you need to know whether a zone is signed and whether validation succeeds, that requires a DNSSEC-aware query, which is a different check from the one on this page.
Ordinary DNS queries travel over UDP and TCP port 53 in plain text, so anyone on the path — an ISP, a public Wi-Fi operator, an attacker — can see every domain you look up. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt that traffic. Major browsers and the large public resolvers support both.
Anycast DNS announces the same address from many locations at once, so a query is answered by whichever site is nearest. That cuts latency and spreads an attack across the whole network rather than concentrating it on one machine. If you want the mechanism explained properly, read our guide to how anycast routing works.
Practical tip: switching your own device to a resolver that supports DoH or DoT stops your ISP reading your lookups. It does not change what your domain publishes, and it does not change what this page returns — the query here leaves our server, not yours.
One of the most common reasons to reach for a DNS checker tool is to confirm records during a platform setup. Here is what each of the big three asks for, and what usually goes wrong.
Shopify asks for two changes: an A record pointing to 23.227.38.65, and a CNAME for www pointing to shops.myshopify.com. Add both at your DNS provider, then check them here. If the A record still shows a different address, a resolver is holding an older copy. The full walkthrough is in our Shopify DNS records setup guide.
Microsoft 365 needs an MX record at <your-token>.mail.protection.outlook.com with priority 0, a TXT record for SPF (v=spf1 include:spf.protection.outlook.com -all), a CNAME for autodiscover pointing at autodiscover.outlook.com, and a TXT record for domain verification. Confirm all four here before you press verify in the Microsoft admin centre — a failed verification is usually one record that has not been picked up yet.
Google Workspace now uses a single MX record: smtp.google.com. Google’s own admin documentation, read in September 2026, states that “the Google Workspace MX record value is smtp.google.com”, and that domains set up before 2023 may still have the older five aspmx records — “if your email is working, no changes are required”. Both sets are supported, so seeing either one in a lookup is normal. Add SPF as a TXT record, and DKIM as a TXT record on the selector Google gives you.
The usual causes are: the record was added to the wrong zone or the wrong host name; a CNAME exists at the same name, which RFC 1034 does not allow alongside other data; or a resolver is still serving an older copy. The first two are settings you can fix immediately. For the third, our DNS propagation checker asks your own nameservers directly, which is the only way to tell a caching delay apart from a record that was never published.
The lookup time shown with your result is the wall clock for this whole page’s work: eight record-type queries one after another, plus a reverse lookup for each A record found. It is not the time to resolve a single name, and it should not be read as a measure of your DNS provider’s speed.
It is still useful in one specific way. If it climbs towards the eight-second budget, or the Not checked notice appears, something did not answer in time — usually a slow or unresponsive nameserver, or an answer too large for a UDP packet whose TCP retry did not complete. Either is worth investigating, because the same delay is paid by every visitor and every mail server that looks the domain up.
For the speed of one query rather than nine, use a command-line tool: dig prints a Query time line for each lookup it performs. To check whether the machine behind an address is reachable at all, a ping test answers that separate question.
Understanding the full resolution process makes most DNS problems easier to place. Here is what happens when a browser needs to resolve a name, step by step.
# DNS query lifecycle (what happens when you visit google.com):
1. Browser checks its own DNS cache
→ hit? use it. miss? continue.
2. Operating system checks the stub resolver cache
→ hit? return it. miss? forward to the configured resolver.
3. Recursive resolver (for example 8.8.8.8) checks its cache
→ hit? answer. miss? begin iterative resolution.
4. Resolver asks a ROOT server (.)
→ root replies: "ask the .com servers"
5. Resolver asks a .COM server
→ .com replies: "ask ns1.google.com, it is authoritative"
6. Resolver asks the authoritative nameserver
→ authoritative replies with the A record
7. Resolver caches the answer for the TTL it was given
8. Address returned to the browser, connection begins
Steps 1 to 3 are why two people can get different answers for the same domain at the same moment, and why this page’s answer can differ from your browser’s. For the full version with the parts this summary leaves out, read our guide to how DNS resolves domain names to IPs.
Everything this page does can be done from a terminal, and it is worth knowing how — not least because you can then ask one specific server rather than whichever one your machine is configured to use.
# Just the answer section, nothing else
dig example.com A +noall +answer
# Only the values
dig example.com MX +short
# Ask one particular resolver
dig @1.1.1.1 example.com TXT
# CAA records, for certificate authority checks
dig example.com CAA +short
# Follow the resolution path from the root down
dig +trace example.com
# Default record type
nslookup example.com
# A specific type
nslookup -type=MX example.com
# Against a chosen resolver
nslookup -type=TXT example.com 1.1.1.1
Do not use ANY. It used to return every record at a name; it no longer does. RFC 8482 section 4.1 allows a server to “decline to provide a conventional ANY response”, and section 4.2 says that where a record is synthesised instead, “a single HINFO resource record SHOULD be returned”. Run dig example.com ANY against a major resolver today and a perfectly healthy domain will look almost empty.
If you would rather not use a terminal, the filter above gives you the same information with the record types labelled. To scan the ports behind a resolved address afterwards, our port scanner takes it from there.
Whether you own one website or manage many, this is the order worth working through after any migration, nameserver change, mail provider switch or certificate renewal.
_dmarc. Remember DKIM lives on a selector subdomain and will not appear here.Best practice: run the whole list after any hosting migration, nameserver change, email provider switch or SSL renewal. DNS misconfiguration remains one of the most common causes of both website downtime and mail delivery failure, and almost all of it is visible in a single lookup.
A DNS lookup online asks the Domain Name System to translate a domain name into IP addresses and to return the other records published under that name. This DNS checker tool sends the query from our server rather than from your browser, so what you see is not your own machine’s cached copy. It returns A, AAAA, MX, CNAME, TXT, NS, SOA, PTR and CAA records with their TTL values.
They are two different answers and this tool never merges them. Domain not found means the name does not exist in DNS at all, so nothing is published under it. No records found means the name exists but carries no record of the type you asked for — a domain with mail but no website has MX records and no A record, and that is a healthy answer. A domain’s apex can also never carry a CNAME, because it already carries SOA and NS records.
Common causes: the record was added to the wrong zone or the wrong host name, a CNAME record exists on the same hostname (CNAME and MX cannot coexist), or a resolver is still holding an older copy. Our DNS propagation checker will tell you which of those it is, because it asks your own nameservers directly as well as the public resolvers.
An A record maps a domain to an IPv4 address (32-bit, for example 192.0.2.1). An AAAA record maps it to an IPv6 address (128-bit, for example 2001:db8::1). Both do the same job for different versions of the protocol, and a modern domain should publish both so that visitors on either can reach it.
Because DNS stores text in chunks. A TXT record is made of one or more character strings and no single string may exceed 255 octets, so anything longer — a long SPF record, a DKIM public key, a verification token — is published as several strings that a reader joins together with nothing in between. This tool shows the strings as published. If a value looks broken in the middle, check the join: a key pasted into a control panel that inserts a space or a line break there is one of the most common ways a correct record stops working.
CAA records name the certificate authorities allowed to issue SSL certificates for your domain. Without one, any CA in the world can issue a certificate for it. Adding CAA records narrows that down to the authorities you actually use. Use this DNS lookup online tool to check whether your domain publishes any, then confirm the certificate itself with our SSL checker.
Yes. On Linux or macOS, dig example.com A +noall +answer returns the answer section only, and dig example.com MX +short returns just the values. On Windows, nslookup -type=A example.com does the same job. Add a server address — dig @1.1.1.1 example.com A — to ask one particular resolver. Avoid ANY queries: since RFC 8482 a server may answer them with a single synthesised record, which makes a healthy domain look almost empty.
Shopify: an A record pointing to 23.227.38.65 and a CNAME for www pointing to shops.myshopify.com. Microsoft 365: an MX record at <token>.mail.protection.outlook.com with priority 0, an SPF TXT record, an autodiscover CNAME and a verification TXT record. Add them at your DNS provider, then use this tool to confirm each one is published.
Complete your domain and network audit with our free toolkit.
This DNS lookup online tool fetches A, AAAA, MX, CNAME, TXT, NS, SOA, PTR and CAA records with their TTL values, so you can see exactly what a domain publishes and how long a resolver may keep it.
Last updated 24 September 2026 · queries sent from our server through the system resolver