DNS is the part of your online presence nobody thinks about until email stops arriving. You do not need to become a network engineer — but knowing what the five common record types do, and where the traps are, will save you at least one very stressful afternoon.
What DNS actually does
The internet routes traffic by number, not by name. When someone types your domain or emails your company, their software first asks the Domain Name System a question: where does this name actually live? DNS answers with an address, and only then does the visit or the email happen.
Think of it as your business’s public directory listing. The records in that directory decide where your website loads from, where your email is delivered, and who is allowed to send messages in your name. They live at your DNS host — often, but not always, the same company as your domain registrar — and every record is just a small instruction: this name points to that place.
Two consequences follow. First, DNS is upstream of everything: a wrong record can take down a perfectly healthy website. Second, whoever holds the login to your DNS effectively holds your web presence. Know where that login is.
A, AAAA, and CNAME: pointing names at places
These three records handle the “where is the website” half of the job.
- An A record points a name at a server’s IPv4 address — the classic four-number kind. This is usually what sends yourbusiness.com to your hosting provider.
- An AAAA record does the same for IPv6, the newer, longer address format. Providers typically set both so you are reachable either way.
- A CNAME record is an alias: it says “this name is answered by that other name.” A common pattern points www.yourbusiness.com at the bare domain, so both load the same site and you only maintain the real address in one place.
The practical takeaway: when you change hosting providers, it is these records — and only these — that should change. Which brings us to the record that too often changes by accident.
MX and the email trio: SPF, DKIM, DMARC
An MX record answers a different question: not where your website is, but where your email should be delivered. Your site and your mailbox are usually run by different providers, and MX records are what keep them independent. Delete or mispoint them and mail sent to you starts bouncing — silently, from your side.
Alongside MX sit a family of TXT records that protect your sending reputation:
- SPF lists which servers are allowed to send email as your domain.
- DKIM adds a cryptographic signature proving a message really came from you.
- DMARC tells receiving servers what to do with mail that fails those checks — and sends you reports about who is impersonating you.
You rarely write these by hand; your email provider gives you the values. But if they are missing or wrong, the symptom is brutal for a business: your invoices and proposals land in spam folders, and no error message ever tells you.
TTL: the waiting period nobody plans for
Every DNS record carries a TTL — time to live — which tells the rest of the internet how long to cache the answer before asking again. A TTL of 24 hours means that after you change a record, some visitors may keep landing on the old address for up to a day. That is the “propagation delay” people mention, and it is not mysterious — it is a setting.
The professional move is simple: a day or two before a planned change, lower the TTL on the records involved to a few minutes. Make the change, confirm everything works, then raise the TTL back up. Same records, same change — but the switchover happens in minutes instead of a nervous day, and rolling back is just as fast.
The mistakes that actually hurt
Almost every DNS horror story a business tells is one of these four:
- Moving the website and breaking the email. A new web provider says “point your domain at us,” someone updates all the records or switches nameservers without copying the MX and TXT entries — and email dies mid-migration. This is why careful providers stage a move: assess what exists, configure the new environment, then migrate and verify with the email records copied first.
- Deleting mystery records. That odd-looking TXT value may be verifying your domain for your email provider or an integration. If you do not know what a record does, find out before removing it.
- Leaving TTL high before a cutover, then discovering the change takes a day to settle — during business hours.
- One person holds the keys. Registrar and DNS logins living in a former employee’s inbox is the most common single point of failure we see. Move them to a shared, recoverable account your business controls.
Should you manage DNS yourself? If your setup is one website and one email provider, and you follow the TTL rule above, you can. The moment the picture includes migrations, multiple services, or email deliverability problems, DNS becomes a place where small edits carry outsized risk — and handing it to someone who works in it daily is cheap insurance.
Qubits manages domains and DNS as part of hosting, and every migration we run is staged so mail keeps flowing while the website moves. Unsure what your current records even say? Send us a note — we will review them and reply within two business days.