Define deployment as an observable DNS property
A DNS deployment study can establish that a particular record was observed at a particular owner name and time. It cannot, by itself, establish that every message from the organization authenticated, that receivers applied the same policy or that a business request was legitimate. The study should define its measured property before collecting data: record presence, syntactic validity, applicable policy discovery and operational message compliance are different outcomes.
RFC 1035 defines DNS message and record structures. RFC 9989 defines DMARC discovery and alignment behavior. These standards support a reproducible measurement method, not a claim that a scan was performed. This manuscript contains no domain observations, adoption percentages or inferred message results.
Choose the unit and population before querying
Specify whether the study counts registered domains, fully qualified names, sending identities or customer organizations. Those units are not interchangeable. One organization can operate many domains, while a domain can host several independent sending workflows. A list of website names is not automatically a list of domains that send mail. Record how the sample was selected and what the selection excludes.
Freeze the input list with a version identifier and a retained hash. Define handling for duplicates, internationalized names, trailing dots, aliases and changes in ownership or status. Do not silently remove difficult names after seeing their results. If the population is a convenience sample, describe it that way rather than presenting it as representative of all email domains. No population list was created or queried for this draft.
Distinguish exact-name observation from discovery
An exact TXT lookup answers a narrower question than determining an applicable DMARC policy. Under RFC 9989, the discovery process can involve a DNS Tree Walk. A method that queries only one expected owner name should label its outcome exact-name presence, not complete DMARC deployment. Retain the algorithm and standard version used so another analyst can understand what a negative result means.
SPF has its own identity and record-selection rules in RFC 7208. Looking for a policy at a website domain does not prove it is the MAIL FROM identity used by the organization's messages. A DNS-only study can describe publication at selected names, but it must not invent sending identities or substitute brand names for observed SMTP context.
Retain authoritative and recursive evidence separately
For each authorized observation, record the exact owner, type, class, server or resolver, time and response status. Authoritative answers describe the queried authority's response; recursive answers may reflect cached data and the resolver's own processing. If both are collected, preserve both rather than selecting the answer that fits the expected result. Their disagreement can be analytically important.
Document how authoritative servers are discovered and how the method handles inconsistent answers across them. Record any failures in the discovery path rather than labeling them absence of the final policy. A recursive TTL can reflect remaining cache lifetime, so it should not be reported as the original configured TTL without evidence. The study should preserve raw transcripts alongside normalized fields to support later review.
Preserve record boundaries and error categories
TXT RDATA can contain several character strings within one record. That differs from several TXT resource records at the same owner. A measurement parser should preserve those boundaries before applying protocol-specific selection. Unrelated TXT data can coexist with authentication records; it should not inflate a policy count or be merged into a valid-looking assertion.
Distinguish name error, a successful answer with no requested data, server failure, timeout, invalid syntax and ambiguous relevant records. These categories should not all become missing deployment. The result table should retain the original response and the rule used to assign a category. If the method retries, predefine the retry schedule and final classification so temporary failures are not handled differently depending on the desired result.
Keep DNSSEC evidence in its own field
RFC 4033 distinguishes secure, insecure, bogus and indeterminate validation states. A record can be present without a securely validated chain. A validation failure can also prevent a resolver from returning usable data. If the study measures DNSSEC, it must document trust-anchor and resolver context rather than assume any visible record is authenticated.
Do not make DNSSEC status a hidden exclusion that changes the sample denominator. Report how many names were assessed, which states were observed and which could not be determined, using actual evidence when collected. This draft contains no such counts. The point of the method is to preserve uncertainty, not to turn unavailable data into a convenient deployment result.
Separate publication from message-level compliance
A published SPF policy does not show which IP address submitted a real message. A DKIM key does not show that a provider signed a particular message or retained the corresponding private key securely. A DMARC policy does not demonstrate that every legitimate stream aligns. Those questions require operational evidence from the actual route and a trusted receiver.
RFC 8601 explains the trust boundary for Authentication-Results. A matching received-message sample can support a scoped message-level observation, but it does not automatically validate every domain or workflow in a DNS study. Keep publication metrics and message metrics as separate measures with their own populations and limitations. Do not relabel a DNS adoption percentage as compliance or protection achieved.
A reproducible observation worksheet
Create a worksheet with sample version, domain unit, normalized input, exact queried owner, record type, query method, observation time, authoritative transcript, recursive transcript and parser version. Add the assigned result category, applicable-policy discovery path, DNSSEC status where assessed and an explanation of errors. Retain a link to the raw evidence rather than only the final classification.
The analysis specification should state the numerator and denominator for each metric. Presence among all attempted names, validity among names with responses and applicable-policy coverage are different fractions. If several are useful, report them separately. Define exclusions before analysis and preserve an exclusion log with reasons. No original inputs, query transcripts or measurement results are supplied in this manuscript.
Fictional diagnosis: a deployment chart becomes a compliance claim
A fictional analyst queries a list of company website domains and finds policy-looking TXT data at some of them. A presentation labels the result email authentication compliance. The proposed review identifies two gaps: the sample does not establish the actual sending identities, and record presence does not establish message-level authentication. The chart should be renamed to describe the observed DNS property and its sample.
A later authorized study could add sender inventories and received-message evidence, but it would need a new metric definition rather than silently upgrading the original claim. This example contains no real domains, counts or scans. It illustrates a reporting error in a hypothetical method, not a finding about an organization or a completed deployment study.
Release the method with its evidence limits
A useful study conclusion states the population, observation dates, query algorithm, result categories and what the evidence cannot establish. It avoids claims about universal receiver behavior, inbox delivery or prevented fraud. A transparent DNS measurement remains valuable precisely because its scope is clear.
The catalogue requires timestamped authoritative and recursive answers with exact owner names and record types. Those original transcripts remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft is a proposed measurement method, not a performed scan or a message-compliance result.