A DNS monitor that checks only whether the domain resolves can miss a deleted DKIM selector or a broken SPF dependency. Start from the records that real mail paths use. Availability monitoring should report what was queried, from where, and which expected property failed, not simply that DNS is unhealthy.
Build an explicit target inventory
References: RFC 6376 §3.1, RFC 7208 §4.4.
List the author domains, envelope domains, active selectors and policy names used by each sending service. Include dependencies reached through aliases and SPF mechanisms. Add transport-policy names when monitoring receiving security. Ordinary DNS queries cannot discover every selector, so obtain the active set from service configuration and representative signed messages.
For each target, record owner, type, expected shape or approved value, accountable owner and change window. Avoid assuming every value must remain byte-identical forever: a planned key rotation changes data legitimately. Version expected values and distinguish an unapproved change from an approved transition.
Probe authority and recursion separately
References: RFC 1035 §4.1.1, RFC 2308 §2.2, RFC 4035 §5.5.
A direct authoritative query helps establish what the zone serves. A recursive query represents one resolver's effective view, including caches and validation behavior. Retain query time, server address, response code, flags, answer records and TTL context for both. Use multiple relevant vantage points where the service requires them, without claiming that a few probes cover every receiver.
Distinguish NXDOMAIN, an existing name with no requested type, SERVFAIL, timeout and a successful but incorrect answer. A DNSSEC problem can yield failure at a validating resolver even when an authoritative server returns the record. An authoritative-answer flag is not evidence that the answer was cryptographically validated.
Alert on the decision that follows
A missing active selector needs a different response from a brief timeout at one monitor. Group related dependency failures so one unavailable authority does not create hundreds of unrelated tickets. Use consecutive observations and independent paths to reduce noise, while preserving the first-failure time and raw results. Thresholds are local operational choices, not universal DNS protocol requirements.
Do not automatically replace records or disable enforcement merely because a probe fails. First determine whether the monitor queried the correct name and current authority. Route the finding to the record owner with the affected service, last good observation and evidence of the exact change or response condition.
Reproduce three distinct observations
The local fixture classifies an expected selector marker returned with NOERROR as present, an NXDOMAIN response as name missing, and a SERVFAIL response as resolution failure. It then shows that NOERROR with a different marker is a content mismatch rather than an outage. The markers are synthetic and are not DKIM keys.
Run the included script to reproduce the classification. It consumes fixture objects rather than sending packets. To validate a deployed monitor, query an isolated authorized zone with the same cases and retain actual wire responses, timeout measurements and alert delivery evidence. Those live tests were not performed here.
Close the monitoring loop
References: RFC 2308 §5, RFC 6376 §6.
After repair, compare every tested authoritative endpoint, then observe recursive recovery and a representative message when authorized. Negative answers may remain cached after the record returns. Do not erase the incident merely because one later lookup succeeds.
Review the inventory after sender onboarding, selector rotation, domain migration and retirement. DNS observations establish prerequisite availability at a point in time. They cannot alone demonstrate a valid DKIM signature, DMARC alignment, mailbox acceptance or inbox placement.
Retained historical wire evidence
The following describes the retained 7 November 2026 loopback capture, inspected but not rerun as a network experiment for this review. New offline model checks are recorded separately.
The retained wire capture records actual UDP questions to a minimal loopback authority. It retains owner, type, endpoint, UTC observation time, query and response bytes, flags, TTL and SOA context. The resulting branches are: NOERROR with expected TXT means present; NOERROR with no AAAA at the existing apex means no requested data; NXDOMAIN for absent.example.test means name missing; SERVFAIL means resolution failure; an intentionally unanswered question produces a client timeout. The server scripts these responses, but the packets and timeout are actually observed. This tests the decision tree, not commercial monitor behavior or alert delivery.