Seven little text records decide whether your site loads, your email arrives, and your domain is yours. Most people manage them like a lottery ticket. Here is the operator's map.

Open your DNS management panel — Cloudflare, your registrar, wherever it lives — and you will see rows of cryptic entries: A, AAAA, CNAME, MX, TXT, a TTL column you have never touched. They are the highest-leverage configuration most website owners never read. Change one character in the wrong row and your email silently dies. Get them right and nothing on the internet cares where your server physically sits.

This is a field guide to the seven records that actually matter, what breaks when they are wrong, and how to read them like an operator instead of a tourist.

A and AAAA — where the name points

The A record maps your domain to an IPv4 address; AAAA does the same for IPv6. These are the records everything else hangs off. When someone types your domain, this is the answer the internet gets first.

Operator note: if your server has an IPv6 address, publish the AAAA record too. Plenty of mobile networks in Asia now prefer IPv6, and a missing record there means a noticeable minority of visitors take a slower fallback path. Also, keep your TTLs short (300 seconds) during migrations and raise them back to 3600 or more once stable.

CNAME — the alias

CNAME says "this name is really that name." www.example.com is commonly a CNAME pointing to example.com. The gotcha that bites everyone exactly once: a CNAME cannot coexist with any other record on the same name — including MX and TXT. So never put a CNAME on your root domain if you receive email there. Registrars and Cloudflare offer workarounds (CNAME flattening, ALIAS records), but the rule itself is baked into DNS.

MX — who receives your email

MX records point to the mail servers that accept email for your domain, each with a priority number where lower means "try me first." Get these wrong and incoming email vanishes with no error message your sender will understand — the single most silent failure mode in all of DNS. If you use a forwarding service or a provider like Google Workspace, their setup docs give you exact values. Paste them exactly; MX hostnames must end with a dot in some panels and break without one in others.

TXT — the proving ground

TXT records hold free text, and the internet has collectively decided to use them for verification and email security. Three TXT records matter: SPF (which servers may send email as you), DKIM (a cryptographic signature, usually published as a selector subdomain), and DMARC (what receivers should do with mail that fails the first two). If your emails land in spam, start here — a missing or malformed SPF record is the most common cause, and it takes thirty seconds to check with any online validator.

NS and SOA — who is authoritative

NS records name the DNS servers that are authoritative for your domain. This is the delegation your registrar publishes, and it must match what your DNS provider expects. Mismatched NS records are how domains "randomly stop working" after a provider migration. The SOA record holds zone metadata — contact email, serial number, refresh timings. You will rarely edit it, but when troubleshooting propagation, the SOA serial tells you whether the change you made actually took effect.

Reading DNS like an operator

Three habits separate professionals from guessers. First, verify from outside: dig +short example.com A and dig MX example.com tell you what the internet sees, not what your panel claims. Second, remember caching: the TTL column controls how long resolvers remember old answers, so a typo with a 86400-second TTL takes a full day to wash out. Third, change one record at a time and test between changes — DNS failures are almost always compound, and debugging three simultaneous changes is misery.

You do not need to memorize RFC 1035. You need to know which record does what, where the silent failures live, and how to check your work. That is the whole discipline.

Sources: RFC 1035 — Domain Names: Implementation and Specification (IETF) · Cloudflare DNS documentation · DigitalOcean DNS records tutorial