Skip to main content

Policy

Responsible Analysis

Anyone can type a domain into a form. That is precisely why what happens next has to be constrained, and why the constraints are engineering rather than intention.

Last reviewed 1 August 2026. Where this document changes materially, the revision date changes with it.

01

The governing principle

The person typing a domain into a public form is very often not the person who owns it. Any service that fetches websites on request has to design around that fact rather than around the well-intentioned majority.

So the boundary is drawn at a single question: would an ordinary visitor’s browser have obtained this? If yes, IXSEO may read it. If no — if it requires probing, guessing, authenticating or sending something unusual — it does not happen, regardless of who asked or how legitimate their interest appears.

This is deliberately a bright line rather than a judgement call. Judgement calls at scale become exceptions, and exceptions are how services like this end up being used for reconnaissance.

02

Three levels of service

Level 1 — Public website snapshot. Available for any public domain. Passive checks only: pages as served, public DNS records, response headers, transport summary, measured performance, public blocklist indicators and a basic exposure summary. Sensitive technical detail is withheld from the public view even where it was observed.

Level 2 — Domain-verified review. After verifying control of an approved domain resource, more can be shown to you about your own domain: expanded findings, affected addresses in fuller form, organisational exposure detail and a downloadable executive report. What is shown expands; what is done does not change. Every check remains passive.

Level 3 — Authorised technical assessment. A separate engagement under signed authorisation, with a defined scope, an agreed window and named contacts. It is never reached from a public form and never follows automatically from verification.

03

What is never done from a public form

  • authentication attempts of any kind
  • brute forcing or credential testing
  • port scanning or service enumeration
  • vulnerability probing or exploitation
  • form submission or any state-changing request
  • directory or asset enumeration
  • requests to private, internal or metadata addresses
  • execution of any script served by the analysed site
  • full-site crawling

These are not policy statements awaiting enforcement. Private targets are refused by a DNS-level guard that runs before every request and again on every redirect. Markup is parsed passively, so no script from an analysed website ever runs. Requests carry timeouts, byte caps and content-type restrictions.

04

What is withheld even when observed

Some information is genuinely public and still should not be reprinted for whoever typed the domain in. Where an analysis observes it, the public snapshot states that a finding exists and withholds the detail:

  • exact administrative or management addresses
  • origin server addresses behind a proxy
  • precise software version numbers
  • complete organisational email addresses
  • employee-level exposure detail
  • exact internal asset names

The finding is not hidden. You are told something was found and what verification would be required to see it, because concealing the existence of a finding would be a different kind of dishonesty.

05

Honesty about what could not be established

A check that fails is reported as a failed check, never as a pass. A blocklist lookup that times out is a lookup failure. A DKIM selector that does not match a common default proves nothing about whether DKIM exists. DNSSEC status is not claimed, because the passive check available to us cannot establish it.

Scores from passive analysis are capped below one hundred. A perfect score would assert that nothing is wrong, and passive observation establishes what is present rather than the absence of a problem. Every score carries an explanation, and no score is displayed without one.

Scores are directional assessments based on the available evidence and should not be interpreted as search-engine rankings.

06

What verification does and does not authorise

Domain verification confirms control of an approved domain resource. It does not automatically authorise active testing of company infrastructure.

A same-domain administrative email proves access to an address. A DNS record proves control of a zone. Neither establishes that the holder has authority to commission testing of the organisation’s infrastructure, and IXSEO does not treat them as though they do. The verification policy sets out each method and exactly what it establishes.

07

Active tooling, if it is ever added

Some organisations legitimately need active technical assessment, and IXSEO’s architecture anticipates that without enabling it. Any such capability would sit behind an internal job-control layer requiring manual approval against a completed authorisation record.

The public website form is not connected to any active tooling and will not be. There is no user-supplied command path, no shell access from public input, and no arbitrary execution anywhere in the analysis. This is an architectural property rather than a configuration setting.

08

If your website was analysed

Our analyser identifies itself honestly in its user agent, including a link to this page, so a request from it is straightforward to identify in a server log.

If you would prefer that we do not fetch your website, tell us through the contact page and we will honour it. You can also disallow our user agent in your robots.txt, which we respect.

Questions about this document can be raised through the contact page. Nothing here is intended to restrict rights you hold under applicable law.