DNS Records Explained — What A, CNAME, and TXT Records Actually Point To

“Configuring a domain” usually boils down to “adding a DNS record.” Setting up a subdomain, improving email deliverability, proving ownership of a domain to some external service — the goals differ, but the actual task is often the same: add one line in a domain management panel. This post walks through three of the most common DNS record types — A, CNAME, and TXT — what each one actually points to, and two real examples from our own domain.

What DNS is resolving

Between typing wpmm.jp into a browser and a page actually loading, there’s a lookup happening: “this human-readable name — which server’s IP address does it actually correspond to?” DNS (the Domain Name System) is the distributed database that answers that question, organizing information per domain into units called records. Records come in different types, and each type answers a different kind of question. Here we’ll focus on the three that come up most often.

A records — a hostname pointing straight at an IPv4 address

The A record is the most basic type: it maps a hostname (say, wpmm.jp) directly to a specific IPv4 address. It’s a simple map — “traffic to this domain should go to this IP.” When you stand up a new web server and want to serve it from a custom domain, an A record is typically the first thing you configure.

CNAME records — a hostname pointing at another hostname

A CNAME (Canonical Name) record treats one hostname as an alias for another. Instead of pointing directly at an IP address, it says “the real content for this name lives over there, at that other hostname” — an indirect reference, unlike the direct one an A record gives you. CNAME comes with a few constraints worth knowing. The most important: a name that has a CNAME record can’t also carry other record types (like MX or TXT) at the same time, because a CNAME forwards every query for that name wholesale. It also can’t be placed at a zone apex (the bare domain itself, like wpmm.jp with no subdomain) — an A record is the usual choice there instead.

TXT records — arbitrary text attached to a name

A TXT record attaches an arbitrary text string to a domain, rather than an IP address or another hostname. It started out as a place for human-readable notes, but today it’s almost entirely consumed by machines. Two common uses: proving ownership of a domain to an external service (the service issues a random string, you add it as a TXT record, and that proves you control the DNS for that domain), and email authentication configuration.

Example 1: standing up a subdomain starts with an A record

When we set up our English blog at the subdomain en.wpmm.jp, the first step was creating that subdomain in the hosting panel and pointing it at a document root. Behind the scenes, that action adds an A record for the new hostname en.wpmm.jp (or configures the hosting provider’s authoritative DNS to resolve it implicitly) — and it takes some time for that change to reach DNS caches around the world, commonly called “propagation.” That delay has a very practical consequence: try to install WordPress on the new subdomain immediately after creating it, and a connection attempt from an environment still holding a stale cache entry can fail outright. Right after a DNS change, it’s worth confirming through a separate path — a dig lookup, or checking against a different resolver — that the change has actually propagated, before moving on to the next step. It saves time that would otherwise go into chasing a mysterious error.

Example 2: email deliverability comes down to a set of three TXT records

When we investigated why our confirmation emails weren’t reliably reaching Gmail and Outlook inboxes, the fix that actually mattered was adding a TXT record. Email authentication rests on three mechanisms — SPF, DKIM, and DMARC — and all three are published as TXT records. SPF lists which servers are allowed to send mail on behalf of a domain. DKIM attaches a cryptographic signature to a message so a recipient can verify it wasn’t tampered with in transit. DMARC declares a policy for what to do when SPF and/or DKIM checks fail, and where to send reports about those results. Our domain already had SPF and DKIM configured; DMARC was the one missing piece. Adding a TXT record at the hostname _dmarc.wpmm.jp:

v=DMARC1; p=none; rua=mailto:info@wpmm.jp

completed the set of three, and deliverability to major overseas mail providers improved. (p=none is the loosest possible policy — it means “don’t reject or quarantine mail that fails authentication, just send a summary report” — a deliberate way to observe before escalating to something stricter like p=reject.) We go into more detail on how SPF, DKIM, and DMARC divide the work in our earlier post on this exact fix, if you want the fuller picture.

Takeaway

An A record answers “what IP does this name point to.” A CNAME answers “what other name does this name point to.” A TXT record answers “what arbitrary text is attached to this name.” Each type is answering a genuinely different question. In practice, the part that trips people up isn’t the meaning of the record itself — it’s the time lag between making a change and that change actually taking effect anywhere it’s queried from. For anything involving multiple steps, like standing up a subdomain or wiring up email authentication, confirming that a DNS change has actually propagated before moving to the next step tends to be the faster path, not the slower one.