DNS Spy
When something goes wrong in a client’s infrastructure, MSPs are expected to fix it—fast. But there’s one area most teams still overlook, and it’s often the first point of failure: DNS.
Misconfigured DNS doesn’t always break things immediately. It’s subtle. It lingers. And when it finally causes an outage, broken email, or a security issue, it’s often too late.
Here are the DNS misconfigurations MSPs can’t afford to ignore—and what to do about them.
SPF, DKIM, and DMARC Gone Wrong
These DNS records form the backbone of email security and deliverability. But even well-meaning MSPs get them wrong:
Multiple SPF records cause validation failures.
DKIM keys are missing or expired.
DMARC is set to "none" or is overly strict, silently blocking legitimate messages.
📉 Result: Clients don’t know why their emails end up in spam—or disappear entirely.
Missing or Incorrect A/AAAA Records
A single wrong A record and your client’s site is offline. It’s that simple.
DNS points to an old IP address.
A record is accidentally deleted.
IPv6 AAAA records are misconfigured or missing.
This is low-hanging fruit for attackers—and high-stress for clients.
Expired or Misconfigured NS Records
Name servers determine who controls DNS—if they’re out of sync, everything downstream is at risk.
NS records point to decommissioned providers.
Different name servers show different records (“split-brain” DNS).
Clients accidentally update registrars without your knowledge.
The scariest part? It may still work… until it doesn’t.
Forgotten Test Records or Internal Hostnames
That dev.clientdomain.com you set up for staging last year? Still live.
Exposed internal hostnames can aid attackers during reconnaissance.
Forgotten subdomains can lead to subdomain takeover.
They also create client confusion when things “just show up” in external scans.
Wildcard Records That Backfire
Wildcards like *.clientdomain.com seem convenient—until they’re not.
Accidentally expose legacy or vulnerable systems.
Break validation on services expecting specific subdomains.
Become invisible entry points for threat actors.
Wildcard records must be monitored closely or eliminated entirely.
Unmonitored TTL Changes or Record Drift
When a developer changes a TTL or updates a record in an external dashboard, does anyone know?
Low TTLs cause cache storms.
Long TTLs delay fixes.
Silent record changes make troubleshooting nearly impossible.
Without DNS change history and alerts, you’re flying blind.
No Change Alerts, No Audit Trail
The most dangerous DNS issue? The one you didn’t know happened.
If your MSP isn't tracking:
Who changed DNS?
When it changed?
What changed exactly?
…then you’re setting yourself up for painful outages and finger-pointing.
What MSPs Can Do Today
You can’t audit every domain every day—not manually.
What you can do:
✅ Monitor DNS changes across all client domains
✅ Get alerts the moment something changes
✅ Track historical DNS records for fast rollback and auditing
✅ Integrate alerts into your SIEM or ticketing system
✅ Offer DNS monitoring as a value-add to your MSP services
🛠️ DNS Spy was built to solve exactly this problem—at MSP scale.
Final Thoughts
DNS is often the forgotten layer of your client’s stack. But when it breaks, you’re on the hook.
The good news? Fixing it is easy. A little visibility goes a long way.
👉 Get the MSP’s Guide to DNS Monitoring
Learn what to look for, what to monitor, and how to scale it—without adding overhead.