Methodology·Published in full

Every check named.
Every weight public.

A security grade you cannot audit is theater. This page is the complete methodology behind every cqwerty report: the exact checks the scanner runs, the formula that turns them into a grade, what the AI does and cannot do, and the honest limits of the scan.

Deterministic checks

Every finding is a real observation: a DNS answer, a header value, a certificate field. Nothing in the findings is generated.

AI explains, never invents

A language model turns the recorded results into plain English after the scan. It cannot add, remove or alter a finding.

Evidence you can read

Raw records sit behind a disclosure in every report section, copyable, so you can verify any claim yourself.

01 · The instant scan

Ten check routines, six surfaces, about 90 seconds.

These are the ten check routines the free instant scan runs concurrently, exactly as implemented. Where a check is shallow or disabled, this list says so.

  • 01
    TLS certificate

    A live TLS handshake with your server. We read certificate expiry (in days), issuer, subject alternative names, negotiated protocol version and cipher.

  • 02
    DNS and email authentication

    Live DNS queries for A, AAAA, MX, NS, TXT, CAA and SOA records. SPF is parsed and its DNS lookups counted recursively per RFC 7208. DMARC tags are parsed. DKIM is probed across 36 common selectors concurrently.

  • 03
    HTTP security headers

    One request to your site. We grade HSTS (max-age and preload), Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, and note server-software disclosure, cookie flags and the HTTP to HTTPS redirect.

  • 04
    WHOIS

    Registrar, creation and expiry dates, days until expiry, and whether WHOIS privacy is on. Some registries return patchy data; when they do, the report says so.

  • 05
    Exposed files and paths

    20 sensitive paths (.git/HEAD, .env, database dumps, backups, admin panels, log files) probed concurrently. A path only counts as exposed when the response content confirms it, not on status code alone.

  • 06
    Subdomain enumeration

    Read from public certificate-transparency logs (crt.sh), capped at 50. Enumerated only: we list what exists, we do not scan the subdomains themselves.

  • 07
    Email blocklists

    Your resolved IP is checked against Spamhaus ZEN, SpamCop, Barracuda and SORBS, and the domain against the Spamhaus DBL, live over DNS. Listings on shared CDN ranges are flagged as shared-tenant noise instead of being blamed on you.

  • 08
    IP resolution and reverse DNS

    The domain is resolved to its IP and a reverse DNS lookup is made. An abuse-database score lookup exists in the code but is currently disabled, so no abuse score appears anywhere in the report. We show what we checked, never a placeholder.

  • 09
    Mozilla Observatory

    A third-party header grade from Mozilla, shown as independent context beside our own header read.

  • 10
    Page performance

    Google PageSpeed metrics, shown for context only. Performance never affects the security grade.

Also free, on every report: DNSSEC

DNSSEC (DS and DNSKEY records queried from the parent zone and the domain) is not one of the ten routines above: the report page fetches it separately, the moment any report loads, free instant scan included, and shows it under Domain and Ownership. You do not need the deeper model to see it. It is a bonus read, not counted in the thirty-five checks below, because it runs outside the graded instant-scan path and never feeds the letter grade.

01b · Named findings

Sixteen more distinct findings, from the same ten routines.

Every routine above collects more than the report used to show. These are the additional named findings we now grade individually, each with its own real evidence and its own fix. Nothing here is a new probe re-labeled: every row is a genuinely different configuration, a different piece of evidence, and a different action, following the same counting rule as the ten routines above.

  • 11
    SPF DNS lookup budget

    The SPF include chain is resolved recursively and every DNS-consuming mechanism counted against the RFC 7208 limit of 10. Over the limit, receivers may treat the whole record as a permanent error.

  • 12
    DMARC coverage (pct)

    The pct tag on your DMARC record, read directly from the already-parsed TXT record.

  • 13
    DMARC subdomain policy

    The sp tag, compared against your main p policy to flag a weaker subdomain policy. Relaxed alignment (adkim=r / aspf=r) is shown for context but never graded: it is the DMARC default and the setting we recommend for most senders, not a gap.

  • 14
    MTA-STS

    The _mta-sts DNS TXT record, plus a fetch of the published policy file at mta-sts.<domain>/.well-known/mta-sts.txt, to read the enforcement mode, MX list and max-age.

  • 15
    TLS-RPT

    The _smtp._tls DNS TXT record naming where TLS delivery-failure reports are sent.

  • 16
    BIMI

    The default._bimi DNS TXT record: the logo URL, and whether a Verified Mark Certificate is attached and reachable.

  • 17
    Cookie Secure flag

    Every cookie your site sets (up to 6, from the same response the header check already fetched), checked for the Secure attribute.

  • 18
    Cookie HttpOnly flag

    The same captured cookies, checked for HttpOnly.

  • 19
    Cookie SameSite flag

    The same captured cookies, checked for a SameSite value.

  • 20
    X-Powered-By disclosure

    Whether the response announces its framework or language via the X-Powered-By header, already read alongside the other security headers.

  • 21
    HSTS includeSubDomains

    Parsed from the same Strict-Transport-Security header value already fetched for the header grade.

  • 22
    HSTS preload-eligible

    The three hstspreload.org submission conditions, computed from that same header: max-age of at least one year, includeSubDomains, and the preload token.

  • 23
    HSTS max-age adequacy

    The max-age value compared against the one-year threshold browsers expect for durable protection.

  • 24
    IPv6 (AAAA) availability

    Whether the domain resolves an AAAA record, from the same DNS query batch as the A records.

  • 25
    Nameserver provider diversity

    Each nameserver hostname matched against known DNS-hosting providers. Only shown when every nameserver is confidently identified; we abstain rather than guess at an unrecognized host.

  • 26
    Cipher strength

    The cipher negotiated in the same TLS handshake used for the certificate check, matched against a list of ciphers with known cryptographic weaknesses (RC4, DES/3DES, NULL, export-grade, anonymous).

01c · Brand and exposure

Two more, promoted out of the deep-only pass. Twenty-eight checks so far.

Typosquat detection and subdomain-takeover exposure used to run only behind the deeper-model button, feeding the AI narration and nothing else. They now run in the instant, graded scan too, each bounded to keep scan time predictable (the cap is published below). Most free scanners do not offer either at all.

  • 27
    Typosquat and lookalike domains

    Up to 40 plausible lookalikes of your domain are generated (TLD swaps, adjacent-character swaps, leetspeak, single-character insertion or deletion, and homoglyph swaps) and each is DNS-resolved. We report which ones are actually registered, where they resolve, and whether they share your own IP (almost always your own alias, not a squat). Registered does not mean malicious: we report registration and resolution, never intent.

  • 28
    Subdomain takeover exposure

    Up to 25 of your enumerated subdomains (from the same certificate-transparency list above, so this does not make a second query) have their CNAME checked against a curated list of cloud-vendor dangling-CNAME signatures (AWS S3, GitHub Pages, Heroku, Azure, Vercel, Netlify and others). A CNAME match alone is never reported: we fetch the subdomain and confirm the "nothing here" response the vendor itself returns before calling it a finding, so a live, claimed service is never mis-flagged.

01d · New passive probes

Seven more, net-new. Thirty-five checks in total.

These seven never ran anywhere before, deep pass included: open ports, redirect-chain tracing, CORS, cross-origin isolation headers, hosting-provider context, certificate key and signature strength, and registrar transfer-lock status. All read-only, all free, all bounded to keep scan time predictable.

  • 29
    Open ports and exposed servicesNew

    A plain TCP connect attempt (no banner grab, no exploit) against 12 high-signal ports that a typical website domain should almost never expose publicly: FTP, SSH, Telnet, SMTP, POP3, IMAP, SMB, MySQL, RDP, PostgreSQL, Redis and MongoDB. Each is probed concurrently, so wall-clock stays close to the per-port timeout regardless of port count.

  • 30
    Redirect chain and open-redirect signalNew

    The HTTP redirect chain starting at your bare domain is traced one hop at a time (never auto-followed), so a loop is caught by URL repetition and the full hop list is kept as evidence. Bounded to 10 hops.

  • 31
    CORS misconfigurationNew

    One request to your domain root with a spoofed Origin header we do not own and could never legitimately be allow-listed. Any echo of that made-up origin is unambiguous evidence of unconditional origin acceptance; combined with Access-Control-Allow-Credentials: true, it is the well-known severe misconfiguration that lets any attacker-controlled page read authenticated cross-origin responses. A bare wildcard with no credentials is reported as context, not as that severe verdict.

  • 32
    Cross-origin isolation (COOP, COEP, CORP)New

    Read from the exact same response already fetched for the header check (no second request): whether Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy are set, and to what value.

  • 33
    Hosting provider (ASN) contextNew

    Your resolved IP is looked up against Team Cymru's free, keyless DNS whois service, which names the Autonomous System announcing that address: who actually hosts you (your own infrastructure, or a specific cloud/CDN provider), shown as plain context, not a pass or fail.

  • 34
    Certificate key size and signature strengthNew

    A second, independent connection to your certificate, verification turned off on purpose: it reads the public key size and signature algorithm even on a self-signed or otherwise untrusted certificate, which the TLS and certificate check above never does (it stops at the trust verdict). Flags an undersized RSA key (below 2048 bits), a sub-256-bit EC key, or a deprecated MD5/SHA-1 signature.

  • 35
    Registrar lock (EPP transfer-prohibited status)New

    Reads the EPP status codes already returned by the registrar-and-age RDAP lookup above: a transfer-prohibited status is the registrar lock that stops an unauthorized transfer away from the real owner. A registry that does not answer, including a rate-limited response, is reported as honestly unchecked, never assumed unlocked.

Not a 36th check: the readiness snapshot

Every report also shows a Readiness Snapshot: five plain-language questions mapped to a typical cyber-insurance application and the externally-visible slice of the AU Essential Eight. It answers each one from checks already listed above (email authentication, certificate and TLS, HSTS, exposed paths), plus one honestly marked not observable (multi-factor authentication, which no external scan can see). It is a re-framing of existing evidence, not a new measurement, so it is not counted in the thirty-five above, and it is clearly labelled indicative, not an audit.

02 · The deeper model

One more probe before the deep report.

Choosing the deeper model runs this additional probe first (plus a second, already-free DNSSEC read, see above), then hands the combined results to the same narrate-only AI. A probe that fails is skipped and reported as unchecked, never guessed. MTA-STS, TLS-RPT and BIMI used to run only here, then typosquat and subdomain-takeover detection; all five now run in the instant scan above instead.

  • 01
    DNS threat feeds

    Five public feeds queried live: SURBL, Spamhaus DBL, URIBL (Spam Eating Monkey), the URIBL malware list and the SORBS RHSBL. This is not Google Safe Browsing, and we never label it as such.

03 · The grading formula

Five weighted scores make the grade.

The overall score is the weighted average below, mapped to a letter band. These are the real weights from the scanner source, not a simplification.

TLS certificate
Weight
30%
What moves it
Grade from certificate expiry window and protocol version
Email authentication
Weight
25%
What moves it
SPF policy strength and lookup count, DMARC policy, DKIM presence
HTTP security headers
Weight
25%
What moves it
The 0-100 header score from the checks above
Exposed files
Weight
10%
What moves it
Grade from confirmed-reachable sensitive paths
WHOIS
Weight
10%
What moves it
Days until domain expiry, plus a small credit for WHOIS privacy
Letter bands
  • A+92-100 of 100
  • A80-91 of 100
  • B65-79 of 100
  • C50-64 of 100
  • D35-49 of 100
  • Fbelow 35 of 100

Inside email authentication: an enforcing SPF earns credit (hard fail more than soft fail) and a +all record is penalised below having no SPF at all; DMARC earns most at p=reject, less at quarantine, a token amount at none; a found DKIM selector adds the rest.

Not in the grade

DNSSEC, subdomain enumeration, blocklist results, threat feeds, Mozilla Observatory, page performance, every named finding in sections 01b, 01c and 01d (including typosquat and subdomain-takeover detection, open ports, redirect chains, CORS and cross-origin isolation headers, hosting-provider context, certificate key and signature strength, and registrar transfer-lock status), and every deep-pass probe are shown as context but do not feed the letter grade today.

We would rather publish that honestly than quietly fold half-checked signals into a number. If the formula changes, this page changes in the same release.

04 · The AI

The AI writes the words. The checks find the facts.

Post-2025, AI-generated security findings are a known failure mode across the industry. Our architecture is built so that failure mode cannot happen here.

Checks first, words second

Every finding in the report is produced by the deterministic checks above. Only after they finish does a language model receive a digest of those results and write the plain-English explanation.

One call, temperature zero

The narration is a single model call at temperature 0 returning structured JSON, cached by a hash of the scan content. It has no tools, no browsing, and no way to probe your domain.

It cannot add findings

The model can only describe values the scan actually recorded. If the narration fails for any reason, you still get the full deterministic report with a plain fallback summary; nothing is invented to fill the gap.

Scout is grounded the same way

The report assistant answers questions from the same recorded scan values. Ask it something the scan did not measure and the honest answer is that we did not measure it.

05 · Scanning behaviour

Read-only, bounded, rate-limited.

What the scanner sends at your infrastructure, and the guardrails around it.

Read-only

The scan sends ordinary DNS queries, TLS handshakes and HTTP GET requests. It never authenticates, never submits forms, never exploits anything, and never changes anything on your systems.

Bounded

About 20 path probes and 12 port probes per scan, concurrent lookups with tight timeouts, and a hard cap on subdomain enumeration. Scans of private or internal IP ranges are refused outright.

Rate-limited

7 scans a day per IP, whether or not you have an account. Re-scanning the same domain within 15 minutes returns the most recent report instead of burning a new scan.

Cached honestly

Reports are cached by content. A cached report is the same report, timestamped; we never re-date old results as fresh.

06 · Data handling

What we keep, who sees it, what we never do.

What we store

The scanned domain, the scan results and their timestamps, and, if you register, your email address and saved scan history. No card details exist anywhere in the product; there is nothing to charge.

Third parties involved

OpenAI receives the scan digest to write the narration. Mozilla Observatory and Google PageSpeed receive the domain name to produce their scores. Certificate-transparency data comes from crt.sh. Each has its own privacy policy.

What we never do

We do not sell scan data, we do not email unsolicited scan results to domain owners, and we do not use your results for marketing against you.

07 · The limits

What this scan is not.

A tool that hides its limits is selling something else. These are ours, in plain terms.

  • This is an external posture scan. It does not test your application logic, authenticated areas, APIs beyond the homepage response, or your cloud configuration.
  • It is not a vulnerability scanner: it does not fingerprint software versions or match CVEs.
  • Subdomains are enumerated from public logs; a capped subset (25) is checked for takeover exposure, the rest are listed but not probed further.
  • Typosquat detection checks up to 40 permutations for DNS registration only. It does not, and cannot, determine intent: a registered lookalike may be an unrelated business, a defensive registration, or your own alias.
  • The IP abuse-score lookup is currently disabled, so the report shows no abuse score at all rather than an empty gauge.
  • The open-ports check is a plain TCP connect attempt against 12 fixed, high-signal ports only: no banner grab, no payload, no exploit, and no port outside that published list is ever touched.
  • The certificate key/signature check connects with TLS verification deliberately turned off, so it can read the key size and signature algorithm of a self-signed or otherwise untrusted certificate. It never overrides the trust verdict from the certificate check above; it only reads the cryptographic parameters, a separate question.
  • Registrar lock status depends on the registry answering RDAP. Some registries (including .au at times) rate-limit this lookup; when that happens the report shows an honest "could not check", never a guessed lock state.
  • Third-party sources (Observatory, PageSpeed, crt.sh, WHOIS registries) sometimes fail or return partial data. When they do, the report shows the gap instead of a guess.
  • A report is a point-in-time reading. Saved domains get one automatic rescan a week, on Mondays, with a plain-English email only when something changed; between those, posture can still drift, so scan again any time for a same-minute reading.

Found an error on this page, or a check behaving differently from its description? Tell us. Corrections to the methodology ship ahead of features.

Now run it on your domain.

You have read exactly what the scan does. See what it finds: a graded report in about 90 seconds, free, no card.

No credit card Results in 90 seconds Read only