Reading a zone

When you open an unfamiliar zone in a DNS host’s panel, you’re looking at a list of records that probably accumulated over years. Some belong, some are dead, some are wrong.

Knowing what a normal zone for a small business looks like is the baseline you compare against. When you can spot this zone is missing DMARC or the MX still points at the previous mail provider, you catch problems the client doesn’t know to ask about. This skill is what makes domain audits a fast and high-value MSP service.

A typical small-business zone

A small business using M365 for mail and a shared web host for the website has roughly this set of records:

The exact list varies by provider and what services the client uses, but the shape is typical.

The standard set you check for

When you read an unfamiliar zone, scan for these:

1. Apex A (or ALIAS) and AAAA. Is the apex resolving to a current IP? Is AAAA consistent with A?
2. www. Does it resolve? Same destination as the apex?
3. MX. Where does mail go? Current provider, or still pointing at a previous one?
4. SPF (TXT at apex starting with v=spf1). Present? Includes the current mail provider? Only one SPF TXT (not two)?
5. DKIM. Selector subdomain records? Resolving to the mail provider’s published keys?
6. DMARC (TXT at _dmarc). Present? What’s the policy?
7. Vendor verifications. Identify what each is for before deleting.
8. SRV records. Present for Teams / Skype / SIP / autodiscover if the client uses those.
9. NS at the apex. Matches the delegated nameservers at the registrar?
10. Anything you don’t recognise. Investigate before deleting.

Common omissions worth flagging

What this is NOT

• “Every zone should look the same.” Zones vary; the standard set is a baseline.
• “If a record is in the zone, it’s intentional.” Plenty of zones carry old records from previous setups. Audit and ask before deleting.
• “Missing records aren’t a problem if nothing is complaining.” No SPF means no protection from spoofed mail; no DMARC means no visibility. The cost shows up months later.

Decision walkthrough

A new client just onboarded. You pull their zone and see:

@      A    198.51.100.42                                              TTL 86400
@      MX   10 mail.previousprovider.example.
@      MX   20 example-com.mail.protection.outlook.com.
@      TXT  "v=spf1 include:spf.previousprovider.example ~all"
@      TXT  "v=spf1 include:spf.protection.outlook.com ~all"
@      TXT  "MS=ms12345"
www    CNAME example.com.
selector1._domainkey  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.

After SPF, fix the MX inversion: either delete the old provider’s MX entirely (if mail flow has fully moved to M365) or renumber so M365 is at priority 10 and the old provider is gone. Add DMARC at p=none with a reporting address as the next cleanup. Don’t delete the DKIM CNAME or the M365 verification TXT without confirming they’re stale — the DKIM CNAME for M365 is current and required for outbound signing.