A government-domain study needs a defined population before it needs a pass-rate chart. A registered domain can serve a website, a retired programme or a non-sending purpose. Its presence in an official list is provenance, not evidence that every agency message uses that domain or authenticates successfully.
Choose and freeze the official frame
CISA’s dotgov-data repository distinguishes current-federal.csv, containing federal registrations, from current-full.csv, covering the broader .gov zone. Its README says the lists include second-level domains in Ready and On hold states, not every hostname; it also warns that registered domains need not offer an online service. Use those limits in the study title and inclusion rules. Federal is not automatically the same as executive branch.
For a real collection, retain the actual file bytes, source URL, retrieval time and content hash, plus any version identifier available. Do not merely record a link to a changing main-branch file. Keep the original fields and document normalization, duplicate handling and exclusions. No population snapshot or government DNS measurement is supplied by this article.
Fix selection before inspecting outcomes
Choose a census or declare the sampling rule, sample size and random seed or deterministic ordering before collecting results. A hand-picked pair of familiar names is an illustrative case study, not a representative sample. Looking up their registry membership afterward is post-selection corroboration, not evidence that they were sampled from the list.
Record agency, component and domain separately. Three domains owned by one agency are three domain observations but not three independent agencies. Preserve inactive, unresolved and excluded rows with reasons rather than quietly dropping them. Do not replace a failed observation with a more convenient successful domain.
Retain query evidence rather than a boolean badge
For each selected row, record the exact queried owner and type, resolver, UTC request time, response or transport error, DNS status, answer owner/type/data, relevant flags and TTL. Keep raw responses with the parser version and its normalization rules. A successful HTTP request alone does not establish a successful DNS answer. Google’s documented JSON API distinguishes Status, Answer and other response fields; DNS status and transport status belong in separate columns.
For a TXT answer, preserve character-string boundaries and reconstruct logical record content correctly. Do not mistake a CNAME target’s data for a direct answer without recording the chain. An exact _dmarc query is not a complete implementation of RFC 9989 policy discovery. If that is the research scope, label it exact-owner observation rather than effective policy for every subdomain.
Inspect a fictional three-row ledger
These reserved names and outcomes are stipulated for method illustration, not CISA list members or network observations. All rows use type TXT; resolver identity and collection timestamps are intentionally not supplied because no query was run.
- agency-a.example: proposed agency A, component Alpha, owner _dmarc.agency-a.example. Assume NOERROR with one TXT candidate v=DMARC1; p=reject. Classify a literal reject candidate, pending full syntax and discovery validation; do not infer compliance, sender coverage or receiver rejection.
- programme-a.example: proposed agency A, component Alpha, owner _dmarc.programme-a.example. Assume NOERROR with no relevant answer. Inspect CNAME/referral/authority context before classifying NODATA; do not assume no effective policy.
- agency-b.example: proposed agency B, component Beta, owner _dmarc.agency-b.example. Assume request timeout with no DNS response. Record unknown and the missing evidence; do not convert it to an absent or invalid policy.
The ledger has three domain rows and two proposed agency labels, but supplies no real denominator or adoption percentage. One literal reject candidate is not a measured government adoption rate. A real report must show selected, attempted, interpretable and unresolved counts separately, explain denominators and preserve errors.
Separate observable policy from operational outcomes
RFC 9989 describes policy syntax, discovery and receiver processing. A published preference does not force every receiver’s handling and does not show whether legitimate routes align. RFC 9990 describes separate message-derived aggregate evidence with its own reporting coverage. Neither a DNS snapshot nor an aggregate percentage proves every citizen received a notification.
Government mandates require separate authoritative applicability research. Do not translate registry membership, a reject tag or a successful parser into a legal-compliance badge. If a requested conclusion needs sender inventory or receiver evidence, state the gap rather than filling it with assumed success.
Define a reproducible release packet
Before publishing actual empirical findings, retain the frozen frame, precollection plan, exclusions, raw responses, normalized rows, parser version, error log, collection window and claim-to-row mapping. A new collection measures a new time window; it does not retroactively verify an unavailable historical run. Another reviewer should be able to trace every reported number to supplied evidence.
This article is a methodology and written example, not a report of collected government results. No DNS changes, live queries or email sends were performed for its hypothetical ledger. The original manuscript’s historical claims are not used as current evidence here.