Your domain name is the easy part to understand. It is the thing you put on a business card: yourbusiness.com.au. What most owners never see is the machinery that turns that name into a working website and a working email address. 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 single most common cause of "the website is down" calls that have nothing to do with the website itself. The good news is that the idea is simple once you have the right picture for it. This article gives you that picture, walks through the handful of records that matter, and explains how to protect the domain your whole online presence sits on.
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 we need something to translate between the two.
That translator is DNS, the Domain Name System. MDN describes it as a hierarchical, decentralised naming system whose main job is translating human-friendly domain names into the numeric IP addresses computers actually use. Think of it as the address book for the entire internet. You look up a name you know, and it gives you back the location you need.
Here is what happens in the half-second after someone types your address. Their browser asks the DNS system, "what is the number for yourbusiness.com.au?" DNS answers with the IP address of the server your site lives on. The browser connects to that server, and your homepage loads. The visitor sees none of this. They just see your site appear. When DNS is set up correctly, that is exactly how it should feel: invisible.
The Records That Make It Work
A domain does not have one setting. It has a small set of entries called DNS records, each doing a specific job. You will meet four of them. The clearest plain-language definitions come from AWS, and they are worth knowing by name because these are the ones you will be asked about.
- A record. This points your domain at your website's server using its IP address. It is the core "your name lives here" instruction. When you move to a new host, this is usually the record that changes.
- CNAME record. This maps one name to another name, like an alias. It is how "www.yourbusiness.com.au" can point to the same place as "yourbusiness.com.au" without you maintaining the address in two spots.
- MX record. This routes your email. It tells the world which mail servers handle messages for your domain, and in what order to try them. Get this wrong and your website can be perfectly fine while your email silently fails.
- TXT record. This holds small pieces of text used for verification and email security. It is how you prove to Google that you own the domain, and how email systems (through standards like SPF) check that a message claiming to be from you is genuine.
The takeaway for a non-technical owner is this: 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 instructions 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 DNS records are wrong or your DNS provider has an outage, your site becomes unreachable even though the server behind it is running fine. The visitor just sees an error. 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 are what get your email into inboxes rather than spam folders. Missing or misconfigured verification records are a common reason a legitimate business email can land in junk. For most small businesses, email is where the money conversations happen, so this is not a side issue.
Security. DNS is also where you anchor the padlock customers look for. Sites are served securely over HTTPS, which relies on a SSL/TLS certificate (the technology behind the padlock in the address bar). Google advises protecting every site with HTTPS, even ones that do not handle sensitive data, because it stops outsiders from tampering with or quietly reading what passes between your site and your visitors. A CDN, a content delivery network that serves your site from servers close to each visitor, is often wired in at the DNS layer too, and it both speeds the site up and absorbs certain attacks.
Registrar Versus Host: Two Different Companies
This is the distinction that confuses owners most, and it matters when something breaks.
A registrar is the company you rent your domain name from, such as the firm where you bought yourbusiness.com.au. A host is the company whose server stores your actual website. They are often two different businesses, and 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.
Knowing which is which saves real time. If your domain is about to expire, that is a registrar problem. If your site is throwing errors but the domain is fine, that is usually a host problem. When you can name the layer, you can call the right company first instead of being bounced between them.
Protecting the Domain Everything Sits On
Your domain is the foundation of your online identity, so it is worth a few minutes of care.
Stop it expiring. A lapsed domain is the most avoidable disaster in this article. If the registration runs out, your site and email go dark, and in the worst case someone else can register the name. Turn on auto-renewal and keep the billing card current. Make sure the contact email on the account is one you actually check, and ideally not an address on the same domain you might lose access to.
Turn on registrar lock. A registrar lock (also called a transfer lock) stops anyone from moving your domain to another company without your permission. AWS notes it as protection against unauthorised transfers, and that you can simply switch it off when you genuinely want to move. It is a free setting that blocks one of the nastier forms of domain theft, so leave it on by default.
The Pitfall Nobody Warns You About: Propagation
When you change a DNS record, the change is not instant everywhere. Computers around the world keep cached copies of the old answer for a while, so for a stretch of time some visitors see the new version and some still see the old one. This in-between period is called propagation, and it can run from minutes to a day or more.
This catches people out constantly. You update a record, check your site, see no change, and assume the update failed. Usually it just has not reached you yet. The practical lesson is to plan DNS changes (especially a host migration) for a quiet period, make them carefully, and then wait rather than frantically changing things again. Patience here prevents a small change from turning into an afternoon of self-inflicted chaos.
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 also 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.