Report what was observed before calling it healthy
A DMARC checker can observe DNS policy information and evaluate parts of its syntax or discovery behavior. That does not establish that every legitimate sending service authenticates correctly, that all receivers apply the same implementation or that a particular message reached an inbox. A useful checker output should identify its exact inputs, resolver context, observation time, discovery method and limitations before presenting a conclusion.
RFC 9989 defines the current DMARC mechanism, including policy discovery and alignment. This article describes proposed evidence requirements for a checker; it does not claim that EmailAuth implements them or that any domain was scanned. No authoritative or recursive query for a user domain was performed, and no received-message sample was collected.
Distinguish an exact lookup from policy discovery
A query for a particular _dmarc owner name is an observation at that name. Determining the applicable policy can require the current standard's discovery process, including its DNS Tree Walk rules. The checker should state whether it merely displays an exact TXT answer or implements a defined discovery algorithm. It should not call a missing record at one name proof that no applicable policy exists without evaluating the relevant scope.
Record each owner name, query type, response and branch used by the implemented discovery process. The output should distinguish a valid policy, no applicable policy, an invalid candidate and a DNS error according to the supported algorithm. Do not invent a shortcut based only on a familiar organizational-domain list while claiming current-standard behavior. The product version and standards reference should be retained alongside the result.
Preserve authoritative and recursive perspectives
An authoritative answer and a recursive resolver answer can differ because of caching, delegation state, timing or resolution failure. Record which server or resolver supplied each answer and when it was collected. A dashboard should not merge them into one apparently timeless value. If a checker offers only recursive evidence, say so rather than implying that the authoritative configuration was independently verified.
RFC 1035 defines DNS message and resource-record structures, including TXT records. Preserve response codes and record structure rather than displaying only a flattened policy string. Multiple character strings within one TXT record are not the same as multiple TXT records. That distinction matters when determining whether the answer contains competing DMARC policy records or merely one record represented in several strings.
Interpret syntax with the current standard
RFC 9989 specifies DMARC1 as the case-sensitive version value and requires the version tag in the defined position. A checker should identify the exact reason a candidate is not a valid policy rather than replacing every problem with a generic red warning. It should also distinguish duplicate policy candidates from unrelated TXT data. The applicable discovery procedure determines how candidate records are selected and handled.
Unknown tags are not automatically a fatal policy error: the RFC's formal definition says unknown tags must be ignored. A checker may still warn that a tag is unsupported by its own parser or absent from the current registry, but it should not confuse that warning with a normative rejection rule. Conversely, a recognized tag with a problematic value needs the relevant standard's handling, not an invented universal response to all syntax errors.
State implementation and compatibility limits
The current RFC removes pct and introduces the testing tag t, as explained in Appendix A.6. A checker should identify which standard and tag registry its interpretation follows and avoid implying that every external receiver behaves identically. It should not suggest a mechanical migration from arbitrary historical percentages without a readiness review. Provider-specific eligibility rules may need separate current documentation.
A syntactically acceptable DNS policy is still only one part of the operational picture. The checker has not established the list of legitimate senders, their alignment or the effect of a policy change. Keep recommendations conditional on those missing inputs. A policy that requests enforcement can be correctly published while legitimate workflows remain misconfigured; a DNS checker alone cannot certify that enforcement is safe for the business.
Connect DNS evidence to a trusted message sample
RFC 8601 explains the trust boundary for Authentication-Results fields. A received-message sample should identify the receiver that produced the result and preserve the relevant visible, envelope and signing identities. A copied line containing pass is not enough to establish that the intended receiver evaluated the actual workflow. The sample should be authorized and redacted without destroying the domain relationships needed for analysis.
Compare the sample time and identities with the DNS observations, but do not pretend one sample covers every sender or receiver. A policy may have changed between sending and checking, and recursive caches may reflect different states. State what the sample demonstrates and what remains unknown. This article has no message sample and makes no claim that a real policy matched a real received result.
A checker-output acceptance worksheet
Create a worksheet with queried domain, exact owner names, resolver or authoritative source, timestamps, response codes, retained transcripts and candidate record structure. Add the implemented discovery algorithm, parser version, selected policy, warnings and explicit uncertainty. The message section should record the authorized workflow, trusted receiver, relevant identities, observed result and linkage limitations.
Use proposed fixtures for a valid policy, missing exact-name record with applicable higher-level discovery, duplicate candidates, unsupported tags and unavailable DNS. Separate normative expected behavior from product-specific presentation. A test should verify the retained evidence and explanation, not just a green icon. No fixture was executed here, and no real DNS answer is represented by the examples.
Fictional diagnosis: a green record with a failing sender
A fictional team sees a checker display a valid enforcement policy and concludes that its invoice service is ready. An authorized received-message sample, if later collected, might show that the service uses a nonaligned path. The DNS observation and message failure would not contradict each other: one describes publication, while the other describes a sending workflow.
The proposed investigation would preserve both observations, identify the workflow owner and review the intended aligned path before changing policy or adding authorizations. It would not declare the domain safe merely because the record parses. This is a fictional exercise, not a real invoice-service failure, DNS scan or receiver result. Its purpose is to keep the checker's evidence boundary visible.
Keep the final conclusion proportional
A useful checker conclusion can say that a specific policy was observed and interpreted under a specified algorithm at a stated time. It should not promise universal delivery, complete receiver adoption or protection against all impersonation. The output is strongest when it makes missing operational evidence easy to see.
The catalogue requires authoritative and recursive lookup transcripts, timestamps and a matching received-message sample. Those original artifacts remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies a proposed evidence model, not executed scans or verified EmailAuth checker capabilities.