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.