DNS for Small Business Owners: A Plain-Language Guide

DNS is one of those parts of running a website that nobody explains to small business owners until something goes wrong. A new site does not load on a particular phone, an important email lands in the recipient's spam folder, the domain quietly expires because the renewal email got lost, and suddenly DNS becomes a vocabulary problem on top of an emergency.

This post is the explanation I want every client to have read before they need it. What DNS actually is, the five record types that matter for a small business, what happens when each one is wrong, and how I configure them at launch.

What DNS actually is

DNS is the internet's address book. When a visitor types yourbusiness.com into their browser, the browser does not know where on the internet that name actually lives. It asks the DNS system, "where is yourbusiness.com?" The DNS system returns a numeric IP address, the browser opens a connection to that address, and the website loads.

Every domain has a small set of records that tell the DNS system how to answer that question. Those records live at your domain registrar (where you bought the domain) or at a separate DNS provider (Cloudflare, Route 53, etc.). They are public, queryable by anyone, and they govern more than just the website. Email, file sharing, video conferencing, and almost every internet-facing service that uses your domain reads from the same records.

The five records that matter

Most small business domains need exactly five record types configured. Each one solves a specific problem, and the cost of getting any of them wrong is real.

1. A and AAAA records (where the website lives)

The A record points your domain at the IP address of the server hosting your website. AAAA is the same thing for IPv6 addresses (the newer numbering system). When a visitor types your domain, the browser reads the A record to find the website.

For sites I build on Cloudflare Pages, the A record is replaced by a CNAME (see below) that points at Cloudflare's edge network. The visitor's browser is then routed to whichever Cloudflare data center is geographically closest, which is what makes the site fast worldwide.

What goes wrong: if the A record is missing or wrong, the website does not load at all. The browser shows "this site can't be reached." Common after a site migration when the old A record was removed before the new one was set.

2. CNAME records (aliases)

CNAME records say "this name is an alias for that other name." Used for two main things: pointing the www. subdomain at the same place as the bare domain, and pointing the domain at a hosting provider's server name (so they can change IP addresses without you having to update your DNS).

For sites I build, the typical CNAME setup is:

• www.yourbusiness.com → CNAME to yourbusiness.com (so both versions of the URL work)
• yourbusiness.com → CNAME to Cloudflare Pages' edge address

What goes wrong: a missing www. CNAME means visitors who type the URL with www in front see an error. This used to be more common than it sounds.

3. MX records (where email goes)

MX records tell the internet where to deliver email sent to your domain. If someone emails jane@yourbusiness.com, their email server reads your MX records to figure out which mail server to deliver to. The MX records typically point at Google Workspace, Microsoft 365, or whatever email provider you actually use.

What goes wrong: if MX records are missing or wrong, email sent to your domain bounces. The sender gets a "delivery failed" notification. This is usually noticed within hours of a configuration error because someone tries to email the business and cannot.

For sites I build, I configure MX records to point at whichever email provider the client uses (or sets up at launch). I do not host email myself, but I make sure the records are correct so the client's chosen provider works.

4. SPF, DKIM, and DMARC records (spam protection)

This is the trio of records that decides whether email sent from your domain reaches the recipient's inbox or gets filtered as spam. They are technical, often skipped during initial setup, and the cost of skipping them is that legitimate emails from your business start landing in spam folders without explanation.

SPF (Sender Policy Framework) is a TXT record that lists which mail servers are allowed to send email from your domain. Without SPF, anyone can pretend to be sending from your domain. With SPF, the recipient's mail server can verify "yes, this email came from a server you authorized." Looks like:

v=spf1 include:_spf.google.com ~all

DKIM (DomainKeys Identified Mail) is a cryptographic signature on every email your mail server sends, verifiable by the recipient. Configured by your email provider; you copy the public key from their setup wizard into a TXT record at your DNS host. Without DKIM, the recipient has no cryptographic proof that the email actually came from your mail server.

DMARC (Domain-based Message Authentication) is the policy that tells receiving mail servers what to do with mail that fails SPF or DKIM checks. Without DMARC, the receiver decides on its own (usually conservatively, meaning more of your legitimate mail goes to spam). With a properly configured DMARC record, you can say "if my mail fails the checks, reject it outright" — which both protects your domain from spoofing and signals to receivers that your real mail is trustworthy.

What goes wrong: small business email bouncing into spam folders. The most common cause across every client I have worked with. The fix is correct SPF, DKIM, and DMARC records, and it makes a measurable difference in deliverability within days.

5. TXT records (verification + miscellany)

The catch-all record type for tasks that need a small text string at a specific name. Most commonly used for:

• Domain verification (Google Search Console, Microsoft 365, etc.)
• SPF and DMARC (described above)
• Domain-based service discovery for some platforms

TXT records do not break anything if extra ones are present, but they should be cleaned up periodically. A domain with thirty stale TXT records from past services is harder to audit when something goes wrong.

What I do at launch

For every site I build, I configure DNS at the client's preferred registrar (or move it to Cloudflare DNS if they want, which is faster and free). The launch checklist:

1. A/CNAME for the website. Point the domain at Cloudflare Pages' edge address.
2. CNAME for www.. Make both URL versions work.
3. MX records. Point at the client's email provider.
4. SPF. List the email provider's authorized servers.
5. DKIM. Set the public-key TXT record from the email provider.
6. DMARC. Start with a permissive monitoring policy, then tighten to enforcement after thirty days of clean reports.
7. Domain verification TXT. Add the Google Search Console verification record (and any other services the client uses).

The whole DNS setup takes about an hour at launch. After that, the records stay stable until the client adds a new email provider or service that needs its own record.

Domain renewal: the part that fails silently

One non-DNS task that ties to the same control surface: domain renewal. Every domain has an expiration date. Registrars send renewal-reminder emails, but those emails often land in spam or get ignored. If the domain expires and no one notices, the website goes dark and email stops working overnight.

I monitor renewal dates directly via WHOIS rather than relying on the registrar's email reminders. Sixty days, thirty days, and seven days before expiration, I send the client a heads-up. If the domain does lapse, most TLDs have a thirty-day redemption window during which it can still be recovered, and I help with that.

This is one of those small operational things that almost never matters and is catastrophic when it does.

If your current DNS is messy

Three quick checks any business owner can run:

1. Does www.yourbusiness.com work? If only the bare domain works, your www. CNAME is missing.

2. Send a test email to a Gmail account from your business email and look at the headers. If SPF or DKIM is failing, Gmail will say so in the message details. Failed checks land you in spam more often.

3. Check your domain's expiration date. Go to whois.icann.org, type your domain, and look at the expiration date. If it is less than ninety days away and you have not seen a renewal email, set a calendar reminder.

For sites I build, all three of these are wired in at launch and monitored thereafter. For sites I do not build, the same checks apply, and the fixes are usually small.