Minimalist flat-vector illustration of an online storefront with a shopping cart connected to modular business systems
Ecommerce Platform for Small Business: How to Choose One You Won’t Outgrow
August 14, 2026
Flat-vector illustration of a card payment terminal connected to a secure chip card with a lock and shield, in gray with a magenta accent
Small Business Payment Processing: How to Take Payments Safely and Stop Overpaying
August 16, 2026

DNS for Small Business: The Invisible Records That Run Your Website, Email, and Phones

Almost every “our website is down” emergency we get called into starts the same way. The site is fine. The server is fine. The hosting bill is paid. What actually broke is a single line of configuration sitting in a control panel nobody has logged into since the site was built — a DNS record. It is the least glamorous part of your technology stack and, pound for pound, the part most likely to take your business offline.

Here is the thing worth internalizing: DNS for small business owners is not a web thing. It is a business continuity thing. The same handful of records that point visitors to your website also route every email your company sends and receives, verify your domain to Google and Microsoft, and increasingly carry your phone system too. One bad edit can silently kill all three at once. This guide walks through what those records do, where yours are probably living, how to change them without downtime, and how to lock them down so nobody fat-fingers your revenue away on a Friday afternoon.

What DNS Actually Does, in Plain English

DNS — the Domain Name System — is the internet’s address book. Computers talk to each other using IP addresses, which are strings of numbers. People, mercifully, use names like yourcompany.com. DNS is the lookup layer that translates one into the other, billions of times a day, in milliseconds.

When someone types your domain into a browser, their computer asks a chain of servers, “Where does this name point?” Those servers answer with an address, and the browser goes there. The critical detail most owners miss is that your domain name and your website are two entirely separate things. Your domain is a name you rent from a registrar. Your website is files sitting on a server somewhere. DNS is the string connecting them — and that string can be cut, redirected, or left dangling independently of either end.

That separation is why a business can lose its email while its website stays perfectly up, or lose its domain entirely while every server keeps humming along untouched.

The Records That Matter

You do not need to learn all of DNS. There are roughly nine record types that carry the weight for a typical small or mid-sized business, and understanding them at a conversational level is genuinely enough.

Record What it does What breaks if it’s wrong
A Points your domain to a server’s IPv4 address Website unreachable
AAAA Same, for IPv6 addresses Site fails for IPv6-only visitors
CNAME Points one name at another name (e.g. www → root domain) Subdomains and vendor-hosted tools break
MX Tells the world which mail servers accept your email Inbound email stops arriving — silently
TXT (SPF) Lists who is allowed to send email as your domain Your outbound mail lands in spam
TXT (DKIM) Publishes the key that cryptographically signs your mail Authentication failures, spam folder
TXT (DMARC) Tells receivers what to do when mail fails SPF/DKIM Spoofing goes unchecked; deliverability suffers
NS Names the authoritative servers holding all of the above Every record above stops applying at once
SRV Points to services on specific ports (VoIP, chat, directory) Phones fail to register or route

Two things stand out on that list. First, four of the nine are about email — which is why we treat DNS and mail as a single conversation rather than two. If your messages are landing in junk folders, the cause is usually sitting in these records; our guide to keeping your business email out of the spam folder goes deep on exactly that. Second, the NS record is the master switch. Change it and every other record on this page becomes irrelevant instantly, because you have just told the internet to ask a different set of servers entirely.

Where Your DNS Actually Lives (and Why Nobody Knows)

This is the question that stalls most troubleshooting calls for the first twenty minutes. There are three plausible homes for your records, and the honest answer for many businesses is “we’re not sure.”

  • Your registrar — the company you bought the domain from. Convenient, usually free, and where DNS lives by default until somebody moves it.
  • Your web host — very common, because a developer pointed the NS records at the host during a build so they could manage everything in one panel.
  • A dedicated DNS provider — a managed service chosen deliberately for speed, redundancy, security controls, and better access management.

The trap is the gap between where records appear to live and where they are authoritative. We have lost count of the times someone edited an A record at their registrar, waited an hour, and saw nothing change — because the NS records had been pointed at the web host years earlier, and the registrar’s zone had been an inert copy ever since. Before you change anything, confirm which nameservers your domain actually delegates to. Everything else is guesswork until you do.

Your domain is the single most valuable digital asset your business owns. It is also, in most small companies, the one nobody has been formally assigned to own.

TTL: The One Dial Worth Understanding

Every DNS record carries a TTL — time to live — measured in seconds. It tells the rest of the internet how long to cache the answer before asking again. A TTL of 86400 means resolvers worldwide may keep serving the old answer for a full day after you change it.

This single number explains most “I changed it but nothing happened” frustration. It also gives you a lever. Before any planned change, lower the TTL on the affected records to something short — 300 seconds is a common choice — and wait for the old TTL to fully expire before cutting over. Your change then propagates in minutes instead of a day, and if something goes wrong, your rollback lands just as fast. Raise the TTL back up once you are stable.

How to Migrate Without Downtime

Moving hosts, changing email providers, or launching a redesign all end with a DNS change. The change itself takes ten seconds; doing it safely is about what surrounds it. Our approach on client migrations follows the same order every time:

  1. Export the current zone first. Copy every existing record into a document before you touch anything. This is your map and your rollback plan, and it costs five minutes.
  2. Inventory the dependencies. Verification records for Google Workspace or Microsoft 365, marketing platform CNAMEs, e-signature tools, SSL validation records, VoIP entries. These get orphaned during migrations constantly.
  3. Lower TTLs. Do this at least a full old-TTL period before cutover — often 24 to 48 hours ahead.
  4. Stand up the new destination completely. The new server or mail platform should be fully working and tested before a single visitor is routed to it.
  5. Cut over during a genuine low-traffic window. Not Friday at 5 p.m. Choose a time when someone is available to watch and respond.
  6. Verify all three pillars. Load the website. Send mail out and receive mail in. Place a test call. A migration that only checks the website is a migration that finds its email problem on Monday.
  7. Restore TTLs and re-document. Update the record of truth so the next person inherits reality instead of folklore.

If you are changing hosts as part of this, the destination matters as much as the routing — we covered how to evaluate that decision in our guide to choosing a host and knowing when to move.

Locking It Down

Domain security gets far less attention than it deserves, largely because the failure mode is rare and catastrophic rather than frequent and annoying. If someone gains control of your domain, they control your website, your inbound email, and the password-reset path for most of your other accounts. That is a total compromise, achieved without ever touching your servers.

The controls worth putting in place are neither expensive nor difficult:

  • Enable registrar lock so the domain cannot be transferred away without an explicit unlock.
  • Turn on auto-renew and keep a payment method on file that has not expired. Domains lapse because a card was replaced, not because anyone decided to let them go.
  • Use a role-based email for the registrar account — something like domains@ that survives an employee departure, rather than a personal mailbox.
  • Require multi-factor authentication on the registrar and DNS provider accounts, without exception.
  • Publish a CAA record to declare which certificate authorities may issue SSL certificates for your domain.
  • Consider DNSSEC, which cryptographically signs your DNS responses so they cannot be forged in transit.
  • Keep a DMARC policy in place and actually read the reports it generates.

An Annual DNS Hygiene Check

Once a year — or any time you change a major vendor — walk the zone and ask a few questions. Is every record still pointing at something that exists? Dangling CNAMEs left behind by a decommissioned service are a real subdomain-takeover risk. Does your SPF record still list vendors you actually use, and does it stay within the lookup limits mail providers enforce? Are there verification TXT records for platforms you abandoned two years ago? Is anyone still receiving mail at the addresses your registrar has on file?

It is a thirty-minute exercise that prevents the kind of outage that costs a day. For most growing businesses, the honest answer is that this belongs with whoever owns the rest of your infrastructure rather than with whichever developer happened to build the site — which is exactly the sort of gap our I.T. and communications team is built to close.

Who Should Own This

The pattern we see over and over is that DNS ends up owned by nobody. The web developer touched it during the build. The email vendor added records during setup. The phone provider sent instructions that somebody pasted in. Three years later there is no documentation, no clear account holder, and no one confident enough to change a record without holding their breath.

Fix that with three concrete steps: put the registrar and DNS accounts under company control with company credentials, write down what every record in your zone is for, and name one person or partner accountable for reviewing it. That is the whole assignment. It takes an afternoon and it removes an entire category of business risk permanently.

If you are not sure where your records live, whether your email authentication is configured correctly, or how to move hosts without a day of downtime, we are glad to take a look. Frozen Crow offers a free, no-obligation consultation — reach out at frozencrow.com and we will walk your domain with you, tell you plainly what we find, and help you get it documented and locked down. Our team, your goals.

Leave a Reply

Your email address will not be published. Required fields are marked *