Most people only think about DNS when something has gone wrong. The website loads for you but not for your client. Email stopped arriving the day you switched providers. Google Search Console keeps saying it cannot verify your domain. You open your DNS settings and stare at a table of records with names like A, CNAME and TXT, and it feels like a language nobody taught you.
It is simpler than it looks. DNS is the internet's address book, and each record type answers one specific question. Once you know which question each record answers, most DNS problems become obvious.
What DNS actually does
Computers find each other by IP address, a number like 93.184.215.14. People prefer names like example.com. DNS, the Domain Name System, translates one into the other.
When someone types your domain into a browser, their device asks a DNS resolver, usually run by their internet provider, Google or Cloudflare. The resolver finds the name servers responsible for your domain and asks them for the right record. The answer comes back, the browser connects, and the page loads. It usually takes a few milliseconds.
The important part: your DNS records live on your domain's name servers, and whoever runs those name servers is where changes must be made. That single fact solves a surprising number of problems.
The records you will actually use
| Record | Question it answers | Typical example |
|---|---|---|
| A | What IPv4 address is this name at? | example.com → 93.184.215.14 |
| AAAA | What IPv6 address is it at? | example.com → 2606:2800:… |
| CNAME | Which other name is this an alias of? | www.example.com → example.com |
| MX | Which servers receive this domain's email? | 10 mail.provider.com |
| TXT | What text notes are published for it? | SPF, DMARC, verification codes |
| NS | Which name servers are responsible for it? | ns1.host.com |
| CAA | Which certificate authorities may issue SSL for it? | 0 issue "letsencrypt.org" |
A and AAAA: where the website lives
An A record points a name at an IPv4 address; AAAA does the same for IPv6. When you move hosting, these are usually the records you change.
CNAME: an alias, not an address
A CNAME says "this name is the same as that name", and the address is looked up from the target. They are ideal for subdomains that point at services, such as shop.example.com pointing at an e-commerce platform. One rule catches people out: a name with a CNAME cannot have any other records. That is why the root domain (example.com itself) normally uses A records, not a CNAME.
MX: where email goes
MX records list the servers that receive email for your domain, each with a priority number. Lower numbers are tried first. If email stops arriving after a change, missing or wrong MX records are the first thing to check.
TXT: proof and policy
TXT records hold text that other services read. The most important ones are about email trust:
- SPF starts with
v=spf1and lists which servers may send email for your domain. A domain should have exactly one SPF record. - DKIM publishes a public key at
selector._domainkey.yourdomain.comso receivers can verify your email signatures. Your email provider tells you the selector name. - DMARC lives at
_dmarc.yourdomain.comand tells receivers what to do with email that fails SPF and DKIM checks.
TXT records are also how you prove ownership to services like Google Search Console and Microsoft 365.
TTL and "propagation": why changes seem slow
Every record has a TTL, time to live, measured in seconds. It tells resolvers how long they may cache the answer. A TTL of 3600 means a resolver that looked up your record may keep using the old value for up to an hour after you change it.
This is what people call DNS propagation. Nothing is slowly travelling around the world; caches are simply expiring at different times. Most changes are visible within minutes to a few hours. Changing name servers can take longer, up to 48 hours, because those records are cached at a higher level.
A practical trick: a day before a planned move, lower the TTL on the records you will change to something short, like 300 seconds. When you make the switch, caches expire within five minutes. Raise it again once everything works.
Troubleshooting: common problems and what to check
The website works for me but not for others (or the other way round)
One of you is seeing a cached, older answer. Look up the A record with the DNS Lookup tool, which asks Google and Cloudflare's public resolvers directly. If it shows the new address, the change is live and some caches simply have not expired. To see what resolvers in different countries currently get, run a DNS check from more than 30 locations with the Ping & Uptime Checker; our guide on whether your website is down or it is just you explains how to read the results.
Email stopped arriving
Look up MX. If it is empty or still points at the old provider, fix it at your DNS host. Then check the SPF TXT record: after switching providers, it often still lists only the old one, so new outgoing mail lands in spam.
My DNS changes do nothing at all
You are probably editing records in the wrong place. Look up the NS records, or check the name servers in the domain's WHOIS record. If they point at Cloudflare, changes made at your registrar are ignored, and vice versa. Our guide to reading a WHOIS record shows exactly where name servers appear.
Domain verification keeps failing
Look up TXT for the exact name the service asked for. Common mistakes are adding the record on www instead of the root domain, or pasting the value with extra quotes or spaces.
SSL certificate will not renew
Look up CAA. If the domain has CAA records and none of them allows your certificate provider, renewal fails. Either remove the CAA records or add one for your provider.
"Domain does not exist"
The lookup returned NXDOMAIN. The domain may be misspelled, not registered, or expired. Check its registration and expiry date with the WHOIS Lookup.
A calm checklist before any DNS change
- Note down the current records, or take a screenshot, so you can roll back.
- Confirm which name servers are in charge, and edit records there.
- Lower the TTL a day ahead if you are moving something important.
- Make one change at a time and look it up straight away.
- Test email separately from the website; they depend on different records.
- After a hosting move, also check redirects and HTTPS with the Redirect Checker.
If you are pointing a domain at a server you run yourself, for example an app deployed with Docker, make sure the stack itself is healthy before blaming DNS; our guide to common Docker Compose errors covers the mistakes that most often stop a deployment.
DNS stops being scary once you can see it
Most DNS anxiety comes from making changes blind and waiting to see what happens. Being able to look up exactly what the public internet sees, record by record, turns it into ordinary troubleshooting.
Next time something stops working after a change, start with the question the broken thing depends on: where is the website (A), where does email go (MX), what does this domain promise (TXT), and who is in charge (NS). Then look it up with the DNS Lookup tool and compare it with what you expected. The answer is usually right there in the table.
