How to Read DNS Lookup Results

A DNS lookup shows how the internet finds a domain: where the site lives (A/AAAA), who handles mail (MX), which nameservers answer (NS), and extra text policies (TXT). Read each record type on its own line. Wrong or missing values can explain a failed site or email delivery, but correct DNS does not prove the service itself is healthy.

Run a live query with FindMyIP's DNS Lookup, then match what you see to the guide below. The query runs through the site’s server resolver, not your device’s resolver; it shows record values, not a global propagation check or a visitor DNS-leak test.

What DNS is doing (in one minute)

DNS is the phone book for domain names. Your browser asks for example.com. Resolvers return records that say which servers handle web, mail, and other services.

You do not need to memorize every record type. For day-to-day checks, five matter most: A, AAAA, MX, NS, and TXT. CNAME describes an alias and SOA describes zone administration and caching parameters; both are explained below.

A lookup is not WHOIS. WHOIS is registration metadata (registrar, dates, contacts). DNS is the live routing map. When nameservers look odd in DNS, cross-check them with WHOIS Lookup.

A records — IPv4 for the website

An A record maps a hostname to an IPv4 address.

Typical healthy pattern:

example.com → one or more IPv4 addresses
www.example.com → either its own A record, or a CNAME that eventually points at an A

What to check:

Empty A (and no useful CNAME): browsers cannot reach the site over IPv4. Confirm the hostname you typed (apex vs www).
Unexpected IP: compare against what your host or CDN documented. Sudden changes can mean a migrate, a CDN cutover — or a hijack. Look the address up with IP Lookup if you need ISP/org context.
Multiple A records: often normal (load balancing). All targets should still belong to your provider story.

A records answer "where does this name go on IPv4?" They do not prove the server is healthy — only that DNS points somewhere.

AAAA records — IPv6 twin

An AAAA record maps a hostname to an IPv6 address.

Many domains have A only. That is fine if you never enabled IPv6. Problems show up when:

You intended IPv6 but AAAA is missing or stale
AAAA points at a dead address while A still works (some clients prefer IPv6 and fail weirdly)

If users report "works on some networks, not others," compare A and AAAA. A mismatch between the two stacks is a classic trap.

MX records — where email goes

MX (mail exchanger) records say which hosts accept mail for the domain. Each line has a priority (lower number = tried first) and a hostname.

Healthy signs:

At least one MX if you expect inbox delivery at @yourdomain
Hostnames that resolve (follow them; they need A/AAAA of their own)
Priorities that match your mail provider's docs (Google Workspace, Microsoft 365, Fastmail, etc.)

Red flags:

No MX while you advertise email — check the mail provider’s required configuration. SMTP allows an implicit-MX fallback to the domain’s address records under defined conditions; missing MX does not by itself prove delivery is impossible (RFC 5321 §5.1)
MX pointing at your web host by accident — common after a DIY setup; web and mail are often different services
Stale provider MX after a migration — DNS still sends mail to the old stack

DNS does not show the contents of mail. It only shows the delivery door.

NS records — who answers DNS questions

NS (nameserver) records list the authoritative servers for the domain (or zone).

They answer: "Whose DNS panel is actually in charge?"

Useful checks:

NS set matches the DNS host you log into (registrar DNS, Cloudflare, Route 53, etc.)
After a DNS move, old NS values lingering means some resolvers may still follow the previous provider until TTL expires
NS in DNS should agree with what registration shows — again, WHOIS is the registration-side view

If A/MX look wrong in every public checker, confirm you edited records on the nameservers that NS actually points to. Editing the wrong panel is one possible reason a change never appears.

TXT records — policies and proofs

TXT records hold free-form text. Operators use them for:

SPF — which servers may send mail as your domain
DKIM — cryptographic signatures for mail authenticity (often long selector._domainkey names)
DMARC — domain alignment and policy for messages that fail DMARC evaluation
Domain ownership proofs — random tokens for Google, Microsoft, CDNs, certificate issuers

How to read them:

Multiple TXT records on the same name are normal
SPF should usually be one SPF policy string for the apex (or the exact name your provider specifies). More than one applicable SPF record produces permerror, even if the policies are identical (RFC 7208 §4.5)
DMARC lives at _dmarc.example.com. A message can pass DMARC through aligned SPF or aligned DKIM; it is not necessary for both to pass (RFC 7489 §3.1)
Ownership TXT values are meant to be temporary or permanent proofs — deleting the wrong one can break validation

TXT is where "email goes to spam" investigations often land after MX looks correct.

CNAME, SOA and TTL

A CNAME makes one name an alias of another. Follow the target before treating the lack of a direct A record as an error. An SOA identifies the zone’s primary server, serial and maintenance parameters. The SOA MINIMUM value concerns negative caching; it is not the remaining TTL of every record in the zone (RFC 2308).

TTL is normally a limit on how long a resolver caches a record. FindMyIP does not display ordinary record TTLs. Check your DNS provider’s settings or a resolver query that includes TTL when planning a change. Read DNS propagation and cached answers, then plan TTL changes before a domain move.

An illustrative zone might have an A record for www.example.com, MX records pointing at a mail provider, and a TXT SPF policy. Those records have separate purposes: changing the web address does not automatically move email.

A simple read-through checklist

Open DNS Lookup and query the apex (example.com) and www separately if both matter.
Confirm NS matches the DNS host you believe you control.
Confirm A/AAAA match your web/CDN targets.
Confirm MX match your mail provider and resolve.
Scan TXT for SPF/DKIM/DMARC and leftover proofs.
Wait for TTL if you just changed something — propagations are delayed by design, not by mystery.

If the records look correct but the page still fails, check whether the problem is DNS or the site. Test the service as well as its address.

Common mistakes (quick)

Editing registrar DNS while NS points at Cloudflare (or the reverse). Changes never go live.
Fixing only www and forgetting the apex (or the opposite).
Assuming HTTPS errors are DNS. Certificates fail for other reasons; DNS only gets the client to the right IP first.
Copy-pasting MX without checking priorities.
Two SPF TXT records that disagree.

Privacy note (short)

Public DNS lookups reveal how a domain is configured, not your personal browsing history. Your own resolver path is a different topic: default DNS often goes through your network operator. Encrypted DNS and a VPN change what that path exposes. The DNS Lookup tool reads public record values through the site’s resolver. It does not identify the resolver your browser uses or test whether your DNS traffic travels inside a VPN.

Put the record in context

Read DNS by record type, not as one blob. A/AAAA locate the site, MX routes mail, NS names the authority, TXT holds policy and proofs. When something breaks, match the symptom to the record, verify you are editing the nameservers in charge, then re-query until the public answer matches the panel you trust.

How we research and correct articles