Fundamentals

DNS records explained: the building blocks every domain needs

A is for address, MX is for mail, TXT is for everything else. Here's what each DNS record type does, when you need it, and the mistakes that quietly break your domain.

Published May 25, 2026

What a DNS record actually is

A DNS record is a single line in a zone file — a small piece of public information attached to your domain that tells the rest of the internet how to reach you. When someone types example.com into a browser, their resolver walks the DNS, finds your records, and uses them to route the request.

Every record has a name (which subdomain it applies to), a type (what kind of thing it is), a TTL (how long to cache it), and a value. The whole system is built on a handful of record types. Knowing what each one does — and how it can go wrong — is the foundation of every other DNS conversation.

The record types you actually use

A and AAAA — addresses

The most common record. A maps a name to an IPv4 address; AAAA maps to an IPv6 address. If your site is at 203.0.113.10, you need an A record. If it’s also reachable at 2001:db8::1, add an AAAA record.

example.com.       IN  A     203.0.113.10
example.com.       IN  AAAA  2001:db8::1
www.example.com.   IN  A     203.0.113.10

You can have multiple A or AAAA records on the same name — resolvers will round-robin or pick based on the receiver’s policy. This is the simplest form of load balancing.

CNAME — alias

A CNAME says “this name is just another name for that name.” Use it when you want one subdomain to follow whatever address another name points to.

www.example.com.   IN  CNAME  example.com.
shop.example.com.  IN  CNAME  myshop.shopify.com.

Two big rules:

CNAME cannot live on the apex (example.com itself). For the root, use A/AAAA directly, or use an ALIAS/ANAME if your DNS provider supports it.
CNAME cannot coexist with any other record on the same name. No CNAME + MX on the same subdomain. The spec is strict.

MX — mail exchange

MX records say “send mail for this domain to these servers, in this priority order.” Lower priority number = tried first.

example.com.  IN  MX  10 mail1.example.com.
example.com.  IN  MX  20 mail2.example.com.
example.com.  IN  MX  10 mx.googlemail.com.

If you use Google Workspace or Microsoft 365, you’ll have a small set of vendor-provided MX records. If you have no MX record but you want to receive mail, some senders fall back to your A record — which is brittle and discouraged. Always set explicit MX.

TXT — free text (and the place auth records live)

TXT records hold arbitrary text. In practice, they’re where modern email authentication lives — SPF, DKIM, DMARC, MTA-STS — plus domain verification tokens for SaaS providers.

example.com.            IN  TXT  "v=spf1 include:_spf.google.com -all"
_dmarc.example.com.     IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."

A name can hold multiple TXT records — each one is independent. But only one SPF record is allowed per domain. Two SPF records is a misconfiguration.

NS — nameservers

NS records say “for this zone, ask these servers.” They’re how DNS delegation works. Your registrar publishes NS records pointing at your DNS provider; your DNS provider publishes everything else.

example.com.  IN  NS  ns1.cloudflare.com.
example.com.  IN  NS  ns2.cloudflare.com.

If your NS records disagree with what your registrar says, you have a delegation mismatch. DNSCheckPro catches this — it’s one of the most common silent failures on a freshly transferred domain.

CAA — who can issue certificates

CAA lets you whitelist which certificate authorities are allowed to issue SSL/TLS certs for your domain. Without it, any CA will issue a cert to anyone who proves domain control.

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"

CAA isn’t a hard security boundary (CAs can be tricked or compromised) but it raises the bar significantly and is required by many compliance regimes.

SRV — service location

SRV tells clients where to find a particular service. It’s used heavily by Microsoft 365 (_sip._tls, _sipfederationtls), SIP/VoIP, Matrix, Minecraft servers, and a few other protocols.

_sip._tls.example.com.  IN  SRV  100 1 443 sipfed.online.lync.com.

If you’re not running one of those services, you’ll never touch SRV. If you are, missing or wrong SRV records are why your client autodiscovery doesn’t work.

TTLs: how long records are cached

Every record has a TTL (time-to-live) in seconds. Resolvers cache the record for that long before re-asking. A 1-hour TTL means changes can take up to an hour to propagate.

High TTL (24h+): better performance, less DNS query traffic, slower to change.
Low TTL (5 min): changes propagate fast, more DNS queries. Useful right before a migration — set TTL low a day in advance so the cutover is quick.

A common move during migrations: drop TTL to 300s a day before the change, do the change, watch traffic move, raise TTL back to 3600s once stable.

The five most common DNS mistakes we see

Forgotten subdomains. A SaaS trial set up a CNAME at support.example.com two years ago. The SaaS account was cancelled, but the CNAME is still there — pointing at an IP someone else now controls. (This is “dangling DNS” and it’s how subdomain takeovers happen.)
CNAME on the apex. Trying to CNAME example.com → myhost.example.net. That’s invalid. Use A/AAAA or an ALIAS-style record from your DNS provider.
Multiple SPF records. Two TXT records starting with v=spf1. Receivers treat that as permerror, which is the same as having no SPF at all.
Missing NS agreement. What your registrar publishes for NS doesn’t match what your authoritative nameservers say. Resolvers can usually paper over it — until they can’t.
Stale MX after a mail provider switch. Old vendor’s MX still in the zone alongside the new one. Half your mail goes to the old server (which silently drops it).

How DNSCheckPro watches your records

Every record on every monitored domain is snapshotted on a schedule. When anything changes — added, removed, modified — we keep both versions and tell you what’s different and when. We also flag dangling CNAMEs, multiple SPF records, NS/registrar mismatches, and a few dozen other issues automatically. It’s the audit you’d run quarterly, on autopilot.

Next: dig into DNSSEC for cryptographic protection, or WHOIS vs RDAP for how we track domain expirations.