DNS Records Explained

Updated 26 September 2026 · 6 min read

DNS is how names like example.com become addresses computers can reach. You do not need to memorize every record type, but you do need to know which records point a website, which records deliver email, and why changing one without the other can take a shop offline. This guide covers nameservers, A, AAAA, CNAME (including why CNAME at the apex is a problem), MX, TXT, TTL, propagation, and moving hosts without breaking mail. Examples use example.com and documentation IPs from RFC 5737 such as 192.0.2.10.

Nameservers: who answers for the domain

A domain registrar holds the domain. Nameservers are the servers allowed to answer DNS questions for that domain. You set nameserver hostnames at the registrar (for example, a pair provided by your DNS host). After that, records you create live at that DNS host, not in a random file on the web server.

If you change nameservers, every record must exist at the new provider before you switch, or the name will have holes: website up, mail down, or the reverse. Copy the full set — A, AAAA, MX, TXT, CNAME, and any others you use — and compare, line by line.

WHOIS or the registrar panel shows the current nameservers. Your web host and your email host are often different companies. DNS can live with either, or with a third DNS host. Pick one place as the source of truth.

A and AAAA: the website’s address

An A record maps a name to an IPv4 address. An AAAA record maps a name to an IPv6 address. Browsers will use whichever the network supports.

example.com.        300  IN  A     192.0.2.10
www.example.com.    300  IN  A     192.0.2.10
example.com.        300  IN  AAAA  2001:db8::10

192.0.2.10 is a documentation address, not a public server you should copy. Your host will give you the real IPs. The apex (example.com with nothing in front) and www are separate names. Point both, or redirect one to the other with HTTP after DNS is correct. Redirects are a different topic; see 301 vs 302 redirects once the names resolve.

If you add HTTPS later, certificates still need these names to resolve to the machine that completes validation. That pairing is covered in HTTPS and SSL certificates.

CNAME, and why not at the apex

A CNAME is an alias: this name is the same as that other name. The other name is then looked up for A/AAAA (or further CNAMEs). Typical use: www as an alias to a host the platform controls.

www.example.com.  300  IN  CNAME  example.com.
blog.example.com. 300  IN  CNAME  hosting-example.net.

A CNAME cannot sit on the same name as any other record. The apex of the domain almost always has MX and TXT records for mail. If you put a CNAME on example.com itself, those mail records are not valid together with it in standard DNS. That is why “CNAME at the apex” breaks email or contradicts the protocol.

Some DNS hosts offer flattening or ALIAS/ANAME records that look like a CNAME at the apex but synthesize A/AAAA. Those are product features, not a reason to delete MX records. If your host requires an apex CNAME and you use email on the domain, ask them how MX is preserved before you click.

Never point a CNAME at an IP. It must point at a hostname.

MX: where mail should go

MX (mail exchanger) records name the servers that accept mail for the domain. Each has a priority number; lower numbers are tried first.

example.com.  300  IN  MX  10 mailhost1.example.net.
example.com.  300  IN  MX  20 mailhost2.example.net.

The MX target must be a hostname with A or AAAA records, not a CNAME if you can avoid it (many operators still warn against MX → CNAME). Changing the website host does not require changing MX. Mixing them up is the classic outage: you “moved the site” by copying a DNS template that pointed MX at a web host that does not accept your mail.

Before any cutover, send a test message to an address on the domain and confirm it arrives where you expect. Keep the old MX until the new mailboxes are proven, if you are also moving email.

TXT and friends

TXT records hold text. They are used for proving domain control, and for email authentication (SPF, and sometimes DKIM pieces; DKIM is often a CNAME or TXT on a selector name). A domain can have multiple TXT records. Do not merge unrelated strings into one TXT unless a standard says to (SPF must be a single SPF policy, which is a common trap).

example.com.  300  IN  TXT  "v=spf1 include:example.net -all"

Details of SPF, DKIM, and DMARC belong in email authentication with SPF, DKIM, and DMARC. Other TXT uses include site-verification tokens from search consoles. Leave those in place when you migrate DNS; copy them.

You may also see NS records inside the zone (delegating a subdomain) and CAA records (which certificate authorities may issue for the name). Do not delete records you do not recognize until you know what they do.

TTL and propagation

TTL (time to live) is how long a resolver may cache a record, in seconds. 300 is five minutes; 3600 is an hour; 86400 is a day. Lower TTL before a planned change so old answers expire faster. Raise it later if you want less DNS traffic and you rarely change IPs.

“Propagation” is mostly cache expiry plus people looking at different resolvers. There is no single worldwide switch. You can see an old IP at a cafe and the new IP on your phone. Tools that “check global DNS” are sampling resolvers, not a guarantee.

After you change a record, wait at least the old TTL before you declare victory or delete the old server. Lowering TTL at the same moment as the IP change does not help visitors who already cached the previous TTL.

Changing web hosts without breaking email

A careful website move:

Export the current zone (screenshot plus a text copy of every record).
Lower TTL on A/AAAA a day in advance if they were high.
Build the site on the new host using a hosts-file test or a temporary hostname, not by switching public DNS yet.
When the new site is ready, change only A/AAAA (and www CNAME if it should follow). Leave MX and mail-related TXT/CNAME selector records untouched.
Watch mail for a few hours. Keep the old web host running until the old TTL has passed and you have checked the site on a network that is not yours.

If you must change nameservers as part of the move, recreate MX and TXT first on the new DNS, verify with a lookup, then switch nameservers at the registrar. Website IPs can wait until that mail picture is identical.

If HTTPS breaks after an IP change, the certificate may still be on the old machine. Issue or copy certificates on the new host before or immediately after the DNS cut. Mixed content and redirects come after the name points at the right place.

Checklist

Know which company holds nameservers, and treat that zone as the source of truth.
A/AAAA for the website; MX for mail; never assume a web-host template should replace MX.
No CNAME at the apex if you have other apex records; do not CNAME to an IP.
Copy every TXT and mail selector when you migrate DNS.
Lower TTL before planned A/AAAA changes; wait out the old TTL before decommissioning the previous server.

Print or save the current zone before the next hosting “easy migrate” button. That file is how you undo a broken afternoon.

Related guides

General technical information; test changes carefully and keep backups of your settings.