← Blog  ·  October 2026

DNS Record Monitoring: Get Alerted When Your DNS Changes

How unauthorized changes, botched deployments, and silent TTL drift break production — and the one-time setup that catches all of it.

DNS changes are some of the most damaging failures in production infrastructure — and some of the hardest to detect. Unlike an application crash or a failed deployment, a wrong DNS record doesn't throw an error. It just quietly breaks things. Email stops delivering. Users land on the wrong server. An API integration stops working. And depending on your TTL, the problem can persist for hours or days before anyone traces it back to a DNS change.

This post covers the three common ways DNS changes silently break production, and how to set up monitoring that catches them before users do.


Why DNS changes are so dangerous

Unauthorized or accidental changes

DNS is almost always a shared system. Multiple people have access to your registrar or DNS provider. A developer updates an A record for a staging subdomain and accidentally changes the production one. An automated deployment script updates a CNAME but targets the wrong zone. Someone testing a migration removes a TXT record that was being used for email authentication.

None of these generate an alert. The change is made, the old record is gone, and production breaks — usually at the worst possible time.

MX record errors that bounce email for days

MX records determine where your email goes. A misconfigured MX record — wrong priority, wrong hostname, pointing to a decommissioned mail server — means incoming email gets silently discarded or bounced. The senders get a bounce message but you don't. Your team notices days later when they realize nobody has replied to that customer inquiry from Thursday.

Email delivery failures from bad MX records are particularly costly because they're invisible from the inside. From your perspective, everything looks normal. Nobody told you about the bounces.

TTL drift after migrations

When you migrate a service to a new server or CDN, you update the A record and everything looks fine. But you had a 48-hour TTL. Some users are still hitting the old server for two more days. The old server gets decommissioned. Those users start seeing errors.

Monitoring your TTL and being alerted when it changes unexpectedly (or when it stays high after a migration) prevents this class of problems. You catch the configuration gap before it becomes a user-facing outage.

The real problem with DNS changes DNS failures are often discovered by customers before your team. By the time someone reports "I can't reach your site" or "your email is bouncing," the change has been in place long enough for DNS to propagate — meaning the blast radius is already at maximum.

What DNS monitoring actually checks

DNS monitoring compares your current DNS records against a known-good baseline and alerts you when anything diverges. Specifically, it watches for:

The monitoring doesn't prevent changes — it just ensures you know about them within minutes of when they happen, rather than after users start complaining.


How to check your current DNS records

Before setting up monitoring, you need a snapshot of what your DNS records currently look like. A few options:

Command line

# All record types for a domain
dig github.com ANY

# Specific record types
dig github.com A
dig github.com MX
dig github.com TXT
dig github.com NS

# Check from a specific nameserver
dig @8.8.8.8 github.com A

Free browser tool

🔍 Check any domain's DNS records instantly: dns-checker — look up A, AAAA, MX, TXT, CNAME, NS records in one click → No signup required.

Setting up DNS change monitoring

There are two approaches, depending on your scale and budget.

Self-monitoring with a script

For small setups with a handful of domains, a cron job that checks your DNS records and compares them to a stored baseline is straightforward:

#!/bin/bash
# dns-monitor.sh — runs daily via cron
DOMAIN="yourdomain.com"
EXPECTED_A="203.0.113.42"
CURRENT_A=$(dig +short $DOMAIN A | head -1)

if [ "$CURRENT_A" != "$EXPECTED_A" ]; then
  echo "ALERT: A record for $DOMAIN changed to $CURRENT_A" | \
    mail -s "DNS Change Detected" you@company.com
fi

Extend this for each record type you care about. The downside: you're maintaining the script, the cron job, and the baseline. And if your monitoring cron job fails silently, you're back to square one.

Dedicated DNS monitoring service

For production domains that matter, a dedicated service is more reliable. It checks from multiple locations, stores the history of changes with timestamps, and sends alerts by email, Slack, or webhook without any infrastructure on your side.

What to look for in a DNS monitoring service:

📡 DNSWatch — instant alerts when your DNS changes

DNSWatch monitors your DNS records every few minutes and sends an email the moment anything changes — A, AAAA, MX, TXT, CNAME, or NS. See exactly what changed, when it changed, and from what value. $9/month for up to 10 domains.

Join the DNSWatch waitlist → Check your current DNS records free

A practical monitoring checklist

For any domain that has production traffic or handles email:

  1. Take a snapshot of your current records (use dig or the free tool above)
  2. Set up monitoring for A, MX, TXT (SPF/DKIM), and NS records at minimum
  3. For customer-facing subdomains: monitor their CNAMEs too
  4. Set check frequency to ≤15 minutes for domains handling live traffic
  5. Alert to at least two channels (email + Slack) so a silent email failure doesn't hide a DNS alert
  6. Review your change history quarterly — catching slow TTL drift early prevents migration headaches

← All articles  ·  DNSWatch  ·  Free DNS checker