Free DNS Lookup Tool — Check All DNS Records for Any Domain Instantly
Query A, MX, TXT, CNAME, and NS records for any domain name — instantly, free, no signup.
Querying DNS servers...
🚀 Help Us Build More AI-Powered Tools
We're working on bringing free AI tools to Bizmatepro — including AI writing, image generation, code helpers, and more. Your support helps us cover server costs and keep 100+ tools completely free, with no ads and no signup.
How to Look Up DNS Records for Any Domain
Enter any domain name in the search box above — for example, google.com, yourwebsite.xyz, or even a subdomain like mail.example.com. Click "Lookup Records" and within seconds you will see all available DNS records for that domain, organized by type: A, MX, TXT, CNAME, NS.
This tool is used by developers to verify domain configurations, sysadmins to diagnose mail delivery issues, SEO professionals to check domain ownership, and website owners to confirm their DNS settings after moving to a new host. No installation, no command line, no technical knowledge required — just type and get results.
Every DNS Record Type — Explained Simply
A Record (Address Record)
Maps a domain name to an IPv4 address. This is the most fundamental DNS record — it's what makes bizmatepro.xyz resolve to a server IP like 104.21.5.83. Every website needs at least one A record to be reachable on the internet. Multiple A records can exist for load balancing across multiple servers.
AAAA Record (IPv6 Address)
Same as an A record, but maps to an IPv6 address (e.g., 2606:4700:3031::ac43:c1e1). As IPv4 addresses become scarce, more websites are adding AAAA records so IPv6-capable networks can connect directly without NAT overhead, resulting in faster connections.
MX Record (Mail Exchanger)
Tells mail servers where to deliver email for a domain. When you send an email to someone@company.com, your mail server does an MX lookup to find the mail server handling that domain. Each MX record has a priority number — lower number = higher priority. Multiple MX records provide email redundancy. If you've set up Google Workspace or Microsoft 365, your MX records point to Google or Microsoft servers.
TXT Record (Text Record)
Free-form text data attached to a domain. Crucial for domain verification and email security. Most commonly used for: SPF (Sender Policy Framework — defines which servers can send email for your domain), DKIM (email signature verification), DMARC (email fraud policy), domain ownership verification for Google Search Console, Bing, Facebook, etc. If your emails are landing in spam, the TXT records are the first thing to check.
CNAME Record (Canonical Name)
Creates an alias that points one domain name to another. For example, www.example.com might have a CNAME pointing to example.com, so both addresses reach the same site. Also used heavily with CDNs (Cloudflare, Fastly) — your subdomain CNAME points to the CDN's edge address. Important: CNAME records cannot exist at the root/apex domain (e.g., you cannot CNAME example.com itself — only subdomains like www.example.com).
NS Record (Name Server)
Defines which DNS servers are authoritative for a domain — these are the servers that have the final say on all DNS records for that domain. When you register a domain with a registrar and then move it to Cloudflare or another DNS provider, you update the NS records at your registrar to point to the new provider's nameservers. NS records are set at the registrar level, not on the DNS server itself.
When Do You Actually Need to Check DNS Records?
Check your TXT records — a missing or incorrect SPF record is the #1 reason legitimate emails land in spam. Verify your DMARC and DKIM records are also properly configured.
After moving to a new host, verify your A record points to the new server IP. DNS changes can take 24–48 hours to propagate globally — this tool shows the current live record from our server.
Google asks you to add a TXT record to prove domain ownership. After adding it in your DNS provider, use this tool to confirm the TXT record is live and Google can read it.
Security researchers use DNS lookups to map out a target's infrastructure, identify mail providers, CDN services, and third-party integrations — all from publicly available DNS records.
After updating DNS records, use this tool to check if the changes are live yet. Compare results with what you expect — if the old values still show, propagation is still in progress.
DNS records reveal which email provider, hosting company, and CDN a website uses. MX records show if they use Google Workspace, Office 365, or another mail platform.
How DNS Actually Works — The Journey of a Domain Name
Every time you type a domain into your browser, a complex lookup process happens in milliseconds. Here is the full journey:
Your browser first checks its own cache. If you visited google.com recently, the DNS result is stored locally for the TTL (Time-To-Live) period — typically 300–3600 seconds. This makes repeat visits instant.
If not in browser cache, your OS checks its own DNS cache (ipconfig /displaydns on Windows). Then your router's DNS cache is checked. Many routers also cache DNS responses to speed up local network browsing.
Your device asks a recursive DNS resolver — typically your ISP's DNS server (or a custom one like 1.1.1.1 or 8.8.8.8). This resolver is the main workhorse that does the actual lookup on your behalf.
The resolver asks a Root Nameserver (there are 13 globally) who manages .com domains. The Root points to the TLD Nameserver for .com. The TLD server points to the domain's Authoritative Nameserver (e.g., Cloudflare's ns1.cloudflare.com), which has the final answer.
The IP address is returned to your browser, which connects to the web server. The result is cached at each level for the TTL duration. This entire process — touching multiple servers globally — typically completes in under 50 milliseconds.
TXT Records for Email Security — SPF, DKIM & DMARC Explained
Email spam and phishing are rampant because anyone can fake the "From" address in an email. Three DNS-based standards solve this problem:
Sender Policy Framework
First line of defense
Published as a TXT record, SPF lists all servers authorized to send email for your domain. Receiving servers check if the incoming email came from a listed IP.
Example SPF record:
v=spf1 include:_spf.google.com ~all
The ~all means "softfail" — emails from unlisted servers are marked as suspicious, not outright rejected.
DomainKeys Identified Mail
Cryptographic signature
Your mail server cryptographically signs each outgoing email. The public key is stored in a TXT record. Receiving servers use this key to verify the email wasn't tampered with in transit.
DKIM TXT record location:
selector._domainkey.yourdomain.com
The selector is chosen by your email provider (Google uses google, others vary).
Domain-Based Message Auth
Policy enforcement
DMARC tells receiving mail servers what to do when SPF or DKIM checks fail — none (monitor only), quarantine (spam folder), or reject (block outright). It also sends failure reports to you.
Example DMARC record:
v=DMARC1; p=reject; rua=mailto:dmarc@you.com
p=reject is the strictest policy — unauthenticated emails claiming to be from your domain are blocked entirely.
Understanding TTL — Why DNS Changes Don't Apply Instantly
TTL (Time-To-Live) is a number attached to every DNS record that tells resolvers how many seconds to cache the answer before fetching a fresh copy. It is the reason DNS changes don't apply the instant you click "Save" in your DNS panel.
300
seconds (5 min)
Short TTL — use before planned migrations or when you expect to change records soon. Changes propagate in minutes.
3,600
seconds (1 hour)
Standard TTL — good balance between propagation speed and resolver load. Most records use this.
86,400
seconds (24 hours)
Long TTL — reduces DNS query load for stable records (like NS records). Changes can take a full day to propagate globally.
Pro tip: If you're planning to migrate your website or change hosting, lower your TTL to 300 seconds at least 24–48 hours beforehand. This ensures that once you make the change, it propagates globally within minutes instead of a day.
Frequently Asked Questions About DNS Records
Why is my DNS lookup returning different results than what I set in my DNS provider?
This is almost always a caching issue. DNS records are cached at multiple layers — your browser, OS, router, ISP's resolver, and other resolvers worldwide — each for the duration of the record's TTL. If you just changed a DNS record, our tool queries a live resolver and may still return the old cached value. Wait for the TTL to expire, or use dnschecker.org to test propagation from dozens of locations worldwide. You can also flush your local DNS cache with ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache (Mac).
What is the difference between a CNAME and an A record?
An A record maps a domain name directly to an IP address (e.g., example.com → 93.184.216.34). A CNAME record maps a domain name to another domain name, not an IP (e.g., www.example.com → example.com). The resolver then follows the CNAME to get the actual IP. CNAMEs are useful when the underlying IP may change (like with CDNs), as you only need to update one A record and all CNAMEs pointing to it automatically follow. Never use a CNAME at your root/apex domain — use an A record or your DNS provider's ALIAS/ANAME feature instead.
My emails are going to spam — which DNS records should I check?
Check these three TXT records in order: 1) SPF — look up TXT records for your root domain and find one starting with v=spf1. Make sure your email provider's sending servers are included. 2) DKIM — look up TXT records for selector._domainkey.yourdomain.com (ask your email provider for the correct selector). 3) DMARC — look up TXT records for _dmarc.yourdomain.com. If any of these are missing, your emails are more likely to be flagged as spam. Most email providers (Google Workspace, Office 365, Mailchimp) have documentation explaining exactly which records to add.
How long does DNS propagation take after changing records?
Propagation time depends entirely on the TTL (Time-To-Live) value of the record you changed. If the old record had a TTL of 86400 (24 hours), resolvers that already cached it will serve the old record for up to 24 hours. If you had lowered the TTL to 300 (5 minutes) beforehand, the change would propagate globally in about 5–10 minutes. The global average propagation time (without pre-lowering TTL) is typically 2–4 hours, but in rare cases can take up to 48 hours for some resolvers. This tool shows the current value from our resolver — it may differ from what someone on another ISP sees.
Can I look up DNS records from the command line instead?
Yes — the standard command-line tools are nslookup (Windows, Mac, Linux) and dig (Mac and Linux, also available on Windows via WSL). Example commands: nslookup -type=MX google.com — shows MX records on Windows. dig google.com ANY — shows all record types on Linux/Mac. dig @8.8.8.8 google.com TXT — queries Google's public DNS resolver specifically for TXT records.
Our web tool saves you from opening a terminal and remembering the exact syntax — especially useful for quick lookups on mobile devices.