How to read a domain scan report

1 Introduction

You scanned your domain and got a long page: a letter grade, coloured counts, a list of findings, and eight sections full of tables. It looks like a lot. It is built to be read in a few minutes, top to bottom, and this page explains how.

The short version: look at the score ring for the overall picture, fix the high findings first, then the medium ones, and use the sections below only to understand the evidence behind a finding. Low and info items are hygiene, and they can wait. Each finding links to the block that explains it and to an academy fiche.

100

Starting score: every finding takes points away from it

Severity levels: high, medium, low and info (info is free)

Report sections, from Domain & DNS to Branding

2 How It Works

The scan runs many independent checks against your domain (DNS, mail, web server, certificates, subdomains, AI files...). Each check produces evidence, and sometimes findings. The report puts all findings from every check into one list at the top, then shows the evidence section by section.

Score ring

A letter grade, a score out of 100 and a verdict: Healthy, Needs attention or At risk.

Findings list

Every problem found, worst first, each with a link to its evidence and a Learn link.

Sections

The raw evidence, grouped by theme, with a side rail that shows how many findings each block holds.

No score while the scan is running

Some checks take longer than others. Until every check has finished, the ring shows "pending" instead of a grade: a half-finished scan has fewer findings and would look better than it is. Wait for the grade before drawing conclusions.

3 Detailed Analysis

The score and the letter grade

The score starts at 100. Each problem takes points away according to its severity: 20 for a high, 8 for a medium, 3 for a low, 0 for an info. Two rules keep the number fair:

Each extra problem costs a little less

Problems are ranked worst first. The first one costs its full weight, the next ones cost progressively less (the second about 60%, the third about 45%, and so on). Every finding still costs something, so fixing any one always raises the score, but a domain with ten issues does not sit at zero next to one with thirty.

One cause, one charge

Some weaknesses show up as several findings: one weak Content Security Policy produces a line per unsafe directive, one cookie missing two flags produces two lines. The list keeps every line (each tells you what to change), but the score counts the cause once, at its worst severity.

90 to 100

75 to 89

60 to 74

40 to 59

below 40

The ring colour and verdict follow the score: Healthy from 75, Needs attention from 50 to 74, At risk below 50. Some examples:

One medium and nothing else: 92, grade A. One high alone: 80, grade B. One high plus one medium: 75, still B. Three highs: 58, grade D. A single high always drops you out of A.

Severities: high, medium, low, info

High

Something an attacker can use now or very soon: a subdomain that can be taken over, a domain anyone can send mail as, an MCP server that lets anyone change data. Fix these this week.

Medium

A real weakness that needs another step to exploit, or that lowers your defences: a missing security header, an expired security.txt, a policy that monitors but does not enforce. Plan them in the coming weeks.

Low

Hygiene: good practice that is missing or slightly off. Each costs little in the score. Group them and fix them when you next touch the configuration.

Info

An observation, not a defect: a mobile app declared in .well-known, AI crawlers blocked in robots.txt. Info items are worth reading, but they never affect the score. The info count chip only appears when there is at least one.

The findings list

Under the ring, high and medium findings are shown open, worst first. Low and info findings are folded into a closed list underneath, so the first thing you read is what to fix. If nothing is high or medium, the panel says so and keeps the hygiene items folded. Each row has:

A section link

The section name on the right jumps to the block that holds the evidence (the record, the header, the certificate). Read it before changing anything.

A "Learn" link

Every block of the report, and every finding, has a "Learn" link that opens its academy fiche in a new tab: what the result means and how to fix it.

The score and the counts are visible to everyone. The itemised list requires a free mlab.sh account.

The report sections

The side rail lists every section and block, with a badge counting the findings in each, coloured by the worst one. Blocks with nothing to show are hidden.

Domain & DNS

At a glance, DNS records, DNSSEC, registration, third-party services, hosting and IP intelligence, raw TXT records. See DNS.

Mail authentication (SPF, DKIM, DMARC) and spoofing protection for names that send no mail. See email authentication.

Web & TLS

TLS handshake, HTTP security headers, known vulnerabilities, well-known endpoints, network requests, robots.txt and security.txt.

Certificates

CAA, certificate history, shared certificates and the certificate transparency log. See certificates, CAA and CT.

Subdomains

Subdomains on the web, active ones, ghost subdomains, takeover candidates and the full list. See subdomain takeover.

Exposure

Dangling delegations (domains you trust that anyone could register) and lookalike domains. See suspicious domains.

AI & agents

llms.txt, AI crawling policy, agent discovery and MCP servers. See your AI surface.

Branding

A preview of your website as the scanner saw it.

What to fix first

Every high, starting with those that hand something to an attacker directly: a subdomain takeover, a dangling delegation, a known exploited vulnerability, an open MCP server with write tools.

Mail spoofing: a missing or non-enforcing DMARC policy lets anyone send as you, and it is usually a single DNS record to fix.

The medium findings, grouped by who owns the fix: DNS changes together, web server headers together, certificates together.

Low findings when you next touch that configuration. Read info items once, and act only if something surprises you (an app you do not recognise, a provider you stopped using).

Rescanning and "Since last time"

After a fix, scan the domain again. DNS changes can take a while to be visible everywhere, depending on the record's TTL, so if a fix does not show up, wait and retry. Once a previous scan exists, the report gains a Since last time section at the end: it compares this run with the previous one and lists what was added, removed or changed, with the date of the earlier run. It only appears once the scan has finished. After an update of the scanner itself, the comparison is skipped once, so that new checks are not reported as changes you made.

Check your domain on mlab.sh

A domain scan grades your domain out of 100, lists every finding worst first and links each one to its evidence. Rescan after a fix to see what changed.

Scan your domain on mlab.sh

4 Red Flags

Any high finding, whatever the grade

A B with one high is not "good enough". The grade summarises; the high finding is the thing an attacker will use.

Judging a scan that is still running

While the ring says "pending", findings are incomplete. Wait for the grade.

Chasing low findings before the highs

Ten lows fixed move the score less than one high fixed, and protect you less. Work down the list in order.

A "Since last time" change nobody made

A new DNS record, a new subdomain, a changed mail policy that no one on your team remembers: find out who did it. It can be a forgotten provider, or someone else.

Fixing without reading the evidence

Open the block the finding links to before you change anything. The title says what is wrong; the evidence says exactly which record, header or host.

Related Modules

SPF, DKIM and DMARC for your domain

Stop attackers from sending email as your domain: what SPF, DKIM and DMARC do, how to read a scan result and how to reach p=reject safely.

HTTP security headers explained

HSTS, CSP, X-Frame-Options, cookie flags: what each header blocks, what a missing one means in a scan, and a safe configuration to start from.

Subdomain takeover and dangling DNS

How a forgotten CNAME or NS record lets anyone serve content on your subdomain, and how to find and clean up dangling DNS before an attacker does.