Method | ThreatScope Check

Why this matters

Digital trust is partly visible from the outside. Domains publish signals through DNS, mail, web delivery and registration infrastructure. Those signals do not tell the whole story, but they can help people ask better questions, confirm basic posture, and understand where follow-up may be needed.

ThreatScope Check makes those public signals easier to read without turning them into a score, audit or claim of safety.

How a check is produced

A domain is submitted.
ThreatScope Check performs live checks against public domain-layer signals.
Observed signals are interpreted through four assessment areas: DNS hygiene, email authenticity, web delivery and registration visibility. Certificate Transparency history is retained separately as supporting context.
The result separates evidence from interpretation and keeps unavailable collection context distinct from domain findings.
The result is presented as a point-in-time snapshot with limits and exact supporting evidence available for review.

Assessment areas and supporting context

DNS hygiene

Looks at public DNS signals such as name resolution, DNSSEC-related visibility and basic domain-layer configuration.

Email authenticity

Looks at public mail authentication signals such as MX, SPF, DMARC and bounded DKIM selector observability where visible.

Web delivery

Looks at externally visible web delivery signals such as HTTPS availability, redirects and security headers.

Registration visibility

Looks at publicly available registration or RDAP-style information where supported and visible. When registration data is not returned, that is reported as a source condition, not a negative signal about the domain.

Supporting context

Certificate Transparency history

Public Certificate Transparency evidence can show certificate-history context such as matching hostnames, observed issuers and issuance timing. It is retained as supporting evidence and does not independently lower the public posture or create a fifth peer assessment area.

Supporting context

Provider and service associations

Provider Resolution adds bounded provider and service associations to observed DNS hosting, inbound mail and literal SPF evidence. Associations remain supporting context: they do not change the public assessment or establish contracts, ownership or a complete service chain, and unresolved evidence remains visible.

The Provider Catalogue is the versioned public reference for released associations, inclusion standards, matching rules, source evidence and citation provenance.

Checked / not checked

Checked	Not checked
Public DNS records and resolution signals Public email authentication records where visible Public web delivery signals Public certificate-history signals from Certificate Transparency logs where available Public registration / RDAP-style visibility where supported	Internal systems or private controls Authenticated application areas Private technical control testing Malware or sender reputation classification Full content or application control review Legal, regulatory or contractual compliance Whether internal controls are effective

Evidence model

ThreatScope Check separates what was observed from what may be inferred. Evidence describes public signals that were visible at the time of the check. Interpretation helps explain why those signals may matter, but it should not be treated as a complete assessment of the domain or organisation.

The absence of a visible signal does not always mean misconfiguration, negligence or risk. Some signals may be unavailable, intentionally unpublished, temporarily unreachable, unsupported by the domain, or outside the scope of the check. Coverage and source diagnostics explain evidence completeness separately from posture.

To keep this distinction clear, each collection path records an evidence state:

Observed: The signal was returned and read successfully at check time.
Not observed: The source answered authoritatively that no such record exists.
Unavailable: The source could not be read at check time - for example because of a timeout, transport condition or non-standard response. This is a condition of the source, not a finding about the domain.
Not applicable: The signal does not apply to this domain or cannot be gathered in the current runtime, so it is noted rather than treated as posture evidence.
Error: The collection path failed in a way that is explicitly reported as collection context rather than converted into a domain finding.

Unavailable or failed collection is kept separate from negative findings and does not independently lower the public posture.

Result anatomy

At a glance: The bounded conclusion, attention state and evidence coverage for the point-in-time check.
What deserves attention: Assessment-driving findings that reasonably warrant review.
What was observed: The four stable public assessment areas and their bounded interpretation.
What could not be determined: Unavailable, not-applicable or error collection context, shown separately from domain findings.
Evidence: Collection states, exact supporting signal values and public sources behind the snapshot.
Method: How the four-area public method works and what constrains interpretation.
Export: A bounded plain-English summary and exact JSON response for the same point-in-time snapshot.

Limits

ThreatScope Check cannot tell you whether internal controls are effective, whether email is fully protected, whether a website has complete application coverage, whether a domain has harmful content, or whether a domain operator is compliant with any legal, regulatory or contractual requirement.

It can only describe selected public signals that were visible from the outside at the time of the check.

Certificate Transparency is read as supporting certificate-history context rather than from a live TLS handshake, so it reflects what has been publicly logged rather than the exact certificate served at check time. Where certificate or registration evidence cannot be observed, the result says so plainly and treats that as a limit of visibility rather than evidence of a problem.

.au and .auDO context

ThreatScope Check is built with .au context in mind, but it is not limited to .au domains. It provides a point-in-time reading of one domain’s visible public signals.

A single lookup shows a moment. Repeated observation shows behaviour.

Related work through .auDO observes public signals across a curated .au panel over time. ThreatScope Check does not use .auDO data to produce results, and a ThreatScope Check result should not be treated as longitudinal monitoring.

ThreatScope Check surfaces public domain-layer signals. It does not determine whether an organisation is well governed. For a practical governance conversation, the Domain Governance Baseline provides a separate self-assessment around ownership, accountability and visible public signals.

Visible trust surface

ThreatScope Check is aligned with a TrustSurface view of digital trust: it looks at the public signals a domain presents from the outside, separates evidence from interpretation, and explains the limits of what those signals can prove.

How ThreatScope Check produces a result