DNS is the internet’s phone book. Your domain name is the entry. The records inside it tell the world where to find your website, where to deliver your email, and who is allowed to send mail on your behalf. Change a record and the world eventually looks it up again.
That is the whole idea. Everything else is detail, and the detail is where people get nervous. Below is what each record does, what TTL actually means, and why a DNS change made in the right order is one of the least dramatic things that happens to a website.
Why DNS exists at all
Computers do not know what “yourbusiness.com” means. They know numbers — addresses like 203.0.113.10 that identify a specific server. DNS is the translation layer in between. Someone types your domain, their computer asks a DNS server “where does this go,” and gets an address back. Then the browser goes and fetches your site.
You could, technically, hand out the numeric address instead. Nobody would remember it, and you could never change servers without reprinting everything you own. Names are the point. DNS is what makes names work.
The records, one plain sentence each
A domain’s DNS is a short list of records. Each one has a purpose. There are dozens of types in existence; you will realistically only ever care about four.
- A record — points your domain at the numeric address of the server that holds your website.
- CNAME record — points one name at another name, so “www.yourbusiness.com” can simply say “whatever yourbusiness.com does, do that.”
- MX record — tells the world which server should receive your email, which is a completely separate question from where your website lives.
- TXT record — holds plain text used for verification and email authentication, so services can confirm you own the domain and mail providers can confirm your messages are genuinely yours.
That is most of what a small business domain contains. A few of those, sometimes a CNAME or two for a mailing list or an analytics tool, and nothing else.
TTL: how long the world is allowed to remember the old answer
Every record carries a TTL — time to live. It is a number in seconds, and it means exactly one thing: how long a computer that looked up your record is allowed to keep using that answer before asking again.
A TTL of 86400 is one day. If you change that record, some computers will keep using the old answer for up to a day, because you told them they could. A TTL of 300 is five minutes. Change the record and the world catches up within five minutes.
This is the single most useful thing to understand about DNS, because it explains the thing everyone finds mysterious.
“Propagation” is not a mystery, it is a countdown
People talk about DNS propagation as though a change is slowly seeping across the world, arriving in Denver on Tuesday and Lisbon on Thursday. It does not work like that. Nothing is being pushed anywhere.
What is actually happening: your new record is live immediately at the source. Everyone else is still holding a cached copy of the old answer until their TTL expires. That is why your colleague sees the new site and you see the old one. You are not looking at different internets. You are looking at answers with different expiry times.
Which means the fear is misplaced. The scary version is when someone changes a record with a 24-hour TTL, discovers a problem, fixes it, and then has to wait out the cache twice. The uneventful version is when the TTL was lowered first.
The sequence that makes DNS boring
A DNS cutover done properly has three steps, in this order, and skipping any of them is where the horror stories come from.
Lower the TTL first, and wait. Drop the TTL on the records you plan to change — down to five minutes or so — and then wait out the old TTL before touching anything else. If the record was set to a day, you wait a day. This is the step everyone wants to skip. Lowering the TTL does not take effect until the old TTL has expired, because the world is still holding the old instruction that said “keep this for 24 hours.”
Verify the destination before you point at it. The new server should be fully built, tested, and serving the correct site before a single public record moves. We check the new copy directly — content, forms, SSL, checkout if there is one — while the live site is still happily serving visitors from the old address. Nothing is at risk yet, because nothing has been pointed anywhere.
Then cut over. Change the record. With a five-minute TTL, the world follows within minutes. If something is wrong, you change it back and the world follows within minutes again. That reversibility is the entire reason for step one.
Done in that order, a cutover is dull. Done out of order, it is a day of guessing. This is the same discipline that keeps rankings intact during a move — we wrote about that side of it in migrating without breaking SEO.
Why email is the thing that actually breaks
Here is the failure that comes up more than any other, and it has nothing to do with websites.
Someone moves hosts. They update the A record so the website points at the new server. The site loads. Everyone declares victory. But the MX record still points at the old provider, or worse, the new host’s setup helpfully replaced the MX records with its own mail service that nobody has configured. Email either goes to a mailbox no one is watching, or bounces.
Website and email are separate systems that happen to share a domain name. Your site can live on one company’s server while your mail lives on Google Workspace, Microsoft 365, or anywhere else entirely. Moving one does not require moving the other — but a careless move can silently break the one you were not thinking about.
The other half of this is the TXT records. SPF, DKIM, and DMARC are the text records that vouch for your mail. Lose them in a move and your email does not stop — it just quietly starts landing in spam folders, which is worse, because nobody tells you. You find out three weeks later when a customer says they never got the invoice.
So the rule we work to: before anything moves, write down every record the domain currently has. Every one. Then confirm afterwards that the ones you did not intend to change are still there, character for character.
What is worth your attention, and what is not
Some honest triage, because not all of this deserves your time.
Worth caring about: knowing where your domain is registered and being able to log in. That is the one thing nobody else can do for you. Registrar access is the master key to everything above, and losing it is a genuinely painful problem that takes days of identity verification to fix. Keep those credentials somewhere you will find them in two years.
Not worth caring about: the alphabet soup. You do not need to know what a SOA record is, or the difference between an authoritative and a recursive resolver, or why some providers call a root record an ALIAS or ANAME. That is our job. Understanding TTL and knowing that MX is email is genuinely enough for a business owner.
Also not worth caring about: the online “DNS propagation checkers” that show a world map with red and green pins. They are mostly anxiety generators. Red pins usually just mean that particular server has not hit its TTL expiry yet. It is a countdown, not a fault.
We handle this part for you
DNS is where a lot of migrations go wrong, which is why our migrations are white-glove and free. We build the new copy, test it, lower the TTLs, wait the required time, verify the site loads correctly, and only then move the record. We copy MX and TXT records across untouched unless you have asked us to change them, and we confirm mail flows afterwards rather than assuming.
You do not do the sequencing. You do not sit refreshing a map of pins. You get an email saying when the cutover is scheduled and an email saying it is done. If something needs a decision from you, we ask first. That is the shape of the whole service — more on that in calmer website operations.
If you are unsure what your current records say, or you have inherited a domain from a developer who has vanished, send us an email. We will look and tell you plainly what is there.
Frequently asked questions
How long does a DNS change actually take?
As long as the old TTL says it can. If your records were set to 24 hours, expect up to 24 hours for everyone to catch up. If the TTL was lowered to five minutes a day beforehand, the change lands within minutes. The waiting is not the change itself — it is other people’s caches expiring.
Will my email stop working when I move hosting?
It should not, and it will not if the MX and TXT records are carried across unchanged. Email delivery is governed by different records than your website, so moving a site does not move your mail. Problems happen when someone assumes the new host should handle mail too, and overwrites records that were working fine.
Do I need to move my domain registration to move my hosting?
No. Your registrar and your host can be completely different companies, and often should stay that way. All that needs to change is where a couple of records point. We work with whatever registrar you already use rather than asking you to transfer the domain, which keeps one less thing in motion during a move.
