DNS records are the invisible configuration layer that makes the internet work for your domain. Your A record decides which server users reach. Your MX records determine where email is delivered. Your TXT records prove your identity to mail servers and domain validators. When any of these change unexpectedly — through a provider mistake, a security breach, a misconfigured automation script, or a team member's unannounced edit — the consequences can range from intermittent errors to complete service loss.
The problem is that DNS changes are easy to miss. This article explains why, what to monitor, and how to detect changes before they become incidents.
DNS is a caching system by design. When a record changes, the old value persists in caches around the world until TTLs expire. From inside your network — querying your own nameserver or a resolver that just refreshed — things look correct. Meanwhile, users hitting different resolvers may be getting stale or wrong answers for hours.
Two structural issues make this worse:
Recursive resolvers cache DNS answers according to the TTL in each record. If an attacker or misconfiguration changes your A record, and your TTL is 3600, resolvers that cached the old answer will serve it for up to an hour. But resolvers that haven't recently queried your domain will immediately pick up the new, wrong value. The result: some users reach your real server, others reach a different destination, and the split makes the problem harder to identify.
Many companies spread DNS management across multiple providers: primary DNS on Cloudflare, secondary on Route 53 for redundancy, CDN configuration in Fastly, email routing managed through Google Workspace, and domain registration at a different registrar. When any one of these systems makes a change — through its own automation, a misconfigured sync, or a provider-side incident — the rest of the chain may not reflect the change consistently. There's no single dashboard showing you the complete current state of your DNS.
Not all record types carry equal risk. Here's what matters and why:
Your A record maps your domain to an IPv4 address. This is the most critical record to monitor — unauthorized changes can redirect traffic to a malicious server (DNS hijacking), route users to a decommissioned IP, or break connectivity entirely. Even intentional changes need monitoring to confirm propagation completes correctly.
CNAMEs are aliases pointing subdomains to other hostnames. A changed CNAME for app.example.com or api.example.com can silently redirect API traffic or break CDN routing. Subdomain takeover attacks often exploit stale CNAMEs pointing to deprovisioned services.
Mail exchange records control where inbound email is delivered. Unauthorized MX record changes are a serious security incident — they allow an attacker to intercept inbound email to your domain, including password reset messages and customer correspondence. MX changes are also a common source of email delivery failures after domain migrations that affect mail routing unexpectedly.
TXT records serve multiple purposes, but the most critical are email authentication records: SPF (which servers are authorized to send as your domain), DKIM (signing keys for message verification), and DMARC (policy for failed authentication). A change to your SPF record can cause your outbound email to be marked as spam by recipient servers. A deleted DKIM key breaks email signing validation. These changes are silent until someone notices increased bounce rates or spam classification.
Nameserver records define which DNS servers are authoritative for your domain. An unauthorized NS change is a complete domain hijack — whoever controls the nameservers controls all your DNS. NS changes at the registrar level are particularly dangerous and should be monitored with high-priority alerting.
An MX record that points to a non-existent server causes all inbound email to bounce. An SPF record that excludes your sending server causes outbound email to fail authentication at recipient servers — and with a strict DMARC policy, those messages are rejected or quarantined silently. You may not notice for days.
A changed A record takes your site offline for users whose resolvers pick up the new, wrong value. In a DNS hijacking attack, the change is deliberate — traffic is routed to a server the attacker controls, potentially intercepting credentials or serving malicious content while your real server appears healthy.
Attackers who successfully change your DNS records can serve a convincing copy of your site from a different server, capturing login credentials or payment information. Users see your domain in the address bar and have no indication anything is wrong. The attack persists until someone notices the DNS change and reverts it.
The simplest approach is querying your authoritative nameservers directly and comparing the output to a known-good baseline:
# Check current A record
dig A example.com @ns1.yourdns.com +short
# Check MX records
dig MX example.com @ns1.yourdns.com +short
# Check TXT records (SPF, DKIM, DMARC)
dig TXT example.com @ns1.yourdns.com
dig TXT _dmarc.example.com @ns1.yourdns.com
dig TXT selector1._domainkey.example.com @ns1.yourdns.comThis tells you what your authoritative server currently returns, but doesn't tell you what's propagated globally, doesn't run automatically, and requires you to have a baseline to compare against.
Effective DNS change monitoring requires a system that:
This approach catches both intentional changes that weren't communicated (a teammate updated an MX record without notifying the team) and unauthorized changes (a compromised DNS provider account making changes overnight).
Our free DNS checker shows you the current values for any record type across multiple resolvers worldwide — a useful starting point for establishing your baseline.
Open the free DNS checker →For production domains, manual checks aren't sufficient. DNS changes can happen at any time — a provider incident at 3 AM, an automation script triggered by a deployment, an attacker who gained access over the weekend. You need monitoring that runs continuously and alerts you within minutes of a change, not hours.
DNSWatch monitors your DNS records automatically — tracking A, CNAME, MX, TXT, and NS records, maintaining a baseline snapshot, and sending you an email alert the moment any record changes from its expected value. You configure which records to watch and what changes trigger an alert.
DNSWatch watches your DNS records continuously — A, CNAME, MX, TXT, NS — and alerts you by email the moment anything changes. Catch unauthorized edits, provider mistakes, and propagation issues before they become incidents.
Join the DNSWatch waitlist → Free DNS checker tool