DNS records for humans: A, AAAA, MX, TXT, NS

The short version

Behind every website address is a set of hidden records that tell the internet where to send things, your web traffic, your email, and more. They're called DNS records, and they're public. Learning to read the main five (A, AAAA, MX, TXT, NS) lets you understand how a domain is set up, troubleshoot your own site, and spot when something looks off.

What's actually happening

DNS is the internet's phone book. People remember names like example.com, but computers need numbers (IP addresses). DNS translates the name into the number, and into a few other instructions, every time you visit a site or someone emails you.

A domain's records are its directory listing. Each record type does one job, like separate lines in a contact card: one line for the website's address, another for where email should go, another pointing to who's in charge of the whole listing.

Why it matters to you

• If your website or email isn't working, the answer is very often in these records.
• It helps you understand what a domain is really connected to (your email provider, your host).
• Some records (TXT) are how services prove a domain is legitimately yours, and how email gets protected from forgery.

How to read the main records

Use the lookup tool on this site, or any trusted DNS lookup, and type a domain. Here's what the five common types mean:

1. A record — the website's address in the older, numeric format (like 93.184.216.34). This is "where the site lives."
2. AAAA record ("quad-A") — the same idea, but in the newer IPv6 format (a long address with colons). Many sites have both.
3. MX record ("mail exchange") — where email for the domain should be delivered. If you see names like "google" or "outlook" here, that tells you who handles their email.
4. TXT record — free-form text notes. In practice these are used to verify ownership ("this domain really belongs to us") and to protect email from forgery (settings called SPF, DKIM, and DMARC).
5. NS record ("name server") — the servers that hold the master copy of all these records. This is who's authoritative for the domain, often your registrar or a service like Cloudflare.

How to check you're reading it right

Look up a big, familiar domain. You should see one or more A (and usually AAAA) records, MX records pointing at a recognizable email provider, several TXT records, and two or more NS records. If you own a domain and just set up email or a website, looking up your own records is the fastest way to confirm the change actually took effect.

What a normal result looks like

A healthy domain usually has: at least one A record (often an AAAA too), two or more NS records (having several is normal and good, it's for reliability), MX records pointing to a real mail provider if the domain uses email, and one or more TXT records including an SPF line (it starts with "v=spf1"). Missing MX records simply means the domain doesn't receive email, which is fine for a website-only domain. Changes don't appear instantly: DNS has a built-in delay (called TTL), so a record you just edited can take minutes to hours to show up everywhere.

Want to go further?

The Advanced version shows the exact commands (dig and nslookup), explains TTLs, CNAME vs. A, the SPF/DKIM/DMARC TXT records in detail, authoritative vs. recursive answers, DNSSEC, and how to trace a lookup from the root down.

Summary

DNS maps names to resource records (RRs). The five you'll read most are A (IPv4), AAAA (IPv6), MX (mail routing), TXT (verification and email auth), and NS (delegation/authority). Reading them well means querying authoritative servers, understanding TTLs and caching, and distinguishing record intent, especially the SPF/DKIM/DMARC conventions layered on top of TXT. The reference tools are dig (preferred) and nslookup.

What each record is

• A — maps a name to a 32-bit IPv4 address. Multiple A records enable round-robin/load distribution.
• AAAA — maps a name to a 128-bit IPv6 address. Dual-stack hosts publish both A and AAAA.
• MX — lists mail servers with a preference value (lower = higher priority); points to hostnames that must themselves resolve to A/AAAA (MX must not point to a CNAME).
• TXT — arbitrary strings. Conventional uses: domain-ownership verification tokens, and email authentication:
  • SPF: a TXT at the domain apex beginning v=spf1 ... listing authorized senders, ending in -all (hard fail) or ~all (soft fail).
  • DKIM: a TXT at selector._domainkey.domain holding the public key (v=DKIM1; k=rsa; p=...).
  • DMARC: a TXT at _dmarc.domain (v=DMARC1; p=reject|quarantine|none; rua=...) setting policy and reporting.
• NS — delegates a zone to its authoritative name servers. The parent zone's NS set and the child zone's own NS set should match.
• Related you'll meet: CNAME (alias to another name; cannot coexist with other data at the same name, never at the apex), SOA (zone authority/serial/timers), PTR (reverse IP-to-name), CAA (which CAs may issue certs), SRV (service location).

Why it matters

DNS is where most web/email outages and many security issues surface: a wrong A record points users at the old host; a missing or misconfigured SPF/DKIM/DMARC sends your mail to spam or lets others spoof you; mismatched parent/child NS causes intermittent resolution; a stale high TTL slows a cutover. Reading records authoritatively, not from a cache, tells you the true current state.

How to query, per tool

dig (Linux/macOS; Windows via BIND tools or WSL)

1. dig example.com A +short — just the IPv4 answer(s).
2. dig example.com AAAA +short, dig example.com MX, dig example.com NS, dig example.com TXT.
3. dig _dmarc.example.com TXT +short and dig selector._domainkey.example.com TXT +short for DMARC/DKIM.
4. Query a specific authoritative server to bypass caches: dig @ns1.example.com example.com A.
5. Trace the full delegation from the root: dig example.com +trace.
6. Read the header flags: aa = authoritative answer; the ANSWER section shows RR name, TTL, class, type, data.

nslookup (built in on Windows, also macOS/Linux)

1. nslookup example.com (default A/AAAA).
2. Typed queries: nslookup -type=MX example.com, -type=NS, -type=TXT, -type=AAAA.
3. Pick a resolver: nslookup example.com 1.1.1.1. Note nslookup is less precise than dig about authority and formatting.

Windows PowerShell

1. Resolve-DnsName example.com -Type MX (also A, AAAA, TXT, NS). Add -Server 8.8.8.8 to choose a resolver.

Web

1. Use this site's lookup or a reputable tool for a GUI view; good for a quick read and for checking propagation across multiple global resolvers.

TTLs, caching, and propagation

Each RR carries a TTL (seconds) governing how long resolvers cache it. "Propagation" is really cache expiry: a change is visible once old entries age out, so lower the TTL before a planned change. Query authoritative servers (dig @ns...) to see the new value immediately, versus a recursive resolver that may still serve a cached copy.

Edge cases and gotchas

• MX to CNAME is invalid; MX targets must be real A/AAAA names.
• CNAME at apex isn't allowed; providers emulate it with ALIAS/ANAME/flattening.
• Multiple SPF records break SPF, there must be exactly one v=spf1 TXT at the apex; watch the 10 DNS-lookup limit.
• Parent/child NS mismatch (lame delegation) causes flaky resolution; compare the registrar's delegation with the zone's own NS.
• DNSSEC: look for RRSIG/DNSKEY/DS; dig +dnssec shows signatures and the ad (authenticated data) flag from a validating resolver.
• NXDOMAIN vs. NOERROR/empty: "no such name" differs from "name exists, no record of that type."

How to verify

Confirm a change by querying the authoritative NS directly (dig @<ns> name type) rather than a cache, and check the returned TTL. For email, verify a single valid SPF, a published DKIM selector, and a DMARC policy at _dmarc. For a migration, lower TTLs ahead of time, cut over, then watch recursive resolvers catch up. dig +trace confirms delegation from root to the authoritative zone.

What a normal result looks like

A well-formed zone: one or more A (commonly plus AAAA), two or more in-bailiwick NS that match the parent delegation, MX records at sensible preferences pointing to a real mail provider (or none, for a web-only domain), exactly one apex SPF TXT, plus DKIM/DMARC if the domain sends mail, and consistent SOA serials. Absence of MX is fine for non-mail domains; multiple NS and A records are a reliability feature, not a problem. Treat duplicate SPF, MX-to-CNAME, NS mismatches, or a missing DMARC on a mail-sending domain as the things to fix.

Want to go further?

Pair this with the WHOIS/RDAP guide (NS in a lookup points you to the zone you inspect here) and with email-deliverability hardening (tighten SPF to -all, rotate DKIM keys, move DMARC from p=none toward quarantine/reject with reporting). For resolution privacy, explore DNS-over-HTTPS/TLS resolvers, and add CAA records to constrain which certificate authorities can issue for your domain.