How to monitor DNS records and catch changes you did not make
Check the records your site and mail depend on against the values you expect, and hear about a change you did not make before your customers do.
Catch silent failures · 4 min read · Updated Oct 12, 2026
DNS is the part of a site nobody looks at until it breaks. A domain renewal fails and the registrar swaps in its own nameservers. Someone tidying up the DNS zone deletes a record they did not recognise, and mail starts bouncing. A migration to a new provider copies every record except one.
Nothing was deployed, so nobody is watching. And because DNS answers are cached, an uptime check can stay green for hours after the record has gone.
How it works
A DNS check asks a nameserver for one record, such as the A record of example.com, and compares the answer with the values you said it should have. While they match, nothing happens. When they stop matching, you are told.
It does not care why the record changed. A lapsed domain, a mistake and an attack all look the same from outside: the answer is not what it was.
Step 1: Decide which records matter
You do not need every record. These are the ones whose loss hurts:
| Record | What breaks without it |
|---|---|
NS for the domain | Everything. A change here means someone else answers for your domain. |
A, AAAA or CNAME for the site | The site is unreachable, or points at someone else's server. |
MX for the domain | Incoming mail is lost or bounced. Nobody notices for days. |
TXT for SPF and DMARC | Your outgoing mail starts landing in spam. |
Where to start. NS and MX. They change least often, so an alert almost always means something is wrong.
Step 2: Write down the healthy answer
Read the current values with dig, and keep them somewhere the team can find:
dig +short NS example.com
dig +short A example.com
dig +short MX example.com
dig +short TXT _dmarc.example.com
Three things make an expected answer hold up over time:
- Expect what must be there, not everything that is. If a check passes while your values are among the answers, an extra record added later does not set it off.
- Do not pin addresses that rotate. A site behind a CDN answers with different addresses from hour to hour. Watch its
CNAMEor the domain'sNSrecords, which stay put. - Match whole values. A check on part of an SPF record tells you little. The whole record is the value.
Step 3: Choose where to ask
The same question gets different answers depending on who is asked.
A public resolver, such as 1.1.1.1 or 8.8.8.8, answers the way it does for your visitors. It caches, so it reports a change only after the record's TTL has run out. Your DNS provider's own nameserver answers from the source: it reports a changed or deleted record at once, but cannot see a problem at the registrar.
For the records that matter most, one check of each kind covers both.
Step 4: Test it
- Create a second check for the same record with an expected answer that is wrong, such as
203.0.113.10for anArecord. - It should fail and say the record did not match, and the failure should reach a person.
- Remove it.
Then put a line in whatever you use to plan DNS changes: update the check when you change the record. Otherwise the first planned change produces an alert, and the team learns to ignore it.
Common mistakes
- Watching only the website's record. Mail and nameserver records fail more quietly and do more damage.
- Expecting an instant alert from a public resolver. It serves its cached answer until the TTL runs out.
- Listing every address of a site behind a CDN. The check fails each time they rotate.
- Forgetting the registrar. A domain that lapses takes every record with it. Turn on auto-renewal, and watch
NSin case it fails anyway. - Nobody owning DNS. If no one is named, no one notices. Write down who it is.
Doing this in saysOK
A DNS monitor asks for one record: you choose the type (A, AAAA, CNAME, MX, TXT or NS), the name, and the resolver, which is 1.1.1.1 unless you enter an address or a nameserver's host name. In Expected answer you list the values, separated by commas.
The check passes while every value you list is among the answers. Each must equal a whole answer, and upper and lower case are treated the same. For MX records, list the mail server names without the priority number.
Enter values plainly, not as dig prints them: host names without the final dot, and TXT values without the quotation marks. Because commas separate the values, a TXT value that itself contains a comma cannot be listed.
A failing DNS monitor alerts through any rule with the condition Monitor goes down. If you only want the nameservers watched, Add from a domain proposes that check with the current nameservers already filled in.
DNS checks are not in every plan; see pricing.
Next
Certificates fail the same quiet way: see how to get alerted before an SSL certificate expires. If you look after domains for clients, see how to monitor client websites as an agency.
Set this up in saysOK
Start on the free plan. The guide says where a step needs a paid one.