Do I need to check all five of these on every client site?

For a first pass, yes — these five catch the overwhelming majority of real-world DNS problems on small business sites. You don't need to audit every possible record type, just these: A/AAAA, MX, TXT (SPF), the common CNAMEs, and NS. Once you've done a few client audits, running through this list takes a couple of minutes.

The client's domain has no MX record at all — is that always a problem?

Not necessarily. Some businesses intentionally route all mail through a separate system, a help desk platform, or don't use email on their own domain at all. A missing MX record isn't automatically broken — but you should confirm with the client that it's intentional rather than assuming it's fine, since "nobody set it up" and "we did this on purpose" look identical from the DNS side.

How does this checklist relate to the 10-Minute Network Health Check guide?

That guide is the fast, three-tool pass (DNS, WHOIS, SSL) you run on day one with a brand-new client. This one is a deeper reference specifically for the DNS piece of that check — useful any time you need to verify a client's DNS is correctly configured, not just during onboarding.

DNS Records Every Client Site Should Have — A Checklist

A fast reference checklist for freelance IT consultants and small MSPs: the five DNS record types worth checking on any client site, what each does, and what "wrong" actually looks like.

DNS problems are rarely dramatic. Nobody calls you because a TXT record is missing — they call because "email is going to spam" or "the www site is down" or "our new tool says domain verification failed," and the actual cause turns out to be one DNS record that was never set, or never updated after a migration. This is the reference list to work through when you need to confirm a client's DNS is actually correct, not just "the site loads."

Run the domain through DNS Lookup first, then check what comes back against this list.

A / AAAA records

What they're for: point the domain at the actual server IP address — A for IPv4, AAAA for IPv6.

What wrong looks like: the record points at a host that isn't where the site is actually running anymore — the classic sign of a migration that never fully cut over. If the client says they moved hosting providers "a while ago" and you see an IP that doesn't match the new host, that's your finding.

MX records

What they're for: tell the world which mail servers handle email for this domain.

What wrong looks like: MX records still pointing at an old email provider after a switch to a new one (Google Workspace and Microsoft 365 migrations are the usual suspects) — mail quietly misrouting or bouncing while nobody's watching. Also worth flagging: no MX record at all, which isn't automatically wrong (see the FAQ below) but is always worth confirming.

TXT records (SPF at minimum)

What they're for: SPF authorizes which mail servers are allowed to send email as this domain — it's an anti-spoofing and deliverability record. Other TXT records typically handle domain-ownership verification for services like Google Workspace, Microsoft 365, or marketing tools.

What wrong looks like: no SPF record at all, which tends to land legitimate mail (from a CRM, a marketing platform, an invoicing tool) in spam instead of the inbox. Also common: an SPF record that's missing one of the services actually sending mail on the client's behalf — usually because a new tool got added after the SPF record was last touched, and nobody remembered to update it.

CNAME records (www, mail, and other common subdomains)

What they're for: alias one hostname to another — most commonly www pointing at the bare domain, or a subdomain pointing at a hosted service (a help desk, a marketing landing page tool, etc.).

What wrong looks like: www.clientdomain.com not resolving at all while the bare domain works fine — a surprisingly common gap that's easy to miss if you only ever test the bare domain. Also watch for a CNAME still pointing at a service the client stopped using months ago.

NS records

What they're for: identify which nameservers are actually authoritative for the domain — in other words, who really controls DNS for this client, regardless of who they think controls it.

What wrong looks like: nameservers that don't match the DNS provider or registrar the client believes they're using. This almost always means an old provider from before a migration that never got fully retired — and it means any DNS change you make in the "current" provider's dashboard might not actually be the one taking effect.

Bookmark this page — it's built to be the reference you pull up any time you need to sanity-check a client's DNS, not just something you read once.