Your domain name is the easy part. It is the thing on your business card: yourbusiness.com.au. What most owners never see is the machinery that turns that name into a working website and working email. That machinery is DNS, and when it goes wrong, your site disappears, your email stops arriving, and nobody can tell you why.
In our work building and maintaining sites for small businesses, DNS is the most common cause of "the website is down" calls that have nothing to do with the website itself. The idea is simple once you have the right picture. This article gives you that picture, shows what the records look like, and ends with a five-minute exercise on your own domain.
DNS is the internet's address book
Computers do not find each other by name. They find each other by number, an IP address that looks like 192.0.2.172. People are good at remembering names and hopeless at remembering numbers, so the internet needs a translator between the two.
DNS, the Domain Name System, is that translator: it converts human-friendly domain names into the numeric IP addresses computers actually use. MDN describes it as a hierarchical, decentralised naming system. Think of it as the address book for the entire internet.
The half-second between typing your address and seeing your site
Here is what runs every time someone visits you.
- 1.The visitor types yourbusiness.com.au, and the browser checks its own memory first, because every DNS answer carries a use-by timer called a TTL (time to live) and saved answers are reused until it runs out.
- 2.If nothing is saved, the browser asks a DNS resolver, usually run by the visitor's internet provider, which checks its own cache.
- 3.If nobody has a fresh answer, the resolver finds the servers holding your domain's records and asks directly.
- 4.Those servers reply with your A record's value: the IP address of the server your website lives on.
- 5.The browser connects to that address, the server sends your homepage, and your site appears.
The visitor sees none of this; done right, DNS is invisible. But hold on to step one. Those caches and timers explain the most confusing behaviour in this article.
The four records that steer your site and your email
A domain does not have one setting. It has a small set of entries called DNS records, each doing a specific job. In your DNS provider's control panel they look close to this:
yourbusiness.com.au A 203.0.113.46
www.yourbusiness.com.au CNAME yourbusiness.com.au
yourbusiness.com.au MX 10 mail.yourmailprovider.com
yourbusiness.com.au TXT "v=spf1 include:_spf.google.com ~all"Four types cover almost everything a small business needs; the clearest plain-language definitions come from AWS.
- A record. Points your domain at your website's server by IP address. The first line says this name lives at 203.0.113.46. When you move hosts, this is usually the record that changes.
- CNAME record. Maps one name to another, like an alias. The second line is how www.yourbusiness.com.au points to the same place as yourbusiness.com.au without maintaining the address twice.
- MX record. Routes your email. The third line names the mail server that handles messages for your domain; the 10 is a priority, and lower numbers are tried first. Get this wrong and your site can be fine while your email silently fails.
- TXT record. Holds small pieces of text for verification and email security. The fourth line is an SPF rule, which tells receiving mail systems who may send email as your domain. TXT records are also how you prove to Google that you own the domain.
The takeaway for a non-technical owner: your website and your email are steered by different records. That is why "my site works but my email is broken" is a completely normal sentence: they are two separate lines in the same address book.
Why DNS decides uptime, email and trust
DNS is not a set-and-forget technicality. Three things you care about depend on it directly.
Uptime. If your records are wrong or your DNS provider has an outage, your site becomes unreachable even though the server behind it is fine. Reliable DNS is the first link in the chain that ends with a fast-loading page, which is why we treat it as part of the same job as page speed and mobile performance: both decide whether a customer ever sees your site.
Email deliverability. Your MX and TXT records get your email into inboxes rather than spam folders. A missing SPF record makes receiving systems more likely to treat your legitimate messages as suspicious, and email is where the money conversations happen.
Security. DNS is also where you anchor the padlock customers look for. Sites are served over HTTPS, which relies on an SSL/TLS certificate (the technology behind the padlock). Google advises protecting every site with HTTPS, even ones that handle nothing sensitive, because it stops outsiders tampering with or reading what passes between your site and your visitors. A CDN, a network that serves your site from servers near each visitor, is often wired in at the DNS layer too; it speeds the site up and absorbs certain attacks.
Registrar versus host: who to call when something breaks
A registrar is the company you rent your domain name from. A host is the company whose server stores your actual website. Even when one company sells you both, they remain separate services: the registrar controls the name, the host controls the site the name points to.
Naming the layer correctly saves real time:
| Symptom | Layer | Who to call first |
|---|---|---|
| Domain expiring or already lapsed | The name | Registrar |
| Site shows errors but the domain resolves | The server | Host |
| Site fine, email failing | MX and TXT records | Whoever manages your DNS |
While you are in the registrar's control panel, two free settings prevent the worst outcomes.
- Auto-renewal. If the registration runs out, your site and email go dark, and in the worst case someone else registers the name. Turn it on, keep the billing card current, and make sure the account's contact email is one you check, ideally not on the domain you might lose.
- Registrar lock. Also called a transfer lock, this stops anyone moving your domain to another company without your permission. AWS notes it as protection against unauthorised transfers, and you can switch it off when you genuinely want to move. Leave it on by default.
A saved change is not a live change
Now the misconception that causes the most self-inflicted damage. The wrong belief: you edit a DNS record, click save, and the internet now uses the new value. Check two minutes later, see no change, and the natural conclusion is that the edit failed, so you change more things. That is how a ten-minute migration becomes an afternoon of chaos.
What is actually happening is step one from earlier. Every DNS answer is cached, by browsers, by resolvers, by servers in between, and each cache serves the old answer until its TTL runs out. Your change is live at the source almost immediately; the world catches up as the timers expire. This period is called propagation, and it can run from minutes to a day or more.
Two lessons follow. Plan DNS changes, especially a host migration, for a quiet period, then wait rather than editing again. And if you know a change is coming, lower the record's TTL a day or two beforehand so the old answer expires quickly. The waiting is part of the design, not a fault.
Read your own records in five minutes
You can look up any domain right now with a free tool. DNSChecker.org reports your records from dozens of locations worldwide; Google's Admin Toolbox Dig gives a single quick view. Using DNSChecker:
- 1.Open dnschecker.org, type your domain, leave the record type on A, and search. You should see the same IP address everywhere: that is where your website lives. If locations disagree, a recent change is still propagating.
- 2.Switch the type to MX and search again. The value names who handles your email: Google Workspace users should see google.com in it, Microsoft 365 setups usually outlook.com.
- 3.Switch to TXT and look for a line starting with v=spf1. That is your SPF rule. If none appears, your email security needs attention: receiving systems cannot check which senders are genuine.
- 4.Write down what you found and who manages your DNS, so the who-to-call question has an answer before anything breaks.
The point is not to memorise values. Next time a developer or provider mentions your A record or MX record, you can open the same table they are looking at and follow along.
How we handle it
For most owners, DNS should be something you never have to think about, and that is the standard we build to. When we set up or migrate a site, we get the A, CNAME, MX and TXT records right the first time, confirm HTTPS is in force, lock the domain, and switch on auto-renewal, so the foundation is solid before anything is built on top of it.
That reliability is what lets the more valuable work hold together. The reporting and follow-up in our lead management build only run because the email and domain underneath them are properly configured and stay up. The address book is the unglamorous part. It is also the part everything else depends on, which is exactly why it is worth getting right.