Give each monitoring view a precise question
Domain-health monitoring and message-authentication monitoring answer related but different questions. The first can examine whether selected DNS dependencies exist, parse and remain consistent with an intended configuration. The second examines what happened when particular messages encountered particular receivers. Calling both views “email health” without defining their evidence makes a reassuring dashboard easy to misunderstand.
This is a proposed monitoring model, not an EmailAuth product demonstration. No domain was queried, no message or report was collected, and no monitor was deployed. The references were reviewed on 8 November 2026, including the May 2026 DMARC specifications. Actual provider support, evaluator versions, customer traffic and alerting behavior remain unverified.
Establish what a domain check can observe
A domain check can retain the exact queried name, record type, answer, collection time and resolution vantage. It may detect a missing policy, malformed syntax, an unexpected delegation or a change from an approved baseline. Its confidence depends on the collection method and completeness. A recursive answer may reflect caching; a provider's control-plane listing may reflect a pending configuration rather than current public publication.
For a concrete provider distinction, Route 53 says its list operation can return records pending distribution to DNS servers. Therefore an API inventory and an authoritative DNS observation should not be collapsed into a single timestamped fact. Use separate labels and preserve disagreement for investigation. RFC 1034 explains authority and caching, while the Route 53 API reference describes its control-plane behavior.
Domain checks also depend on supplied scope. A DKIM key lookup requires a selector; a portfolio scan that knows one selector cannot establish coverage of every application. A valid SPF record does not tell the monitor which server actually sent a message. The configuration view should state these limitations next to its result, rather than hiding them behind a healthy label.
Follow the actual message identities
SPF evaluates a sending host against an SMTP identity. DKIM verification evaluates a signature and its signing domain. DMARC then relates successful underlying authentication to the message's author domain. A valid-looking DNS setup does not force a sending application to choose the intended identity or attach the intended signature. RFC 7208, RFC 6376 and RFC 9989 describe these protocol roles.
Consider a fictional sender using an aligned envelope domain but transmitting from an IP that its SPF policy does not authorize. Suppose its DKIM signing is disabled. The domain's published SPF, DKIM key and DMARC records could all be syntactically valid, yet this message would have no aligned passing mechanism. This is an explanatory scenario, not a captured failure or a claim that a particular receiver rejected it.
The next evidence would be an authorized message sample and trusted receiver evaluation, paired with the relevant configuration observations and timestamps. An Authentication-Results header is meaningful only within an appropriate trust boundary. A sender can insert a similarly named header; merely finding the text does not authenticate the assertion. RFC 8601.
Use reports without pretending they cover everything
DMARC aggregate reports provide receiver observations over a reporting interval, including source information, message counts and authentication-related results. They can reveal a failing stream that a static record checker cannot see. They are not a continuous transcript of all mail, and an absent report is not evidence of zero traffic or universal success. Participation, report delivery and processing completeness all affect the observed population. RFC 9990.
Store the reporting organization, interval, arrival time and processing status separately. A late report can describe an earlier condition. A parser failure or stale ingestion job can make a monitoring gap look like an improvement if the dashboard merely removes missing data. Reconcile expected sources where possible, but avoid inventing an expected receiver population that the organization has never established.
Design alerts for distinct failure classes
A proposed configuration alert should say what changed, where it was observed and whether a retry confirmed the observation. A message alert should identify the affected stream and observed population, with enough identity context to distinguish authentication failure from an unrecognized but passing sender. A coverage alert should identify stale, missing or unprocessed evidence. These are separate operational decisions even if they appear in one report.
Set thresholds with the business owner. A small number of failing password-reset messages may matter more than a much larger low-value marketing stream. Record the denominator and time window behind every percentage. Do not present a green configuration score as a delivery guarantee, or interpret a passing DMARC result as proof of customer consent, message safety or inbox placement.
Correlate before changing anything
When views disagree, align their observation times and compare the actual author, envelope and signing identities. Check whether a sender changed, a selector rotated, a path modified signed content, or a resolver retained an older answer. Preserve competing explanations until the evidence separates them. The correct escalation may be to an application owner rather than the DNS operator.
For the fictional unsigned sender, adding another public key would not enable signing in the application. A proposed fix must target the verified cause and have its own approval, rollback criteria and post-change evidence. Neither a monitoring alert nor an analyst's hypothesis authorizes a DNS edit, credential action, external disclosure or test message.
Keep demonstration and release evidence separate
The exact catalogue gate remains open: Compare one healthy DNS configuration with a failing real sender and the evidence each view exposes. The fictional case above explains why that comparison matters but does not satisfy the word real. It would require a consented, safely handled operational example with correlated configuration and receiver evidence. No such evidence was obtained here. Human technical review, independent checking, current implementation validation and owner publication approval are still outstanding.