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’s the whole idea. Everything else is detail, and the detail is where people get nervous. Below is what each record does, what TTL 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. DNS is what lets people use a name instead.
The records, one plain sentence each
A domain’s DNS is a short list of records, each with its own job. There are dozens of record types, but you’ll only ever need to 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 came from you.
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’s a number in seconds, and it means 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 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 doesn’t work like that, and nothing is being pushed anywhere.
Your new record is live immediately at the source. Everyone else keeps using a cached copy of the old answer until their TTL expires, so your colleague sees the new site while you still see the old one. You’re on the same internet, holding answers that expire at different times.
So 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 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. The same discipline keeps rankings intact during a move, and we wrote about that side of it in migrating without breaking SEO.
Why email is usually what breaks
The failure that comes up more than any other has nothing to do with the website.
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 doesn’t require moving the other, but a careless move can silently break the one you weren’t 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 doesn’t stop. It starts landing in spam folders instead, 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, then confirm afterwards that the ones you didn’t 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 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’s our job. Understanding TTL and knowing that MX is email is 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 mostly generate anxiety. A red pin usually means that particular server hasn’t reached its TTL expiry yet, not that anything is wrong.
We handle this part for you
DNS is where a lot of migrations go wrong, so we handle migrations ourselves, for 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 don’t have to handle the sequencing or sit refreshing a map of pins. You get an email saying when the cutover is scheduled and another saying it’s done, and if something needs a decision from you, we ask first. The rest of the service works the same way, which we cover in why better hosting means fewer website emergencies.
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. What you’re waiting on 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.
