Signal definitions
Each signal page explains what the field means, how .auDO observes it, and what it can and cannot show.
Signals observed by .auDO
Signals are the public domain-layer fields .auDO collects, stores, compares and reports on over time. They describe visible DNS, RDAP, mail, DNSSEC, provider and provenance evidence.
Signals are evidence of visible change. They are not conclusions about risk, intent, compromise, compliance or operational quality.
Public signals
Human-readable definitions
Tiered interpretation
How to use this library
Definitions first, interpretation second
Use this page to understand what .auDO observes, how signal changes are classified, and where the limits of public evidence sit.
Signal tiers
Tiers help readers understand the type of observed change without turning observations into scores or findings.
Evidence limits
Public signals can show visible posture and change. They cannot prove motive, impact, compromise or compliance.
Signal library
Observed signal families
The library is organised around the current snapshot model: registration, DNS, mail posture, DNSSEC, provider inference and collection provenance.
Registration and RDAP
Public registration-layer signals including registrar, RDAP status, domain dates and redaction indicators.
DNS delegation and resolution
Visible DNS records used to understand delegation, resolution and routing posture.
Mail posture
Public email authentication and mail-routing signals visible through DNS records and provider inference.
DNSSEC
Signals that indicate visible DNSSEC posture through DNS and RDAP-derived evidence.
Provider inference
Visible infrastructure patterns inferred from public DNS and mail configuration.
Provenance and evidence
Signals that describe how observations were collected, preserved and traced back to source evidence.
Canonical definitions
Signal tiers
Signal tiers are the human-readable classification used by .auDO to describe different kinds of observed change.
Signal tiers are not risk scores. They do not prove impact, compromise, negligence, compliance failure or organisational intent. They help readers understand the type of visible change being preserved.
Tier 1
High-signal trust posture change
Changes that may affect visible domain control, mail posture, DNSSEC posture, registration status or other public trust signals. These changes are more likely to warrant human review, but they are not evidence of compromise on their own.
Examples: registrar changed; RDAP status changed; DNSSEC state changed; DMARC state changed; name server set changed materially.
Tier 2
Meaningful infrastructure movement
Changes that suggest visible infrastructure or provider movement. These may indicate migrations, supplier changes, platform consolidation, operational maintenance or normal infrastructure evolution.
Examples: DNS provider changed; email provider changed; MX records changed; A or AAAA records changed to a different provider pattern.
Tier 3
Routine or low-confidence churn
Changes that are common, expected, low confidence, or not meaningful without additional context.
Examples: individual IP changes; TXT verification token changes; repeated cloud infrastructure churn; minor record ordering changes.
Unclassified
Retained but not yet mapped
Observed event types that are preserved but not yet explicitly classified. These remain available for future analysis as the observatory matures.
Interpretation limits
What signals cannot prove
Public domain-layer observations cannot prove motive, impact, compromise, compliance, negligence or private operational state.
Visible is not complete
A public signal shows what can be observed externally. It does not reveal every internal control, process or decision.
Change is not fault
A visible change may be administrative, defensive, accidental, routine, temporary or otherwise benign.
Providers are context
Provider names describe visible infrastructure patterns only. They do not imply endorsement, fault, quality or a direct customer relationship.
Technical reference
Representative collected fields
These are representative snapshot fields used by .auDO’s current public observation model.
registrar_name, registrar_handle, rdap_status,
rdap_source, rdap_authoritative_reason, rdap_fallback_reason,
rdap_ldh_name, rdap_unicode_name, rdap_handle,
rdap_conformance, created_at_domain, expires_at_domain,
last_changed_at_domain, 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.
.auDO currently treats hosting provider and ASN language as adjacent or historical reporting context unless a report artefact explicitly contains that evidence. They are not presented here as first-class snapshot signal families.
Use alongside
Signals explain the evidence
Use Signals for field-level meaning, State pages for aggregate posture, Reports for dated evidence, and Method for collection limits.