DNS is the phone book of the internet. When someone types your domain, DNS is what tells their browser where to look. It is also the thing that silently breaks sites, delays migrations, and causes email deliverability problems. Here is what you actually need to know.

The DNS record types that matter for websites

A record

Maps a domain name to an IPv4 address.

example.com.  300  IN  A  203.0.113.42

Your web server has an IP address. The A record is how the domain finds it. Most hosting providers give you one.

AAAA record

Same as A, but for IPv6 addresses. Still not critical for most sites, but Google uses it as a ranking signal.

CNAME record

Maps one domain name to another. Used for subdomains pointing to a canonical destination.

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

A CNAME cannot coexist with other records at the same name (no MX, TXT, or A alongside it at the root).

MX record

Specifies which mail servers accept email for the domain.

example.com.  300  IN  MX  10 mail.example.com.
example.com.  300  IN  MX  20 mail-backup.example.com.

The priority number (10, 20) determines which server is tried first. Lower = higher priority.

TXT record

Arbitrary text data. Used for email authentication (SPF, DKIM, DMARC) and domain ownership verification.

CAA record

Specifies which certificate authorities are allowed to issue SSL certificates for the domain. Good security practice.

TTL — Time To Live

Every DNS record has a TTL value in seconds. It tells resolvers how long to cache the record before asking again.

example.com.  300  IN  A  203.0.113.42

300 seconds = 5 minutes. Before a migration, lower your TTLs to 60 seconds at least 24 hours in advance so the change propagates quickly.

Many managed DNS services (Cloudflare, Route 53) cache aggressively. Some default to 300, others to 3600 or higher. Check before migration windows.

How DNS propagation actually works

DNS does not “propagate” in the way most people describe it. There is no global broadcast. Instead:

  1. You update a record at your DNS provider
  2. Your DNS provider’s nameservers start serving the new value
  3. Recursive resolvers (your ISP, Google 8.8.8.8, Cloudflare 1.1.1.1) cache the old value until their cached TTL expires
  4. Over time, all resolvers serve the new value

“Propagation” delays come from cached TTLs. If your TTL was 86400 (24 hours), it can take that long for all resolvers to pick up a change.

Common DNS mistakes

1. CNAME at the root/apex

example.com cannot have a CNAME. Only www.example.com can. Use an A record or ALIAS record at the apex, or use your DNS provider’s synthetic records.

2. Multiple A records pointing to different IPs

This is fine for load balancing but browsers may try them in any order. If one IP is broken, some users get errors.

3. Conflicting MX and CNAME

If example.com has a CNAME, it cannot also have MX records. This is a common migration mistake when someone CNAMEs their root domain to a SaaS platform.

4. TTL set too high before migrations

Set TTLs to 300 or lower at least 24 hours before changing any DNS. Failing to do this is the most common cause of extended downtime during DNS cuts.

5. Not verifying TTLs are actually what you set

Some DNS providers override your TTL. Cloudflare’s minimum TTL is 300 regardless of what you set. Check with dig:

dig A example.com +short
dig A example.com +noall +answer

The records to check before any migration

Before moving hosting, document the current state:

dig NS example.com
dig A example.com
dig AAAA example.com
dig MX example.com
dig TXT example.com

Save these outputs. Reversing a migration is much harder without them.

DNS and email deliverability

If you are migrating and email breaks, DNS is usually the cause. Specifically:

  • SPF record — lists which mail servers are allowed to send email for your domain. If your new host sends email and the SPF record does not include their server, it fails.
  • DKIM — public key encryption for email. The TXT record must match the private key on your mail server.
  • DMARC — policy that tells receivers what to do with email that fails SPF/DKIM. Start with v=DMARC1; p=none and tighten from there.

Run a free check at mxtoolbox.com or dmarcanalyzer.com before and after any migration.