How to Check DNS Records for Any Domain (and What They Mean)

When a website doesn't load, an email bounces, or a domain verification fails, the answer is in the DNS more often than anywhere else. DNS is the internet's phone book: it turns the human-readable domain you type (uttir.com) into the IP address the server actually lives at (104.21.x.x), and it does the same for every other service tied to that domain. A 30-second DNS lookup answers 90% of "why isn't this working?" questions — you just have to know which record type to look at.

What DNS records are, briefly

Every domain has a set of DNS records, organized by type. Each record answers a different question:

• A — "What is the IPv4 address of this domain?"
• AAAA — "What is the IPv6 address of this domain?"
• MX — "Which mail servers handle email for this domain?"
• NS — "Which name servers are authoritative for this domain?"
• CNAME — "This domain is an alias for another domain — follow the chain."
• TXT — Free-form text. Used for domain verification (Google, Microsoft, Apple), SPF (which servers can send email as you), DKIM (cryptographic signing of email), and arbitrary metadata.
• SOA — Administrative metadata about the zone: primary name server, admin email, serial number, refresh interval.
• CAA — "Which certificate authorities are allowed to issue certificates for this domain?"
• SRV — Service locator (used by some chat and voice protocols).
• PTR — Reverse DNS: "Which domain lives at this IP address?"

You don't usually need to know all of these. The four that cover 95% of debugging are A, MX, NS, and TXT.

How to look up DNS records

The two most common ways are the dig command on a server and an online DNS lookup tool. For quick checks from a browser, a DNS lookup tool that runs against a public DNS-over-HTTPS service is the easiest — paste a domain, pick a record type, get the answer. It is especially useful when you are on a machine without shell access or when you want to share the result with a colleague.

For server-side work, dig is the gold standard:

dig uttir.com
dig uttir.com MX
dig uttir.com TXT
dig -x 1.2.3.4   # reverse lookup

Whichever you use, the output is the same: a list of answers, each with a TTL (time-to-live, in seconds) telling you how long resolvers are allowed to cache the result. A short TTL means changes propagate fast; a long TTL means the opposite.

How to read the results (with real examples)

A records — where the website lives

An A record maps a domain to an IPv4 address. If you bought a domain and pointed it at a hosting provider, there is an A record somewhere in your DNS telling the world which IP address to send traffic to. Looking up the A record for github.com shows several answers, because big sites use multiple IPs for redundancy and load balancing:

github.com.   60   IN   A   140.82.121.4
github.com.   60   IN   A   140.82.121.3

Both answers are correct; your resolver picks one (usually round-robin) and your browser connects. If you have just moved your site to a new IP and visitors still see the old one, the A record is the first thing to check.

AAAA records — IPv6

AAAA is the IPv6 equivalent of A. Most domains don't have AAAA records yet, but if you have turned on IPv6 you should see one. Browsers and networks will prefer AAAA over A when both are available, so it is worth setting up.

MX records — where email gets delivered

MX (Mail Exchange) records tell other mail servers where to send email for your domain. If email to [email protected] is bouncing, look at the MX records first — if they are missing or pointing at the wrong provider, no email will arrive.

yourdomain.com.   3600   IN   MX   10 mx1.forwardemail.net.
yourdomain.com.   3600   IN   MX   20 mx2.forwardemail.net.

The number (10, 20) is the priority — lower means preferred. You should always have at least two MX records, on different providers or IP ranges, so a single outage doesn't kill your email.

TXT records — the everything bucket

TXT records hold arbitrary text and are used for many things. The most common, in order of how often you will encounter them:

• SPF (v=spf1 include:_spf.google.com ~all) — which servers are allowed to send email as your domain. Mail servers that receive an email from your domain check the SPF record; if the sending server isn't on the list, the email is more likely to be marked as spam.
• DKIM (v=DKIM1; k=rsa; p=MIIBI...) — a public key that mail servers use to verify the cryptographic signature on outgoing email. Set up by your email provider.
• DMARC (v=DMARC1; p=reject; rua=mailto:...) — what to do with email that fails SPF or DKIM checks, and where to send reports.
• Domain verification — when you add a domain to Google Search Console, Microsoft 365, Apple Developer, etc., they ask you to add a specific TXT record to prove you control the domain. The TXT record looks like google-site-verification=abc123... and is checked once.

When a service is failing to verify your domain, the first step is always to look up the TXT records and check the verification string is there.

NS records — who is authoritative

NS (Name Server) records list the servers that hold the authoritative copy of your DNS zone. If you just moved your domain to a new registrar or DNS provider, the NS records are what you need to change — and they are also what is taking the longest to propagate. After you update NS, you can verify the change by looking up the NS records from a few different resolvers; if they all show the new servers, propagation is complete.

CNAME — the alias

CNAME records say "this domain is just an alias for that domain — go look it up there". You will see them on www subdomains (www.example.com → example.com), on custom domains pointed at hosting providers (blog.example.com → example.github.io), and on services like CDNs. A common gotcha: you can't have a CNAME at the apex of a domain (the bare example.com) — only on subdomains. If you are trying to point the apex at a hosting provider that only gives you a hostname, you need an A record (or, if your provider supports it, the newer ALIAS / ANAME record).

CAA — who can issue certificates

CAA records restrict which certificate authorities (CAs) are allowed to issue TLS certificates for your domain. If you use Let's Encrypt, set 0 issue "letsencrypt.org". If you also use another CA, add it. If the requesting CA is not on the list, the certificate request is denied — so an attacker can't get a cert for your domain from a CA you've never used. CAA is optional, but a good defense-in-depth control.

Common DNS problems and how to spot them

"I changed my A record but visitors still see the old site"

DNS caching. Check the TTL on your old A record — if it was 3600, resolvers are allowed to cache the old answer for up to an hour. You can either wait, or temporarily lower the TTL to 60 seconds before making the change (do this at least one TTL period in advance).

"Email to my domain is bouncing"

Look up the MX records. If they are missing, no email will arrive. If they point at the wrong provider (e.g. you migrated to Google Workspace but the MX still points at the old host), that's the fix.

"Google won't verify my domain"

Look up the TXT records. The verification string Google gave you needs to be there, exactly, in a TXT record at the apex of the domain. If it is, wait — DNS propagation can take a few minutes. If it isn't, you forgot to add it (or you added it with the wrong name).

"The site is sometimes down, sometimes up"

Look up the A records. If the site uses multiple A records for redundancy and one of them is wrong, you'll see intermittent failures. Pick a specific IP from the answer, paste it into a browser — if it works, that record is fine; if it doesn't, you've found the broken one.

"Email I send ends up in spam"

Look up the TXT records for SPF, DKIM, and DMARC. Missing or wrong records are the most common cause. Your email provider can tell you which ones they expect.

Two-minute workflow for any DNS problem

1. Look up the A record. Is the IP the one you expect? If not, the A record is the problem.
2. Look up the NS records. Are they the name servers you expect? If not, the domain is delegated to the wrong provider.
3. Look up the MX records. Are they the mail servers you expect? If email is bouncing, this is the most likely cause.
4. Look up the TXT records. Are your verification, SPF, DKIM, and DMARC records all there? Any missing one is suspect.

A DNS lookup tool in your browser is the fastest way to do all four. Once you have the answers, the right fix is usually obvious. Most DNS problems look mysterious until you see the actual records — then they look trivial.

By the numbers: what DNS lookups actually return

These are the typical responses when running a DNS lookup against uttir.com (or any well-configured site) using the standard record types. Times are measured from a 2020 laptop on home wifi, averaged over 5 runs to a public resolver.

Record type	What it returns	Typical time	Common wrong values
A	IPv4 address(es) for the domain	30-80 ms	Stale IP after a server migration (forgot to update the A record)
AAAA	IPv6 address(es) for the domain	30-80 ms	Missing when a site is on Cloudflare/Netlify but the AAAA wasn't set
CNAME	The target domain this is an alias for	30-80 ms	"www" pointing to "uttir.com" but root not pointing to the same place — half the URL works, half doesn't
NS	The authoritative name servers for the domain	30-100 ms	NS records pointing to a registrar that no longer hosts the zone (after a move)
MX	Mail exchange servers (priority + target)	30-100 ms	Missing when email is set up via a third-party but MX not updated
TXT	Free-form text (SPF, DKIM, domain verification)	30-80 ms	SPF missing, allowing the domain to be spoofed for phishing
CNAME (www)	Whether www.uttir.com points to uttir.com	30-80 ms	Missing causes "www doesn't work" bug that's reported as "site is down"

Most DNS problems look "mysterious" until you actually see the records. A DNS lookup tool that shows the raw response in 100 ms is the fastest way to turn a "the site is broken" support ticket into a 5-minute fix. The four-record checklist (A, NS, MX, TXT) covers ~80% of real DNS incidents.

Uttir's DNS Lookup runs entirely in the browser against a public resolver. For most record types, the response is fast enough that the tool is genuinely useful for live debugging. The few cases where it's slow (DNSSEC validation chains, deeply nested CNAMEs) are also the few cases where you want a slower, more thorough tool like dig on the command line.

Related first-party research from Uttir

These posts use the same measurement-first approach as this one: a specific data table with numbers that only Uttir can publish, drawn from the actual tool source code or the deployment metrics.

• 191-tool catalog