Authoritative DNS Lookup & Record Checker
Inspect live DNS records including A, AAAA, MX, TXT (SPF/DKIM), NS, CNAME, and SOA to diagnose email routing and hosting configuration.
A Practical Guide to DNS Records
📌 On this page
1. Every record type explained
A maps a domain to an IPv4 address. AAAA maps a domain to an IPv6 address. CNAME aliases one domain name to another (commonly used for "www" pointing to the root domain, or subdomains pointing to a third-party service). MX specifies which mail servers handle email for the domain, each with a priority number (lower priority number is tried first). NS lists the authoritative nameservers responsible for answering DNS queries for the domain. TXT holds arbitrary text data — most commonly domain-ownership verification codes and email authentication policies (SPF, DMARC). SOA (Start of Authority) contains administrative metadata about the DNS zone itself, including a serial number that increments each time the zone is edited.
2. SPF, DKIM, and DMARC: the email authentication trio
SPF (published as a root-domain TXT record starting with "v=spf1") lists which mail servers are authorized to send email on your domain's behalf — receiving servers check the sending IP against this list. DKIM adds a cryptographic signature to outgoing emails, verified using a public key published at a selector-specific subdomain (not the root domain), proving the message wasn't altered in transit. DMARC (also a root-domain TXT record, starting with "v=DMARC1") tells receiving servers what to do when SPF or DKIM checks fail — quarantine, reject, or take no action — and where to send failure reports. All three working together substantially reduce the chance of your domain being spoofed by spammers and improve deliverability for legitimate transactional email from WordPress, WooCommerce, and marketing platforms.
3. How DNS resolution actually works
When you look up a domain, the resolution process walks a hierarchy: a root nameserver directs the query to the correct top-level-domain (.com, .org) nameserver, which directs it to your domain's authoritative nameservers (the ones listed in your NS records), which finally return the actual record data. Most queries never touch this full chain in practice because resolvers at every level cache results for the record's TTL duration — this caching is exactly what makes DNS fast at global scale, and also exactly why DNS changes take time to propagate everywhere.
4. Using this tool to troubleshoot common problems
Website not loading after a host migration? Check whether the A record points to your new server's IP. Emails bouncing or landing in spam? Check for MX records (can email be received at all) and an SPF TXT record (is your sending infrastructure authorized). Domain verification failing for a third-party service (Google Search Console, an email marketing platform)? Look for the specific verification TXT record the service asked you to add. SSL certificate provisioning stuck? Confirm the A/AAAA/CNAME record actually points where your certificate authority expects before assuming the certificate system itself is broken.
5. DNS propagation and TTL, demystified
"Propagation" isn't really a single global event — it's the natural expiry of cached copies of your old DNS records held by resolvers around the world. Each record has a TTL (Time to Live, in seconds) that tells caching resolvers how long they may serve a cached answer before re-querying. A record with a 3600-second (1 hour) TTL means some resolvers may keep serving the old value for up to an hour after you change it. Lowering TTL in advance of a planned DNS change (a common practice before a migration or provider switch) shortens this window significantly, which is why the migration checklist recommends dropping TTL to 300 seconds 24-48 hours before a cutover.
Frequently Asked Questions
What is the purpose of inspecting DNS records?
DNS records route your domain name to the correct web server (A / AAAA), handle email delivery (MX), verify domain ownership (TXT), and establish authoritative nameservers (NS). Checking records helps diagnose website downtime, email delivery failures, and SSL provisioning issues.
What are SPF, DKIM, and DMARC TXT records?
SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC are email authentication protocols stored as DNS TXT records. They prevent spammers from spoofing your domain and ensure transactional emails from WordPress reach user inboxes without landing in spam.
How long does DNS propagation take?
DNS changes take anywhere from a few minutes up to 48 hours to propagate globally depending on the TTL (Time to Live) values set on your previous records and caching policies of intermediate ISP resolvers.
Does this DNS lookup tool prevent SSRF?
Yes. All domain queries pass through an SSRF validation layer that rejects private IP addresses (10.x, 192.168.x, 172.16-31.x), localhost, loopback addresses, and cloud metadata targets.
Why doesn't looking up my domain show a DKIM record in the TXT results?
DKIM records are not published on your domain's root TXT records — they live at a selector-specific subdomain in the format selector._domainkey.yourdomain.com, where "selector" is a name chosen by your email provider (Google uses "google", many ESPs use their own naming). To check a specific DKIM record, you need to know your provider's selector and look up that exact subdomain rather than the bare domain. This is a common point of confusion since SPF and DMARC ARE published directly on the root domain's TXT records, but DKIM deliberately is not.
What does an "A" record actually point to, and why might a site have multiple?
An A record maps a domain name to an IPv4 address — it's the core mechanism that lets a browser turn "example.com" into a server it can connect to. Multiple A records for the same domain are common with load-balanced infrastructure or CDNs, where DNS returns several IP addresses and clients pick one (often via round-robin or geographic routing), spreading traffic across multiple servers automatically.
Why does a domain sometimes have no MX records at all?
A missing MX record means the domain cannot receive email directly — this is normal and intentional for domains used purely for a website with no associated mailboxes (a marketing landing page domain, for example), or for subdomains that inherit mail routing from the parent domain. If you expect a domain to receive email and see no MX records, that is the direct cause of email delivery failures for that domain.