What is a DNS record? A, AAAA, MX, TXT, and the rest, explained

A DNS record is a small piece of structured information, stored in a name server somewhere, that tells the internet how to handle your domain. Every domain has several of them, each one a different type, each doing a different job. Most people who own domains never look at their records — they're configured once and then forgotten.

But every email that arrives, every website that loads, every subdomain that resolves — all of it depends on these records. When something stops working, the records are usually where you look first.

The format

Every DNS record has four parts: a name, a type, a value, and a TTL.

The name is the part of the domain the record applies to — the root (example.com), a subdomain (www.example.com, mail.example.com), or a wildcard. The type is the category — A, AAAA, MX, TXT, and so on. The value is what the record actually points at: an IP address, another hostname, an arbitrary string. The TTL — time to live — tells DNS resolvers how long they're allowed to cache the answer before re-checking.

That four-part structure covers everything below.

The types you'll actually see

A — the IPv4 address record

The most fundamental record. An A record maps a name to an IPv4 address. When you visit example.com, your computer asks DNS for that domain's A record and gets back something like 93.184.215.14. The connection happens to that address.

Every domain that serves a website or any IPv4-reachable service has at least one A record. The how to find a website's IP guide walks through how to read these in practice — A records are exactly what the lookup is returning.

AAAA — the IPv6 address record

Same idea as A, but for IPv6. The four As exist because IPv6 addresses are four times longer than IPv4 — 128 bits versus 32 — and naming the record type "AAAA" is a small joke that's stuck around since the 1990s.

The value is a hex IPv6 address like 2606:2800:21f:cb07:6820:80da:af6b:8b2c. Modern domains often have both A and AAAA records, so clients with IPv6 connectivity can use it and clients without can fall back to IPv4. The IPv6 explainer covers how the addresses themselves are structured.

CNAME — point one name at another name

"Canonical name". Instead of pointing at an IP address, a CNAME points at another DNS name. www.example.com CNAME example.com means "look up example.com instead". The resolver follows the chain and uses whatever address it finds at the end.

CNAMEs are convenient because they let you update one record and have several names follow. If you change the A record on example.com, every CNAME pointing at it automatically gets the new address.

One quirk: a CNAME can't coexist with other records on the same name. If example.com has any other records (which the root almost always does — at minimum SOA and NS), it can't also be a CNAME. This is why you'll often see CNAMEs on subdomains but not on the bare root domain.

MX — where to send mail

"Mail exchange". An MX record tells the rest of the internet which server should receive email for your domain. When someone sends mail to you@example.com, the sending mail server queries DNS for the MX records on example.com and connects to one of those servers to deliver the message.

Each MX record has a priority value alongside the hostname. Lower numbers are preferred — sending mail servers try the lowest-priority MX first, and only fall back to higher-priority records if the lower one isn't responding. This is how mail providers offer redundancy: a primary and a secondary mail server, with priorities like 10 and 20.

If your domain has no MX records at all, mail to that domain has nowhere to go and bounces. (Strictly, sending servers will fall back to the A record in this case, but in practice most modern setups always have MX records configured explicitly.)

TXT — free-form text

The most chameleon-like record type. Originally TXT was just "any arbitrary text you want to attach to a name", with no specific structure or meaning. Over time it became the catch-all home for ownership verification, email security policies, and assorted domain configuration that didn't fit any other record type.

You'll find TXT records doing all of these jobs:

• Domain ownership proofs — Google Search Console, Microsoft 365 setup, certificate authorities, payment processors, every SaaS that needs to verify you control a domain asks you to add a specific TXT record. They check it exists, that's the proof.
• SPF — a TXT record listing which servers are allowed to send mail on behalf of your domain. Receiving servers check it to detect spoofed sender addresses.
• DKIM — a public key, also stored as a TXT record, used to verify that an email's signature was generated by your authorised mail server.
• DMARC — a policy record that tells receiving servers what to do with mail that fails SPF or DKIM checks.

The combination of SPF, DKIM, and DMARC is the difference between your email reaching inboxes and being silently dropped. As the blacklist guide covers, these checks are part of why mail from misconfigured servers gets routed straight to the spam folder. TXT records that nobody manages tend to be how this happens.

TXT records are often the longest and messiest entries in any domain's zone — long base64-encoded keys, complex policy strings with arcane syntax, and a small archaeological layer of expired verification records nobody ever cleaned up.

NS — who's authoritative for this domain

"Name server". The NS records on a domain tell the wider internet which DNS servers are authoritative for it. When a resolver wants any record from example.com, it first looks up which name servers handle the domain — and those name servers are listed in the NS records.

NS records exist in two places: at the parent zone (the .com registry knows that example.com is hosted on Cloudflare's name servers, for instance) and at the apex of the domain itself. The two should match. NS records are usually managed by your DNS provider; you rarely edit them directly except when migrating to a different provider.

SOA — administrative metadata

"Start of authority". Every zone has exactly one SOA record, sitting at the apex. It contains administrative metadata: which name server is the primary, an admin contact email (formatted oddly because @ is illegal in DNS, so it uses a dot instead — admin.example.com means admin@example.com), a serial number that increments each time the zone changes, and timer values that control how secondary name servers refresh their copies of the zone.

You almost never edit the SOA record manually. DNS providers manage it automatically and most users never notice it exists.

PTR — reverse DNS

The reverse-DNS record. PTR records map an IP address back to a name — the opposite direction of A and AAAA records. They live in the special in-addr.arpa and ip6.arpa zones rather than in your domain's normal zone, and they're controlled by whoever owns the IP block, not whoever uses the IP.

The reverse DNS post covers exactly how the lookup mechanism works, why the PTR records are stored where they are, and why mail servers care about them so much.

CAA — who can issue certificates for this domain

"Certification Authority Authorization". A CAA record tells the world which certificate authorities are allowed to issue SSL/TLS certificates for your domain. Without one, any CA can issue a certificate for your domain — which has been the source of several real-world certificate mis-issuance incidents.

A CAA record naming, say, only Let's Encrypt and DigiCert means any other CA must refuse certificate requests for your domain, even if the requester somehow appears authorised. It's a small one-line addition to your DNS that materially reduces the attack surface for cert mis-issuance — and most domains still don't have one.

SRV — service location

An SRV record points at both a host and a port for a specific named service. The format includes a service name, protocol, priority, weight, port, and target host — for example, _sip._tcp.example.com for SIP-over-TCP. SRV records are heavily used in VoIP, XMPP, and Microsoft Active Directory environments. They're rare in everyday web hosting setups but central to certain protocols.

The records most people ignore but probably shouldn't

Three categories deserve a moment of attention.

SPF and DMARC TXT records. Without proper email authentication, modern mail providers (Gmail, Outlook, Yahoo) increasingly demote or drop your messages. If you send mail from a custom domain, the difference between "configured correctly" and "not configured" is often the difference between landing in the inbox and being silently dropped.

CAA records. Adding one is a five-minute job that meaningfully reduces the risk of someone obtaining a certificate for your domain through some other CA. Most domains don't have one, which is mostly an oversight rather than a deliberate choice.

DNSSEC records. RRSIG, DS, DNSKEY, NSEC, and friends — these are the records that cryptographically sign your zone, allowing resolvers to verify the answers haven't been tampered with. DNSSEC is genuinely complex, deployment is a non-trivial commitment, and most domains don't use it. Worth knowing exists; probably worth its own post some other time.

Where these records live

Records exist on whatever server is the authoritative name server for your domain. That's usually wherever you registered the domain — Cloudflare, Namecheap, Porkbun, or one of the various Google-Domains-successor registrars — or wherever you've explicitly delegated DNS management.

The chain of trust starts at the root: the root DNS servers know who runs .com. The .com registry knows who runs example.com (via NS records). And the authoritative server for example.com is where the actual A, MX, TXT, and other records are stored. When a resolver does a fresh lookup, it walks down this chain — root → TLD → your authoritative server — and asks each one for the next step.

TTL and the propagation myth

If you've ever changed a DNS record, someone has probably told you it could take "up to 48 hours to propagate". This is somewhat misleading, and worth understanding properly.

There is no global event that causes DNS records to "propagate". The actual mechanism is just caching. Every DNS record has a TTL — a duration in seconds that tells resolvers how long they're allowed to keep their cached copy before re-checking. If your TTL is 300 seconds, resolvers worldwide refresh the answer within 5 minutes. If your TTL is 86400 (one day), it can take that long for the change to be seen everywhere.

The "48 hours" figure is a worst-case fudge factor that accounts for unusually long TTLs, secondary caching layers, and the occasional misbehaving resolver that ignores TTLs entirely. In practice, with sensible TTLs, most changes are visible globally within minutes.

If you know a change is coming, lower the TTL on the affected records a day or two beforehand to something short like 300 seconds. Make the change, wait until the old cached entries have expired, and then raise the TTL back up. This is the standard playbook for migrations.