Method
ThreatScope Check reads public domain-layer signals and presents a point-in-time view of a domain’s visible trust surface. It separates observed evidence from interpretation, and explains the limits of what can be concluded from public signals alone.
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.
Looks at public DNS signals such as name resolution, DNSSEC-related visibility and basic domain-layer configuration.
Looks at public mail authentication signals such as MX, SPF, DMARC and bounded DKIM selector observability where visible.
Looks at externally visible web delivery signals such as HTTPS availability, redirects and security headers.
Looks at the domain’s public certificate footprint, such as certificate visibility in public Certificate Transparency logs, observed issuers and issuance timing. When a certificate cannot be observed, that is reported as a source condition rather than a domain weakness.
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.
| Checked | Not checked |
|---|---|
|
|
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. Confidence and source diagnostics explain evidence completeness separately from posture status.
To keep this distinction clear, each surface records an evidence state:
An unavailable source is never treated as a negative signal about the domain. Surfaces that could not be observed are excluded from posture scoring rather than counted against the domain, unless there is a clear domain-side finding in its own right.
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.
The certificate surface is read from public Certificate Transparency logs rather than from a live TLS handshake, so it reflects what has been publicly logged rather than the exact certificate served at scan time. Where a certificate or registration record could not be observed, the result says so plainly and treats it as a limit of visibility, not as evidence of a problem.
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.
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.
Related: Changelog, Privacy notice, and Terms / acceptable use.
