DNS checks

The DNS check queries your domain's full record set every hour by default and compares the result to the previous snapshot. If any record changes, disappears, or indicates a mail deliverability problem, DomainCare fires an alert. You get signal on real changes, not noise from transient resolver hiccups.

What it monitors

• A / AAAA records — IPv4 and IPv6 addresses the domain resolves to, plus their TTL values
• CNAME records — canonical name targets
• MX records — mail exchanger hostnames and priorities
• TXT records — the full set of TXT strings (includes SPF, verification tokens, etc.)
• NS records — nameserver hostnames reported by the zone (recorded and shown in the check detail; change alerts for nameservers come from the Nameserver check)
• SOA record — primary nameserver (nsname) and serial number
• CAA records — certificate authority authorization entries (issue, issuewild, iodef)
• PTR / reverse DNS — reverse DNS names for the first five resolved IPs
• MX PTR (FCrDNS) — forward-confirmed reverse DNS check on the primary MX host

How often it runs

The DNS check runs every 1 hour (3,600 seconds) by default. Paid plans can override this to a faster interval per domain via per-check controls. The MX PTR check is included in every run; it resolves every IP address of the primary MX exchange and verifies that at least one of them has a PTR (reverse DNS) name matching the exchange — so mail hosts that round-robin across several addresses aren't flagged when one of them confirms.

Check status. The check is failing (red) only when the zone itself doesn't resolve (no A, AAAA, or CNAME records). Missing MX records show needs attention (amber): the domain works, but mail delivery is broken. Missing CAA records and MX reverse-DNS issues (a primary MX without a PTR record, or a forward-confirmed reverse DNS mismatch) are informational: the warning text stays visible on the check detail page and the events still fire, but they don't turn the check or the domain amber. Subdomains aren't flagged for missing MX/CAA.

Why your IPs change but you don't get paged

Sites on CDN and serverless platforms (Vercel, Cloudflare, AWS CloudFront, Fastly, Netlify, …) answer DNS from anycast pools and rotate which A/AAAA addresses they return per query — with no real configuration change. DomainCare suppresses that noise two ways:

• CNAME anchoring. When your domain points at a managed platform via CNAME (e.g. cname.vercel-dns.com) and that CNAME target is unchanged, the CNAME is treated as the stable identity. The rotating IPs underneath it are ignored — dns_records_changed and resolved_ip_changed do not fire.
• Confirmation (hysteresis). For apex domains pointing straight at platform IPs (no CNAME to anchor on), an A/AAAA change is only reported once the new address set has held steady across two consecutive checks and differs from the prior baseline. A set that keeps rotating never stabilises, so it stays quiet; a genuine migration confirms on the next check. CNAME changes are not subject to this delay — a change there is high-signal (takeover risk) and alerts immediately. Nameserver changes are monitored by the Nameserver check, not this one.

Alerts this check produces

Event	Tone	When it fires
dns_records_changed	Warning	CNAME records changed (immediately), or an A/AAAA set change was confirmed across two consecutive checks. Anycast/CDN rotation under an unchanged managed CNAME is suppressed. Nameserver changes are reported by the Nameserver check, not this event
cname_records_changed	Warning	CNAME target changed
mx_records_missing	Failure	All MX records disappeared (no mail exchangers found)
mx_records_changed	Warning	MX records changed (different exchangers or priorities)
mx_recovered	Recovery	MX records are present again after a mx_records_missing event
txt_records_changed	Warning	TXT record set changed
resolved_ip_changed	Warning	The IP addresses the domain resolves to changed and the new set held steady across two consecutive checks (anycast/CDN rotation is suppressed)
caa_records_changed	Warning	CAA record set changed
caa_records_missing	Warning	No CAA records found for the apex domain — fires on the first scan (baseline) as well as on a regression from a previously-present set
caa_recovered	Recovery	CAA records are present again after a caa_records_missing event
soa_primary_ns_changed	Warning	The SOA nsname (primary nameserver) changed and the new value held steady across two consecutive checks (per-query SOA variance is ignored; trailing-dot/case differences don't count)
mx_ptr_mismatch	Warning	No resolved IP of the primary MX has a PTR name matching the hostname (FCrDNS failed), confirmed across two consecutive checks. Informational severity — weekly digest, no immediate alert
mx_ptr_missing	Warning	Primary MX host resolved but none of its IPs have a PTR record, confirmed across two consecutive checks. Informational severity
mx_ptr_recovered	Recovery	MX PTR is correct again (held for two consecutive checks) after a mismatch or missing event
dns_ttl_dropped_low	Info	A record TTL dropped below the low-TTL threshold (signals upcoming change or misconfiguration)

What to do when alerts fire

• dns_records_changed / resolved_ip_changed — because these only fire on a confirmed, sustained change (not transient CDN rotation), treat them as real. Verify the change was intentional (deployment, CDN migration, DNS provider change). If you did not make the change, check your DNS provider for unauthorized edits and rotate any API keys that have write access.
• mx_records_missing / mx_records_changed — missing or changed MX records will interrupt email delivery immediately. Restore the correct MX records and confirm with a live mail test.
• caa_records_missing — without CAA records any CA can issue certificates for your domain. Add a CAA record that restricts issuance to your CA of choice (e.g. 0 issue "letsencrypt.org").
• mx_ptr_mismatch / mx_ptr_missing — many spam filters reject mail from servers without matching FCrDNS. Ask your mail host or hosting provider to set a PTR record for the mail server IP that matches the MX hostname. (Reverse-DNS lookups are flaky by nature; DomainCare ignores transient PTR timeouts/SERVFAIL — these alerts fire only on a determinable, sustained mismatch or missing PTR, not on a momentary lookup failure.)
• dns_ttl_dropped_low — a TTL under 300 seconds suggests a DNS change is in progress. Normal after intentional migrations; investigate if unexpected.

Related

• Email deliverability — SPF and DMARC depend on correct TXT and MX records
• Nameserver checks — monitors authority and NS record validity
• Alert reference