DNS is the single most consequential thing in your client's stack that nobody on the agency side wants to think about. The reason is that DNS docs were written for sysadmins running their own BIND zones in 2002, and what an agency operator actually needs is a 20-minute mental model that explains why MX records keep "mysteriously" disappearing and what the difference between an A record and a CNAME is when a host migration goes sideways.
This is that post. No BIND syntax, no dig answer-section dissection, just the record types you'll see in client portfolios and what each one breaks when it goes wrong.
The five record types you actually deal with
DNS has dozens of record types. In agency work you'll touch five.
A — IPv4 address
What it does: maps a hostname to an IPv4 address.
acme.com. 3600 IN A 216.198.79.1
www.acme.com. 3600 IN A 216.198.79.1
When a browser asks "where is acme.com?", the answer is 216.198.79.1. That's it.
How it breaks in client work:
- Host migration not finished: client moves from Bluehost to Cloudways. New IP set, but the A record still points to the old host. Site looks "down" because the new host doesn't recognize the old hostname → 404 or a parking page.
- Multiple A records left over from a redundancy setup: client used to have two hosts behind round-robin DNS. They dropped one. The dead IP is still in DNS, so a third of visitors hit nothing.
- CDN added without removing the underlying A record: a CNAME at
wwwto Cloudflare is set up, but the apexacme.comis still pointing direct to origin. Visitors who type the bare domain bypass the CDN entirely.
Detection: a daily snapshot of A records and an alert on change. If the IPs flipped without you doing it, that's a conversation.
AAAA — IPv6 address
Same as A but for IPv6. Increasingly mandatory — Apple Private Relay clients and some corporate networks prefer IPv6, and a missing AAAA record adds 50–200ms to first byte.
acme.com. 3600 IN AAAA 2606:4700::6810:84e5
How it breaks: usually it just isn't there. Most managed hosts auto-provision AAAA; some (cheap shared hosting, older WordPress hosts) don't, and clients of yours quietly lose performance for IPv6-preferring users without anyone realising.
Detection: track whether AAAA exists. If a client previously had it and now doesn't, the site moved to a host that's stuck in 2014.
MX — mail exchange
Where email for the domain goes.
acme.com. 3600 IN MX 10 smtp.google.com.
acme.com. 3600 IN MX 20 alt1.smtp.google.com.
Two MX records here, with priorities 10 and 20. Senders try the lower-priority record first (counterintuitively — "priority 10" means "tried first"). Higher numbers are fallbacks.
How it breaks:
- MX disappears entirely: someone editing DNS deleted the MX record by accident. Email starts bouncing immediately. Slack channel of pain ensues.
- MX points at the old email host after migration: client moved from Google Workspace to Microsoft 365 a year ago, but the agency missed updating the MX. Old Workspace tenant is shut down, mail bounces.
- Pointing at the host's mail server, not the email provider: cheap shared hosts auto-create MX records pointing at themselves. If the client uses Google for email but the host's MX got reinstalled during a migration, mail flow breaks silently.
- Catch-all MX with a typo:
mail.acme.cominstead ofmail.acme.com.— the trailing dot matters in DNS. Without it, some registrars helpfully append the domain again, giving youmail.acme.com.acme.com. Mail goes to the void.
Detection: snapshot MX records and alert on any change. This isn't an alert that fires often, so when it does, look hard.
NS — name servers
The most important and the most invisible. NS records say who is authoritative for this zone. The registrar tells the world "for acme.com, ask these name servers." Those name servers then serve the A, MX, TXT, etc records.
acme.com. 86400 IN NS ns1.dyna-ns.net.
acme.com. 86400 IN NS ns2.dyna-ns.net.
How it breaks:
- Client moves DNS hosting (registrar to Cloudflare, or Cloudflare to Route53). NS records change at the registrar level. If the new DNS provider doesn't have the zone fully populated, MX/A/TXT all stop resolving.
- Domain hijack: someone gets into the registrar account and points NS at name servers they control. From the outside it looks like a routine NS change. The site now serves their content, all email is intercepted, recovery takes weeks.
- NS partial outage: one of the name servers is down. Most resolvers will fall back to the working one, so the site appears mostly fine — but corporate networks with strict DNS caching may hit the dead one and report the site as down. You don't see this from your laptop.
Detection: a daily snapshot of NS records is the single most important DNS monitor for agencies. If NS changed and you didn't change it, that's an emergency-call event, not an email-the-client event. The client's whole DNS surface — and email — is now controlled by whoever made that change.
TXT — arbitrary text records
Originally for human-readable notes. Now used for everything email-auth, domain-verification, and AI-search-engine related.
acme.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
acme.com. 3600 IN TXT "google-site-verification=..."
_dmarc.acme.com. 3600 IN TXT "v=DMARC1; p=quarantine; ..."
You'll see TXT records used for:
- SPF — "these IPs are allowed to send email for this domain"
- DKIM — public keys for email signature verification
- DMARC — email delivery policy
- MTA-STS / TLS-RPT — modern email security
- Domain ownership verification for Google, Microsoft, Stripe, dozens of others
- AI-engine verification — Perplexity, OpenAI's web crawler config
How it breaks:
- DKIM key removed during a "cleanup": the marketing team rotated their email provider, the old DKIM key in TXT was deleted, the new one wasn't added. Mail starts going to spam folders within hours.
- SPF too restrictive: client adds a new email tool (Customer.io, Intercom). Forgot to add it to SPF. Half of transactional email gets soft-bounced.
- Old verification records left forever: TXT records from 2018 for tools the client doesn't use anymore are still there. Not breaking anything but cluttering the zone and confusing future you.
Detection: TXT records are noisy. Snapshotting them daily is fine but you'll get false-positive "change detected" alerts because legit ops adds and removes them constantly. Scope alerts to specific records — DMARC removed = critical, random TXT added = info.
Records you'll see less often
- CNAME: alias from one hostname to another. Common for
www.acme.com → acme.comor for SaaS endpoints (docs.acme.com → cname.gitbook.com). CNAMEs cannot exist at the apex (you can'tCNAMEacme.comitself in standard DNS). Some DNS providers fake an apex CNAME viaANAMEorALIASrecords. - SRV: service records for SIP, XMPP, Microsoft 365 services. Mostly auto-managed.
- CAA: authorises which certificate authorities can issue certs for the domain. Worth setting; almost nobody does. If your client got hit by a CA-issued cert they didn't authorise, CAA would have prevented it.
You don't have to monitor SRV or CAA for normal client work. They're set once and then forgotten.
Patterns that catch real problems
The five things below aren't theoretical. We see each of them across agency portfolios every month.
Pattern 1: NS changed = stop everything
NS change without a corresponding ticket from the agency = unauthorised DNS-host migration or hijack. This deserves an SMS, not an email. Get the client on the phone.
Pattern 2: MX disappeared = email is dying right now
The TTL on MX records is usually 3600 (1 hour). From the moment MX disappears, you have one hour before mail starts bouncing globally. If your monitoring runs daily, that's not enough — check MX hourly for any client running their own email through the domain (i.e. anything with Google Workspace or Microsoft 365 attached).
Pattern 3: A records change = the site moved or got hijacked
If the change is intentional (host migration), you knew about it and the alert clears in five minutes. If it's not, you're either looking at a successful registrar hijack or a misconfiguration during a routine change. Either way, the alert pays for itself.
Pattern 4: AAAA disappeared = host is silently worse than before
Lower priority than the above. Worth knowing but not 3am-call-worthy.
Pattern 5: TXT spawned a new SPF / DMARC = email auth changed
Easy to miss. If your client suddenly has a p=reject DMARC where they had p=none last week, half their newsletters are now in spam folders for the first 72 hours. Worth a "did you mean to do this?" message.
Tools
You can run DNS monitoring with dig in a cron and a diff. That's the version we built for ourselves before turning it into a product.
If you want it productised — three-tier alerts on the patterns above, a snapshot history, a per-client dashboard — that's Pleenx. Daily checks across A, AAAA, MX, NS, TXT for every domain you add, alerts when records change without you doing it. We probe externally (no agents on client servers) and the alert defaults are tuned to the patterns in this post.
If you'd rather DIY, this is a serviceable starting dig script:
#!/usr/bin/env bash
set -euo pipefail
domain=$1
echo "=== $domain ==="
for type in A AAAA MX NS TXT; do
printf "%-5s " "$type"
dig +short $type "$domain" | tr '\n' ' '
echo
done
Run it daily, store the output, diff against yesterday. Anything non-empty in the diff is your worklist for the day.
Related reads: What breaks when an SSL cert expires is the same playbook for the TLS layer. Domain auto-renewal failures covers the WHOIS side. The WordPress care-plan checklist shows how all four (DNS, SSL, WHOIS, HTTP) fit into a real agency monitoring stack.