What does a DNS monitor check?
A DNS monitor resolves one hostname for one record type and compares the answer against the value you stored. It supports A, AAAA, CNAME, MX, TXT and NS records. If the record disappears, changes to something you did not expect, or stops resolving, the check fails.
Leave the expected value blank to check for presence only — that the record exists and resolves at all. Fill it in to check for drift, which is what you want on anything a third party can edit: an MX record a mail vendor manages, a TXT record holding a domain-verification token, a CNAME pointing at a CDN.
What should I actually monitor?
The records whose loss is silent. A broken A record announces itself within minutes because the site goes down. A deleted SPF or DKIM TXT record does not: mail keeps sending and quietly starts landing in spam, and you find out weeks later from a customer who never got an invoice.
A practical starting set for one domain: the apex A record, the www CNAME, the MX records, the SPF TXT record, the DKIM selector TXT record, and the NS records. The last one catches delegation changes, which is the failure mode of a domain transfer going wrong.
How does a TCP check differ from an HTTP check?
A TCP check opens a socket to a host and port and reports whether the connection was accepted. It says nothing about what is listening there or whether it works. That is the point: it separates "the network path and the process are up" from "the application is behaving", which is exactly the distinction you want at 3am.
Use it for services that do not speak HTTP — a database port you expose to a partner, an SMTP relay, an SSH bastion — and for confirming that a firewall change did what you intended. For anything that does speak HTTP, an HTTP check tells you strictly more.
443 HTTPS terminator up but app broken → pair with an HTTP check
25 SMTP relay reachable → mail delivery path intact
22 SSH bastion reachable → your own break-glass access still works
3306 MySQL exposed → usually a mistake; monitor it to prove it is closedWhy did my DNS check fail when the site is clearly up?
Almost always one of three things. The record has more than one valid answer and your expected value names only one of them — round-robin A records and multi-vendor MX setups both do this, and the fix is to check for presence rather than an exact value. The record legitimately changed and nobody updated the monitor. Or the resolver we used got a stale cached answer, which resolves itself on the next run.
DNS checks run from our infrastructure using our resolvers. A result describes what a resolver on the public internet sees, not what your internal split-horizon DNS serves inside your network.