Advertisement
Server-side DNS resolver active

DNS Lookup Online
Free DNS Checker Tool to Query All DNS Records

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.

Query DNS Records for Any Domain

Enter a domain to dig DNS online and retrieve every record type with TTL values.

Advertisement
Robert Harrison, OSINT and Network Utility Expert at TrustMyIP
Written & Verified By

Robert Harrison

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 Harrison
Advertisement

What Is a DNS Lookup Online and Why Does It Matter?

A 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.

Advertisement

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.

DNS Record Types Explained: Complete Technical Breakdown

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.

A Record — The IPv4 Address Anchor

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.

Advertisement

AAAA Record — IPv6 Resolution

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 Record — Mail Server Routing

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.

CNAME Record — Domain Aliasing

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.

Advertisement

TXT Record — Security and Verification

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 Record — Nameserver Authority

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.

SOA Record — Zone of Authority

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 Record — Reverse DNS

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 Record — SSL Certificate Authority

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.

What the TTL Column Actually Tells You

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.

Free Tool to Find Hidden TXT Records for Domain Verification

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.

SPF — Sender Policy Framework

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 — DomainKeys Identified Mail

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 — Domain-based Message Authentication

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 Security: DNSSEC, Spoofing Protection and Modern Protocols

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 — Cryptographic DNS Validation

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.

DoH and DoT — Encrypted DNS Queries

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 and DDoS Mitigation

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.

DNS Record Lookup for Shopify and Microsoft 365 Setup Troubleshooting

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 Custom Domain Setup

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 (Outlook) Email Setup

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 Email Setup

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.

Why Is My MX Record Not Showing Up?

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.

How Long This Lookup Takes, and What That Number Means

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.

How DNS Resolves Domain Names: The Complete Query Lifecycle

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.

Running the Same Lookup From Your Own Command Line

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.

Using dig (Linux and macOS)

# 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

Using nslookup (Windows and macOS)

# 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.

Complete DNS Troubleshooting and Infrastructure Audit Checklist

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.

  1. A and AAAA: do they point at the server you expect? A stale A record is the single most common cause of “the old site is still showing”.
  2. MX: the right hosts, in the right priority order, and no CNAME at the same name.
  3. TXT: filter to TXT and confirm SPF is present and DMARC is published at _dmarc. Remember DKIM lives on a selector subdomain and will not appear here.
  4. NS: the nameservers you intend to be using, and no leftovers from a previous provider.
  5. CAA: present, and naming the authority that actually issues your certificates.
  6. SOA: note the serial before and after a change — if it does not move, your change did not save.
  7. TTL: lower it on records you are about to change, a day before you change them, then put it back.
  8. PTR: for a mail server, make sure the address has reverse DNS that matches the name it announces.
  9. After any change: confirm what your nameservers are actually serving, rather than what a cache remembers.
  10. Certificate: re-check it after the domain moves, because a new server means a new certificate chain.

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.

Frequently Asked Questions About DNS Lookup

What is a DNS lookup and how does it work?

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.

What is the difference between "no records found" and "domain not found"?

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.

Why is my MX record not showing up in DNS lookup?

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.

What is the difference between A and AAAA DNS records?

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.

Why does my TXT record appear split into several pieces?

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.

What are CAA records and why do they matter for SSL?

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.

Can I run these lookups from my own command line?

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.

What DNS records do I need for Shopify or Microsoft 365?

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.

Related DNS & Network Tools

Complete your domain and network audit with our free toolkit.

Query Any Domain’s DNS Records Instantly
Free DNS Checker Tool — No Signup Required

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