Observed evidence
A public record or field collected directly.
Signals observed by .auDO
These pages define the public evidence .auDO observes or derives, what visible change may mean, and what cannot be concluded from it.
Use this library to interpret evidence definitions and limits. Current findings remain authoritative in State of .au, Cohorts and dated Reports.
Observed evidenceDerived postureEvidence context
How to read the library
Four kinds of evidence
Each label describes the nature of the evidence and how it was obtained or calculated. It is not a score or quality judgement.
Derived posture
A bounded classification calculated from observed public evidence.
Provider inference
A best-effort label inferred from visible infrastructure patterns.
Evidence context
Provenance, source and collection information that explains how evidence was obtained or preserved.
Signal library
Browse by family
Choose a domain-layer family to read its evidence definitions, possible meaning and interpretation limits.
Registration and RDAP
Public registration evidence together with the RDAP source context used to obtain it.
- RDAP source context Evidence context
- Registrar Observed evidence
- RDAP status Observed evidence
- RDAP redaction Observed evidence
DNS delegation and resolution
Direct public DNS records describing delegation, resolution destinations and general-purpose text evidence.
- Name servers Observed evidence
- Address records Observed evidence
- TXT records Observed evidence
Mail routing and authentication
Mail-routing evidence and derived authentication posture visible through public DNS.
- MX records Observed evidence
- DMARC posture Derived posture
- SPF presence Derived posture
DNSSEC
A combined DNSSEC posture reference supported by direct DNSKEY evidence and a source-specific RDAP assertion.
- DNSSEC posture Derived posture
- DNSKEY presence Observed evidence
- DNSSEC via RDAP Source-specific observed evidence
Provider inference
Best-effort classifications derived from visible name-server and mail-routing patterns.
- DNS provider Provider inference
- Inbound mail service association Provider inference
Supporting reference
Evidence and collection context
These pages explain source lineage, point-in-time metadata, preserved source material and fallback handling. They support trust in the evidence but are not peer domain-posture signals.
Evidence lineage
How an observation is dated, traced to source material and preserved for later inspection.
Source availability
How alternate public sources are used and disclosed when the preferred collection path is unavailable or incomplete.
Change-event classification
Signal tiers
Tiers classify observed change events. They are separate from the evidence-type labels used to organise this reference library.
Signal tiers are not risk scores. They help readers understand the kind of visible change preserved by .auDO.
Tier 1
High-signal trust posture change
Changes that may affect visible domain control, mail posture, DNSSEC posture or registration status.
Tier 2
Meaningful infrastructure movement
Visible infrastructure or provider movement that may reflect migration, consolidation or normal operational evolution.
Tier 3
Routine or low-confidence churn
Common, expected or low-confidence changes that are not meaningful without additional context.
Unclassified
Retained but not yet mapped
Observed event types preserved for future analysis but not yet explicitly classified.
Interpretation limits
What signals cannot establish
Public domain-layer observations describe visible evidence. They do not establish motive, impact, compliance, organisational quality or private operational state.
Visible is not complete
A public signal does not reveal every internal control, process or decision.
Change is not fault
A visible change may be administrative, defensive, accidental, routine or temporary.
Inference is not declaration
Provider labels describe best-effort visible patterns and do not prove a direct customer relationship or service quality.
Technical reference
Representative collected fields
Technical field names support traceability after the plain-language meaning of each signal is established.
registrar_name, registrar_handle, rdap_status, rdap_source, rdap_fallback_reason, rdap_redacted, nameservers, a_records, aaaa_records, mx_records, txt_records, dnssec_enabled, dnssec_enabled_rdap, dnskey_present, spf_present, dmarc_present, dns_provider, email_provider, rdap_raw, dns_raw, captured_at and run_id.
Use alongside
Move from definition to evidence
Use State for current aggregate posture, Reports for dated evidence, Explainers for deeper concepts and Methodology for collection and interpretation rules.