DNS Records Explained: The Ones That Matter and the Ones That Break Things

Most outages that get reported as "the website is down" are DNS. The server is fine, the site is fine, and something in a text record is pointing at the wrong place — or is still cached pointing at the old one.

DNS is also the least visible layer of a website. Nobody looks at it until it breaks, and by then the change that broke it was made weeks ago by someone who has moved on.

Here is what each record type does and where each one goes wrong.

A and AAAA — where the site lives

A maps a hostname to an IPv4 address. AAAA maps it to IPv6.

example.com.      A      203.0.113.10
example.com.      AAAA   2001:db8::1
www.example.com.  A      203.0.113.10

If these are wrong or missing, nothing else on this page matters.

The mistake: publishing an A record for example.com but not for www.example.com, or vice versa. Half your visitors type it the other way and get nothing. You never notice because you always type it the same way.

On IPv6: in several markets a large share of mobile traffic is IPv6-only and reaches IPv4-only sites through carrier-grade translation, which adds latency to every connection. If your host supports IPv6, adding AAAA is free and removes that hop.

MX — where email arrives

example.com.  MX  10 mx1.provider.com.
example.com.  MX  20 mx2.provider.com.

Lists the servers that accept mail for your domain. Lower priority number wins; higher numbers are fallbacks.

Two things people confuse:

MX controls incoming mail only. If your outgoing mail is landing in spam, MX is not the problem — SPF, DKIM and DMARC are, and those live in TXT records.

An MX record must point to a hostname, never an IP address. MX 10 203.0.113.5 is invalid, and some mail servers will reject mail for a domain configured that way.

NS — who is authoritative

example.com.  NS  ns1.provider.com.
example.com.  NS  ns2.provider.com.

The nameservers that answer for your domain. These must match what is configured at your registrar — the NS records in the zone and the delegation at the registrar are two different things, and they can disagree.

The migration failure: you move hosting, update the DNS records at the new provider, and the site works for you but not for others. The cause is almost always that the registrar delegation still points at the old nameservers, so half the internet is asking the old provider, which still has the old answers.

Always have at least two nameservers. One is a single point of failure for your entire domain, including email.

TXT — the catch-all

Arbitrary text records, now used for a growing list of purposes:

• SPF — which servers may send email as you: v=spf1 include:_spf.google.com ~all
• DMARC — the enforcement policy, at _dmarc.example.com
• DKIM — the public key, at selector._domainkey.example.com
• Domain verification — Google Search Console, Microsoft 365, Atlassian, Zoom, and a dozen others

Two rules that catch people:

Only one SPF record per domain. Two TXT records starting v=spf1 is a permanent error, and the result is that neither works. This happens when a second vendor is onboarded and adds their own record rather than editing the existing one. Merge them.

TXT records accumulate. Most established domains carry verification records for services they stopped using years ago. They are harmless but they are clutter, and clutter is where the second SPF record hides. Audit them annually.

CAA — who may issue certificates for you

The most under-used record type on this list.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef "mailto:security@example.com"

CAA declares which certificate authorities are permitted to issue certificates for your domain. Without it, any public CA may issue one. With it, only the ones you name.

CAs are required to check this record before issuing. It is a genuine control against mis-issuance, it takes two minutes, and almost nobody sets it.

Two things to get right: include every CA you actually use — including any your CDN or hosting provider issues on your behalf, which is easy to forget — and use issuewild ";" to forbid wildcards if you do not use them.

SOA — zone metadata

One per zone, mostly automatic. The field worth knowing is the serial number: it increments each time the zone is edited. During a migration, if the serial has not changed, your edit did not publish. That single check resolves a lot of "I already changed it" confusion.

TTL: the thing that makes migrations painful

Every record carries a Time To Live — how many seconds resolvers may cache it.

A record with a 24-hour TTL can take a full day to update worldwide. There is no way to speed that up after the fact. Once a resolver has cached the old answer, it will serve it until the TTL expires, and no amount of pleading changes that.

The technique that makes this a non-issue:

1. 48 hours before the migration, lower the TTL on the records you will change to 300 seconds.
2. Wait for the old TTL to fully expire, so every resolver has picked up the short one.
3. Make the change. It now propagates in five minutes.
4. A day after, raise the TTL back to 3600 or higher.

Step 4 matters — a permanently low TTL means more lookups and marginally slower first connections for every visitor.

This is the single most useful DNS practice, and it has to be done in advance. It cannot be applied retroactively, which is exactly when people wish they had.

Why different tools show different answers

Because they are asking different resolvers, and those resolvers have different cached copies depending on when they last asked.

Right after a change this is expected and resolves as TTLs expire. If it persists beyond the TTL, something is genuinely publishing inconsistent answers — usually two sets of nameservers still active after an incomplete migration.

You can inspect every record for a domain, with its TTL, using our free DNS lookup tool. It queries directly from your browser, so it also shows you what a resolver near you currently believes.

A migration checklist

1. Export the complete current zone before touching anything.
2. Lower TTLs to 300s, 48 hours ahead.
3. Build the full zone at the new provider before switching delegation.
4. Switch nameservers at the registrar.
5. Verify A, AAAA, MX, TXT and CAA all resolve at the new provider.
6. Send a test email in both directions.
7. Keep the old zone alive for a week — resolvers with long-cached NS records will still be asking it.
8. Raise TTLs back once traffic is stable.

Step 7 is the one people skip, and it is the reason a migration looks fine on day one and produces bounced email on day three.