Understanding DNS Records (A, CNAME, MX, TXT)

What DNS does and where records live

The Domain Name System translates names people can remember, such as example.com, into the data computers need: IP addresses, mail server names, security policies and more. The core specifications are RFC 1034 and RFC 1035, published in 1987, and the basic model has barely changed since.

DNS is a distributed, hierarchical database. At the top are the root servers, below them the servers for each top-level domain such as .com or .de, and below those the authoritative name servers for individual domains. When you register a domain, your registrar publishes NS records in the TLD zone that point to the name servers holding your zone. That zone is simply a collection of resource records, and those records are what this guide is about.

How a lookup travels

1. A browser asks the operating system, which asks a recursive resolver (often run by your ISP or a public service).
2. If the answer is not cached, the resolver asks a root server, which refers it to the TLD servers.
3. The TLD servers refer it to your domain's authoritative name servers.
4. The authoritative server returns the record, and the resolver caches it for the duration of its TTL.

Anatomy of a resource record

Every record has the same five parts, which you can see clearly in standard zone file syntax:

www.example.com.   3600   IN   A   192.0.2.10
name               TTL    class type data

• Name – the hostname the record belongs to. A trailing dot marks a fully qualified name; in zone files and many control panels @ stands for the zone apex (the bare domain).
• TTL – time to live in seconds, telling resolvers how long they may cache the answer.
• Class – almost always IN for internet.
• Type – A, AAAA, CNAME, MX, TXT and so on.
• Data – the value, whose format depends on the type.

The most common DNS record types

A and AAAA records: pointing names to servers

An A record holds one IPv4 address; an AAAA record holds one IPv6 address. A name may have several of each, and resolvers will return all of them, which gives a simple form of load distribution. If your hosting provider supports IPv6, publish both so that clients on IPv6-only or dual-stack networks connect directly.

@     3600  IN  A     192.0.2.10
@     3600  IN  AAAA  2001:db8::10
www   3600  IN  A     192.0.2.10

When you move to a new host, the A and AAAA records are what you change. Knowing which network an address belongs to helps when debugging; a lookup such as the TLDix hosting checker shows which provider operates a given IP.

CNAME records: aliases and their limits

A CNAME says that one name is an alias for another, canonical name. Resolvers follow the chain and return the target's records. CNAMEs are convenient for pointing subdomains at services you do not control, such as a hosted shop, a CDN or a status page, because the provider can change its IP addresses without you editing anything.

shop    3600  IN  CNAME  stores.provider.example.
status  3600  IN  CNAME  example.statuspage.example.

The rules you must not break

• A name with a CNAME cannot have any other record type (RFC 1034, clarified in RFC 2181). You cannot put a CNAME and an MX on the same name.
• Because the zone apex always has SOA and NS records, a standard CNAME cannot be used on the bare domain. Many DNS providers offer proprietary ALIAS, ANAME or CNAME-flattening features to work around this, and the newer HTTPS record type (RFC 9460) is another option.
• MX and NS records must point to a hostname that has A or AAAA records, not to a CNAME.
• Avoid long chains of CNAMEs; each hop adds lookup time and another point of failure.

MX records: routing email

MX records tell sending mail servers where to deliver messages for your domain. Each record has a preference number; lower numbers are tried first, and records with equal preference share the load.

@  3600  IN  MX  10 mx1.mailhost.example.
@  3600  IN  MX  20 mx2.mailhost.example.

If a domain has no MX record, senders fall back to its A or AAAA record, which is rarely what you want. For a domain that should never receive email, RFC 7505 defines a null MX: a single record with preference 0 and a target of a single dot.

TXT records: verification and email authentication

TXT records store arbitrary text, and over time they have become the place for policies and ownership proofs. Search engines, certificate authorities and SaaS platforms often ask you to add a TXT record containing a token to prove you control a domain. The three most important uses relate to email:

• SPF (RFC 7208) lists the servers allowed to send mail for your domain, for example v=spf1 include:_spf.mailhost.example -all. Publish only one SPF record per name.
• DKIM (RFC 6376) publishes a public key at a selector such as s1._domainkey, letting receivers verify message signatures.
• DMARC (RFC 7489) lives at _dmarc and tells receivers what to do when SPF and DKIM checks fail, for example v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com.

A single TXT string is limited to 255 characters, but a record can contain several strings that are concatenated, which is how long DKIM keys are stored.

NS, SOA and CAA: records that run the zone

NS records

NS records list the authoritative servers for a zone. They must match at two levels: in the parent TLD zone, set through your registrar, and inside your own zone. A mismatch causes inconsistent answers that are hard to diagnose. Listing at least two name servers on separate networks is standard practice.

The SOA record

@  IN  SOA  ns1.example.net. hostmaster.example.com. (
        2026100701 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; negative caching TTL

The serial number must increase whenever the zone changes so that secondary servers pick up the update; a date-based format like the one above is common. The last field controls how long resolvers cache a not-found answer (RFC 2308).

CAA records

CAA records state which certificate authorities may issue TLS certificates for your domain. Since 2017 publicly trusted CAs must check them before issuing. Adding 0 issue "letsencrypt.org" means only that CA may issue, which reduces the risk of mis-issued certificates.

TTL, propagation and checking your records

There is no global push in DNS: changes become visible as cached copies expire. If a record has a TTL of 86400, some resolvers may keep serving the old value for up to a day. A sensible routine before a planned migration is to lower the TTL to 300 seconds a day or two in advance, make the change, confirm it, and then raise the TTL again.

The dig tool is the most reliable way to see what is actually published:

dig example.com A
dig example.com MX +short
dig _dmarc.example.com TXT
dig @ns1.example.net example.com SOA
dig example.com NS +trace

Querying the authoritative server directly with @ shows the current value and bypasses any cache. The +trace option follows the delegation from the root, which is useful when you suspect a mismatch between your registrar and your DNS host.

Common mistakes and how to avoid them

• Letting the domain expire. Every record stops working the moment the domain is suspended. Track expiry dates; the TLDix domain lookup shows registration status and name servers, and the documentation describes renewal alerts.
• Forgetting the trailing dot in zone files, which turns mail.example.com into mail.example.com.example.com.
• Two SPF records on the same name, which makes SPF evaluation fail with a permanent error.
• CNAME conflicts at the apex or alongside MX and TXT records.
• Stale records pointing to deprovisioned cloud resources, which can enable subdomain takeover. Remove records when services are retired.

Once you understand the handful of record types above, almost every DNS task becomes a matter of choosing the right type, writing the value carefully and verifying the result with dig.