Domain intelligence

The mlab Domain Scan provides a structured analysis of internet domains, helping security teams understand infrastructure, trust signals, and exposure. It focuses on transparency, technical accuracy, and analyst-driven interpretation.

1. Domain Scan Overview

The overview section provides the essential context of the domain scan. It confirms what domain was analyzed, when the scan occurred, and whether the analysis completed successfully.

This section acts as the reference point for all subsequent data and helps assess the freshness and completeness of the results.

• Domain – the analyzed fully qualified domain name
• Scan date – timestamp of the analysis execution
• Status – completed, partial, or timeout
• Related SSL – number of certificates linked to the domain

How a domain scan works

2. Ownership & Access Notice

This notice clarifies the intended use of the domain scan and provides additional context when the analyzed domain belongs to the user.

It encourages legitimate owners to authenticate and unlock deeper insights while reinforcing responsible and defensive usage.

• Encourages domain owners to access extended analysis
• Provides ethical and contextual framing
• Unlocks additional data for authenticated users

When the domain is one your organization verified, members of the organization also see a Security monitoring card under the RedKit recap (Team and Enterprise). See Security monitoring.

3. Findings and score

The report opens on one list: every finding from every check, worst first, each tagged with the section it comes from. Above it sit an overall score from 0 to 100 and a letter grade.

How the score is computed:

• Findings that share one cause count once, at their worst severity. A missing DMARC record is one problem, not one per check that notices it.
• Each cause costs points by severity: high 20, medium 8, low 3, info 0.
• Causes are ranked worst first and each one costs a little less than the one before it. A domain with thirty issues still scores below one with five, but a long tail of minor issues does not pin everything to 0.

No score is shown while checks are still running: a half-finished scan has fewer findings, and would otherwise read as a clean bill.

The score is a summary for triage. Every section below shows the raw data it was built from, so you can check any finding against its source.

Every block of the report, and every finding in the list, has a Learn link to a free explainer on academy.mlab.sh: what the result means, why it matters and how to fix it. The score panel links to a guide on reading the report.

4. Registration

• Registrar, creation, last update and expiry dates, with days left before expiry
• Registrar locks: transfer, delete, update and renew. Without a transfer lock, a domain can be moved to another registrar without the owner lifting anything.
• Hold and pending delete statuses, and whether the registration is privacy protected

5. DNS

• Records: A, AAAA, MX, NS, SOA, CAA and reverse DNS
• DNSSEC: validated along the whole chain, not only detected. The status reads secure, insecure (not signed), island (signed, but the parent does not vouch for it), bogus (signed, but validation fails) or unknown.
• CAA: which certificate authorities may issue for the domain, and whether the record restricts anything at all
• TXT records: SPF, DMARC and DKIM, plus the SaaS services they reveal (e.g. Google Workspace in an SPF include)
• Dangling delegations: every domain this one trusts through a CNAME, MX, NS or SPF include is checked for still being registered. A lapsed target can be bought by anyone, who then receives that trust.

6. Email security

SPF and DMARC are evaluated the way a receiving mail server applies them, and the domain's protection against spoofing is graded as a whole.

• SPF: the all qualifier, the number of DNS lookups and void lookups against the limit of 10, and whether the record fails to evaluate (permerror). A record over the limit is ignored by receivers, whatever it says.
• DMARC: the published policy and the effective one, which is what receivers actually apply once the pct percentage is taken into account. p=none means spoofed mail is reported but still delivered.
• DKIM: selectors found, and the key type each one publishes (RSA or Ed25519)
• BIMI, MTA-STS (the policy file is read, since its mode is what decides whether anything is enforced) and TLS-RPT
• Domains that send no mail are checked for the records that stop anyone from sending in their name
• Microsoft 365 tenants: whether mail sent straight to the tenant (Direct Send) can spoof the domain to its own users

7. Web

• TLS: protocol versions, certificate and its chain
• HTTP: redirects, security headers (HSTS, CSP, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy) and cookie flags
• Software and CVEs: the software and versions the site exposes, matched against known vulnerabilities
• .well-known files
• security.txt: checked against RFC 9116 (required fields, expiry, signature), not only for presence
• robots.txt: declared rules and the paths they reveal

Technologies (Team and Enterprise)

The Technologies section identifies the software, plugins and exact versions a site runs, on demand:

• Software is identified from what the site itself discloses (response headers, cookies, markup, the scripts it loads and the version files CMSs and plugins ship with), matched against more than 7,600 technology signatures. Only the hosts you pick are looked at.
• Exact versions where the site gives them away: CMS cores, WordPress plugins and themes, JavaScript libraries, web servers and languages.
• Every line says how it was found and carries the identifier vulnerability tracking keys on: CPE, npm package or WordPress slug.
• Known vulnerabilities: each identified version lists its CVEs, the highest CVSS score and whether any is exploited in the wild, with a link to each CVE. WordPress plugins and themes are matched by their slug against WordPress security advisories.
• A technology without a version reads Not checked, never "None".
• Bot checks and unreachable sites are flagged as such instead of guessed at.

A run counts as one domain scan. Hosts identified in the last 24 hours are shown as they are, without rerunning. Free and Pro accounts see the section locked.

8. AI and agents

How the domain presents itself to AI crawlers and agents:

• llms.txt and llms-full.txt
• The rules robots.txt sets for each known AI crawler, by operator and purpose (training, search, user-triggered)
• Agent cards (A2A), AI plugin manifests and TDM reservation (TDMRep)
• MCP servers: discovered from server cards, DNS and common endpoints. For each one, whether it requires authentication, which tools it exposes and whether they read, write or destroy, and tool descriptions that look like instructions aimed at the model.

9. Certificates

mlab collects certificate data from Certificate Transparency logs and live endpoints.

• Every certificate issued for the domain, with issuer, validity and fingerprints
• Certificate history over time
• Neighbours: other domains that share a certificate with this one

10. Attack surface

• Subdomains: active ones (resolving now) and historical ones (seen in passive sources), with suspicious names flagged
• Every subdomain on the web: each live host is visited once (homepage and TLS handshake) and gets its own A to F grade. The grade is never a bare letter: the report shows the base its security headers earned and each penalty applied. Hosts answering with an API response, an error page or an anti-bot challenge are listed but not graded, with the reason.
• CVEs per host: the software each host exposes, with its known CVEs. CVEs are matched again each time the report is opened, so a vulnerability published after the scan still shows up.
• Subdomain takeover: names pointing to an unclaimed cloud resource
• Ghost subdomains: names in Certificate Transparency that no longer resolve, such as abandoned services, leaked internal hostnames and takeover candidates
• IP intelligence for the addresses the domain resolves to
• Typosquatting: registered look-alike domains

Hosts on private addresses are skipped, and very large domains are capped: the report says when the list was truncated.

11. Older reports

A report made by an earlier version of the scanner says so at the top, lists the checks it is missing, and offers a new scan to fill them in.

12. Using the report from the API

Two routes return a domain scan:

domain-report/2 only ever gains fields; a breaking change would ship as a new schema on a new route. Ignore fields you do not know. status is completed, partial, failed or in_progress, and score is null while the scan is in progress. Sections a scan predates are null rather than empty, so "not checked" never reads as "nothing found". See the API reference.

13. Limitations, Timeouts & Partial Scans

Some domains cannot be fully analyzed due to size, complexity, rate limiting, or explicit platform restrictions.

In such cases, scans may timeout or return partial results while still providing useful insights.

• Large or highly interconnected domains
• Strict rate limiting or blocking
• Blacklisted or restricted domains
• Graceful degradation with partial data

14. Responsible Usage & Disclaimer

mlab Domain Scan is intended for defensive security, research, and legitimate infrastructure analysis.

The platform does not perform intrusive exploitation, does not bypass authentication, and does not modify remote systems.

• No active exploitation or brute forcing
• Read-only, non-intrusive analysis
• Compliance with responsible disclosure principles
• User accountability for scan intent

Read-only · No exploitation · Defensive security