Non-intrusive external scanning
Understand what was observed, when, and what it means
Use this guide to assess a report's scope, evidence and limitations. It explains visible results through a fictional example and shows how to read the populations and dates behind our sector studies.
The short version.
Our scans use bounded, external, non-intrusive checks. They do not attempt exploitation, credential testing or intentional modification of target systems. Checks combine public records, external intelligence and bounded connections to public-facing services. Missing evidence remains explicit.
One rule decides what is in a scan and what is not.
Every MyDomainRisk check is a non-intrusive external observation. We look at what a domain already shows to the public internet — its DNS records, its certificates, the headers its website sends, what public threat-intelligence sources say about it. Website protocol checks complete a small, bounded set of TLS handshakes without sending application data. They do not enumerate ciphers or attempt exploitation. Collection records for DNSSEC, disclosure files and cloud storage distinguish completed, incomplete and unavailable checks; completed collection is not a security pass. Historical reports retain their original evidence. RPKI routing intelligence is currently unavailable. Published vulnerability intelligence adds context without sending additional probes to the target.
A domain assessment describes the selected domain and the public-facing evidence available to the checks performed. It does not inventory every system an organisation uses. One domain can serve several sites or organisations, and one organisation can use several domains.
A homepage check, a full security scan and scheduled daily monitoring have different coverage. Read the report's assessed domain, scan date, findings and evidence availability. Plan-specific checks are described below; a shorter assessment should not be treated as a complete inventory.
Security results describe observable technical posture. Authenticity results address signs of deception or suspicious identity. A well-configured domain can still be deceptive, and a genuine organisation can have configuration weaknesses.
Bounded checks read public DNS records, website responses and advertised services. A response supports what was observable at the time; it does not establish the state of internal systems.
Published and commercial intelligence adds context about threats, services, certificates and identity exposure. Its observation can predate the scan. Read the source's retained date where it is available.
A dated retained copy may be used when fresh evidence is unavailable. Opening a report does not make that evidence new. An unrecorded observation date remains unrecorded.
The scan date, an intelligence observation date and a delayed check's completion date describe different events. A later addition expands the available evidence; it does not by itself prove that a risk appeared later or that a previous problem was repaired.
The available evidence supports the stated check. It applies to that check and its observation date; it does not certify the organisation.
The report retains an observed issue. Read the evidence and applicability limits, then validate the finding with its technical owner.
The report identifies a measure whose relevance depends on the domain's use. Review that context before deciding on a change.
The available evidence could not establish an outcome. An unanswered request or incomplete response is not evidence of a secure configuration.
The check was not performed in this assessment. It may be outside the selected scan's scope; it is not a pass.
A supplemental check is waiting to complete. The scan can publish its existing results, and the dated addition appears later. Scores are unchanged by queued additions.
Read the published score alongside the findings, coverage and dates. It describes this assessment; it is not a probability of an incident or a guarantee of safety.
A score shown as ‘at least’ is a published minimum with incomplete evidence. Keep the qualifier when quoting it. It is not an exact score or a directly comparable before/after reading.
The report could not publish a main score. Read the available findings and missing-evidence explanation. No score is not zero, and independently observed findings remain useful.
Reports explain visible findings, their implications and suggested next actions. A vulnerability match needs an applicability check; an exposed address may belong to a hosting provider; identity records do not by themselves prove that an organisation's own systems were breached. Review the supporting evidence before acting.
These invented entries show how to interpret evidence states. They are not a real organisation's scan, a score calculation or a claim about the prevalence of these issues.
Observed issue · email policy
The report observed a published monitoring policy on the stated date. Review legitimate senders and mail evidence with the domain's email administrator before changing enforcement. This observation does not test how every receiver handled a real message.
Not verified · website headers
The assessment could not establish the header configuration. It does not establish that a header is missing or present. Read any other retained findings and the report's score qualification separately.
Dated intelligence · software
Read the observation date and verification status. Confirm the actual product, patch level and affected configuration privately. A version match is not proof of exploitation or compromise.
Queued · related-host review
The original report retains its scan date. When the review completes, its addition has a separate date and the score is unchanged. The extra evidence does not establish a new incident or verified repair.
Start with the population and the dated source report. A tracked domain list is the study's population; it is not automatically a census of organisations, sites or people. A public/private or regional label does not establish representative coverage.
Distinguish tracked domains, completed assessments and published scores. A finding's prevalence may describe the scored or assessable subset; use the denominator stated beside that figure.
Completed domains without a published score are excluded from score averages and counted separately. They are not zero-score domains; independently observed findings remain evidence.
A floor-inclusive average uses published lower bounds at their displayed values and remains an ‘at least’ average. A point-only average describes a different subset.
Read primary scan dates and delayed evidence dates separately. Overlapping lists must not be added as a unique-domain total. Later evidence and changed membership can alter figures without demonstrating posture movement.
Different populations, dates, coverage or assessment methods can prevent a fair comparison. An absent finding, unavailable check or incomplete comparison does not establish repair.
Fictional population example: A list has 12 domains and 12 completed assessments, but only nine published scores: seven point scores and two lower bounds. The other three remain unscored. A published-score average therefore describes nine domains, while a point-only average describes seven. Neither is an average over all 12.
Each published study and its PDF retain their own observation dates, scope and qualifications. This guide does not replace those records or turn a study into certification, a national league table or an assessment of internal systems.
The question every MSP and multi-domain owner asks before turning on scheduled monitoring.
Collection limits constrain each check. Repeated or concurrent scans still generate traffic, including across domains that share infrastructure.
The scan description explains the checks we perform; it is not a blanket assurance about permission or a target system's response.
We do not attempt exploitation, credential testing or intentional modification of target systems.
Repeated scans generate requests. Bounded collection constrains each check; it does not guarantee a target's response, absence of alerts or permission to scan.
Public-facing observations and external intelligence, with plan-specific coverage and explicit limits.
Pro/MSP full scans sample up to six advertised nameservers and two parent servers, plus up to five mail servers at one public address each. Dated evidence cards show DNS responses, mail TLS and supported authenticated DANE certificate bindings. Missing responses remain unverified. Matching responses do not prove independent infrastructure or continuous availability. No email is sent; Free scans and daily monitoring skip these advisories.
Certificate validity and expiry, plus bounded TLS 1.0–1.3 handshakes on website port 443 on every plan. Unavailable probes remain unverified; this does not enumerate ciphers or certify the configuration.
Published email records, observed DKIM key structure, and MTA-STS policy syntax and mail-server matching. DNSSEC validation is reported separately from signing-record presence. Unavailable evidence remains unverified; these checks do not test actual message authentication.
The protective HTTP headers your site sends with every page.
Published service and vulnerability observations, supplemented by bounded connection checks. Dated known-exploitation intelligence helps prioritise reported vulnerabilities without claiming compromise or changing the domain score. Where observed versions match the limited lifecycle coverage, reports show dated upstream support context. Distribution backports, extended vendor support and installed patch status remain unverified. This adds no target requests.
Pro/MSP Network Map includes a mobile-friendly list and expandable map of observed website, email and DNS IP locations, with lookup dates, country borders and zoom/pan controls. Locations are approximate: CDN, proxy and anycast addresses may represent an edge, not the origin. Physical server locations and data residency remain unverified. Missing locations stay unknown. This adds no target requests and does not change the security score.
Registration expiry, transfer locks and DNS configuration. Pro/MSP full scans automatically review up to 50 related hosts per scanned domain using public certificate records, including older expired ones, and bounded DNS/HTTPS checks. Daily monitoring skips that review. Discovery is incomplete and indicators need ownership review; they do not confirm takeover or change the main score.
Registered domains that imitate yours — the raw material of phishing against your customers and staff.
Whether your domain, infrastructure, or employee credentials appear in trusted public and commercial threat feeds.
The externally verifiable subset of GDPR Article 32, PCI DSS, and related baselines — formatted as evidence for auditors.
We compare the scan's externally visible checks with current guidance and transparent security benchmarks. A good result is useful evidence that your public domain follows many of the same technical expectations; it is not certification, a compliance decision or a replacement for internal testing.
Comparative analysis last reviewed: 17 August 2026
Close means broad coverage of the same external surface. Strong overlap means many shared checks within a narrower specialist benchmark. Supporting evidence means selected requirements only, and Limited means only a small externally visible part of a much broader framework.
This list is a commitment, not a description of current limitations.
Anything deeper — and there's very little we'd ever add — would be separate, clearly labelled, opt-in, and gated behind verified proof that you own the domain. It would never be quietly added to the standard scan.
Guarded website requests identify our scanner. About our scanner explains the identification headers, signed requests, page collection and how a site operator can block it.
External observation cannot see everything, and we would rather say so.
We don't assess your internal network, your endpoints, your staff practices, or anything behind a login. A scan is one view of your risk, best used alongside internal reviews and penetration testing.
No adverse finding was retained within the checks and evidence available for that assessment. Read the coverage and dates alongside it. A result does not establish that the whole organisation is secure or free of malicious activity.
MyDomainRisk is built and operated by Huro Data Technologies Ltd., a UK company — self-sustaining on subscriptions, not venture-funded, with no advertising, no data sales, and no resale of your information. Data handling is documented in our privacy policy and GDPR commitment; security researchers can find our vulnerability disclosure policy here.
The checker on our homepage runs genuine checks with no account, and shows exactly the kind of findings a full scan produces. Or browse a sample report first to see how a full scan reads.