Method reference

Provider Catalogue

A versioned reference of documented infrastructure associations maintained by ThreatScope Check. Provider Resolution uses these associations to interpret selected DNS hosting, inbound mail and SPF observations while preserving the underlying evidence and limits of attribution.

What this catalogue is

The Provider Catalogue connects selected observable infrastructure values with documented provider and service associations. Released rules are used by Provider Resolution to interpret authoritative or managed DNS, inbound mail routes and gateways, and literal SPF service references.

An association means that an observed value matches a governed, evidence-backed infrastructure pattern for the stated role. It does not by itself establish a commercial relationship, ownership, registrar, website host, mailbox backend, active mail flow or complete service chain.

Current release

—Catalogue version

—Provider identities

—Active rules

—Supported association roles

— active evidence-backed patterns · Schema version — · Maintained by ThreatScope Check · Rule-level source provenance and evidence review dates are retained with the catalogue.

Find a published provider or service, inspect its evidence and share a correction.

Released provider reference

This reference lists provider identities represented by the current catalogue release and the observable roles and services supported by active rules. It is not an exhaustive vendor directory and does not imply that every product, region, reseller configuration or endpoint operated by a provider is recognised.

Find a provider, service or recognised pattern

Loading providers…

Provider	Observable roles	Recognised services	Rules

Found a missing or incorrect association?

You can submit provider documentation or other public evidence for review. A submission is correspondence, not an accepted catalogue change: ThreatScope Check applies the same evidence and release process before any association becomes part of Provider Resolution.

Submit Provider Catalogue evidence or a correction

Learn how observed patterns become bounded, evidence-backed associations.

How to interpret an association

—

DNS hosting

Recognises authoritative or managed DNS infrastructure from nameserver values. It does not establish who registered the domain or where its website is hosted.

—

Inbound mail route

Recognises an MX routing destination or email-security gateway. It does not necessarily identify the mailbox provider, customer relationship or complete mail path.

—

SPF reference

Recognises a literal service reference in a published SPF policy. It does not prove active sending, effective authorisation or DMARC alignment.

Provider Resolution is role-bound and intentionally selective. Released rules use exact hostnames or bounded hostname suffixes. Evidence that does not support a released association remains unresolved rather than being converted into a provider label.

What qualifies for inclusion

Provider associations are not released from hostname resemblance, provider familiarity or repeated observation alone. A released rule requires evidence that identifies the relevant provider or operator, establishes the service role, supports the observable matching boundary and provides sufficient context to avoid misleading attribution.

Catalogue schema v2 makes the evidence basis explicit. Most rules use provider-published technical patterns. Where a rule is supported by retained direct provider operational instruction, the linked public source independently corroborates the service but may not document the exact endpoint. The Registry retains the direct instruction; it is not reproduced publicly.

Evidence that materially suggests an association but does not yet satisfy the release standard remains outside ordinary Provider Resolution until the remaining evidentiary gap is resolved.

Versioning and corrections

The catalogue is maintained as a versioned reference because provider endpoints, product names and published configuration guidance change. Each rule retains source provenance, rationale, status and an evidence review date. Entries may be revised, added, suppressed or removed through a catalogue release.

A provider association should not be the sole basis for a security, legal, commercial or attribution decision. Unknown, custom, white-label and insufficiently documented patterns remain unresolved rather than being forced into a provider label. Public evidence and corrections can be submitted for review before any governed catalogue decision is made.

Adopt a pinned release in your own service and preserve its provenance.

Use the Provider Catalogue in your own service

The Provider Catalogue is available as a versioned, machine-readable release. You can use the same documented DNS hosting, inbound mail and SPF provider associations used by ThreatScope Check in another application, internal tool or research workflow.

Current machine-readable release

Provider Catalogue 1.6.0

Start with the release descriptor. It identifies the catalogue data, schemas, integrity hashes and conformance material that make up this version.

Start with the 1.6.0 release descriptor Inspect the 1.6.0 catalogue data

Discover available releases. Read /provider-catalogue/releases/index.json to see the current release, prior releases and their Catalogue schema, Provider Resolution and Consumer Contract identities.
Select and pin a release deliberately. Fetch that immutable version's release.json; do not treat discovery as automatic adoption.
Verify before use. Follow only the relative paths declared by release.json, verify the supplied schemas and SHA-256 values, then run the conformance vectors and released rule fixtures.
Use it with your own observations. Apply Provider Resolution to DNS hosting, inbound mail and literal SPF values collected by your service.
Preserve provenance. Keep the Catalogue version and SHA-256 with derived results so the association can be reproduced later.
Check for newer releases separately. Re-read the discovery index when appropriate, test the new immutable release and adopt it only when your service is ready.

No live ThreatScope dependency is required. Consumers do not need a ThreatScope Check account, Provider Registry access, D1 access or the public Check API. The discovery index is mutable release metadata only; immutable versioned bundles remain the adoption and reproducibility boundary.

Implementation details

Consumer contract: provider-catalogue-consumer-v1. Provider Resolution: provider-resolution-v1.

index.json is the release-discovery document. release.json remains the interoperability entry point for the version you choose to adopt. It binds the Catalogue version to catalogue.json, its structural schema and SHA-256 identity, plus the language-neutral conformance vectors and their schema.

For example, inspect discovery with curl -fsS https://threatscopecheck.com/provider-catalogue/releases/index.json, then fetch a pinned descriptor such as curl -fsS https://threatscopecheck.com/provider-catalogue/releases/1.6.0/release.json.

A consumer may retrieve, cache, vendor or mirror released artefacts and implement the matching behaviour independently. Preserve the Catalogue version and provenance, identify ThreatScope Check as the source when citing the Catalogue publicly, do not imply endorsement or partnership, and preserve the role-bound interpretation limits. The Terms / acceptable use remain the normative reuse conditions.

The published conformance vectors and each released rule's positive and negative fixtures are provided to verify compatible behaviour.

Release provenance and citation

Provider Catalogue releases are versioned so that provider associations can be traced to the rules and evidence in use at a particular point in time.

Catalogue version: —
Provider Resolution: —
Consumer contract: provider-catalogue-consumer-v1
Schema version: —
Catalogue SHA-256: —

Suggested citation

ThreatScope Check. Provider Catalogue, version —. ThreatScope Check Provider Resolution. https://threatscopecheck.com/method/provider-catalogue/

For technical reproducibility, record the catalogue version and SHA-256 above with the citation.