DNS Records Explained: A, CNAME, MX, TXT, NS — What They All Mean

Someone asks you to "just set up the email" for a new domain. You go into the DNS panel, and you're looking at a table of records — some A records, an SOA, a few MX records — and you're not entirely sure which ones to touch. Or you've just pointed a domain to a new server and email has stopped working, and you need to figure out why. DNS record types are not complicated, but the terminology creates more confusion than the concepts warrant.

What DNS does

DNS (Domain Name System) translates human-readable domain names into information computers need — primarily IP addresses, but also routing instructions for email, domain verification data, and more. When you type a domain name into a browser, your computer queries a chain of DNS servers to look up what that name maps to.

A zone file (the set of records for a domain) contains multiple record types, each serving a specific purpose. Here are the ones you'll encounter in real work.

A Record — Maps domain to IPv4 address

An A record maps a hostname to an IPv4 address. This is the fundamental record that lets browsers find a server.

example.com.     300  IN  A  203.0.113.10
www.example.com. 300  IN  A  203.0.113.10

The numbers before IN are TTL (time to live) in seconds — how long resolvers should cache this record before checking again. A TTL of 300 means the record will be re-queried every 5 minutes. Lower TTL = faster propagation of changes; higher TTL = less DNS query load.

Multiple A records for the same hostname provide basic round-robin load balancing — different clients will receive different IP addresses and connect to different servers.

AAAA Record — Maps domain to IPv6 address

The IPv6 equivalent of an A record. The four A's stand for the four times the address length (IPv6 is 128 bits, IPv4 is 32 bits). Most modern servers should have both an A and AAAA record.

example.com. 300 IN AAAA 2001:db8::1

CNAME Record — Canonical name alias

A CNAME record maps one hostname to another hostname, rather than to an IP address. The resolver follows the CNAME and then resolves the target name.

www.example.com. 300 IN CNAME example.com.

This is commonly used to point subdomains to a CDN, SaaS provider, or load balancer that handles its own IP addressing:

blog.example.com. 300 IN CNAME mycompany.ghost.io.

Important limitation: you cannot use a CNAME at the zone apex (the bare domain itself — example.com, not www.example.com). The RFC prohibits CNAME at a name that also has other records (like SOA or MX). This is why CDN providers offer "CNAME flattening" or "ALIAS" records as proprietary solutions for apex domains.

MX Record — Mail exchange routing

MX records tell sending mail servers where to deliver email for a domain. They point to a hostname (not an IP address), and each record has a priority value — lower numbers are higher priority.

example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.

The sending server tries mail1 first; if it's unreachable, it tries mail2. For Google Workspace and Microsoft 365, you'll replace these with the provider's MX hosts (which look like aspmx.l.google.com or example-com.mail.protection.outlook.com).

If email isn't working after a DNS change, check the MX records first. Also verify that the target hostnames in MX records have their own A records — MX records must point to a hostname, and that hostname must resolve.

TXT Record — Free-form text, primarily for verification

TXT records store arbitrary text. In practice they're used for three main things:

SPF (Sender Policy Framework) — Specifies which servers are authorized to send email from your domain. A typical SPF record looks like:

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"

DKIM (DomainKeys Identified Mail) — A public key that allows receiving servers to verify that email was signed by your mail system:

google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."

Domain ownership verification — Google Search Console, Microsoft 365, and other services ask you to add a TXT record with a specific string to prove you control the domain.

You can have multiple TXT records at the same name, but only one SPF record (additional SPF records will cause verification failures).

NS Record — Nameserver delegation

NS records specify which servers are authoritative for a domain's DNS. When you register a domain, you tell the registrar which nameservers to use; they publish NS records in the parent zone.

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

NS records have high TTLs (24 hours or more) because changing nameservers is infrequent and DNS caches hold them for a long time. If you're migrating DNS to a new provider, expect up to 48 hours for the change to propagate globally, even with a low TTL. To check who currently controls a domain's nameservers and when the registration expires, use a WHOIS lookup.

TTL and propagation

DNS propagation is often misunderstood. When you change a record, the change applies immediately on the authoritative nameserver. But resolvers around the world cache the old value for the duration of its TTL. There is no global "push" of DNS changes — resolvers just stop using their cached value after the TTL expires and re-query.

Before making a critical DNS change (pointing a domain to a new server, changing MX records), temporarily lower the TTL to 60 or 300 seconds, wait for that TTL to expire, make the change, then raise the TTL back to normal once you've confirmed everything works. This minimizes the "stuck on old value" window.

Diagnosing DNS problems

The DNS Lookup tool lets you query any record type for any domain in seconds — useful for checking whether a change has propagated, verifying MX records before testing email, or inspecting TXT records for SPF/DKIM configuration.