Domain Security Assessment
An outside-in review of what a domain publicly exposes, with each result tied to evidence and each gap named as a gap.
Check a domain
We inspect only publicly reachable configuration. No login, agent or installation is required.
What the assessment covers
The assessment runs several modules in parallel against the domain you enter. You can run all of them or select scopes. The scopes below correspond to the modules that run.
- DNS: collects the domain's public records and runs the inherited dns-audit checks, including SPF, DMARC and MX record analysis and DNSSEC state.
- Email authentication: whether SPF and DMARC are published and valid, and whether DMARC is merely monitoring or enforcing. DKIM selectors cannot be enumerated from outside, so DKIM is reported only for selectors that can be tested.
- SMTP: connects to the MX hosts to see whether they accept mail connections and offer encrypted transport. Domains that publish a null MX, meaning they declare they do not receive mail, are marked not applicable.
- Website: HTTPS availability, certificate state, redirects and key response headers on the public site.
- Lookalike domains: generates plausible variants of the domain name and looks for those that resolve, listing them as candidates to review. A candidate is not proof of abuse.
- Reputation: blocklist lookups through licensed providers. If no provider is enabled on the server, this is reported as NOT CONFIGURED, which says nothing about the domain.
How long it takes
Most assessments finish in well under two minutes. The modules run at the same time and each has its own time limit, from 20 seconds for reputation up to 95 seconds for the DNS module. A module that exceeds its limit is stopped, and its checks are recorded as UNKNOWN rather than silently dropped.
Progress is shown layer by layer, so a slow mail server does not hide the DNS and website results that have already completed.
How to read the outcome
The result has two separate axes. Posture says what was found: Strong, Good, Needs Attention, High Risk or Unknown. Coverage says how many planned checks reached a conclusion. A strong posture with incomplete coverage is labelled provisional.
If the domain does not exist in DNS (an authoritative NXDOMAIN answer), no assessment is produced and the page says so. A resolver failure on its own is never presented as a missing record. Read reading statuses for exact meanings.
What is not tested
The assessment is external and non-invasive. It deliberately leaves out the following.
- Internal networks, endpoints, user accounts and anything behind authentication.
- Exploitation, brute-forcing, credential guessing or denial-of-service testing.
- Software version matching against vulnerability databases; no CVE or ransomware verdicts are produced.
- The origin server behind a CDN or proxy; when a CDN edge answers, the result describes the edge.
- Whether a specific message will reach a specific inbox. Authentication records are necessary for good delivery, not a guarantee of it.
- Application-level flaws in your website, such as injection or access-control problems.
Before you run it
Only enter domains you own or are authorised to review. The checks use public data and a small number of ordinary connections, and requests are rate limited. Private, loopback and other non-public address ranges are refused.
To follow up on a result, the domain and email security baseline guide describes what a sensible target state looks like, and the DNS change checklist covers making changes safely.
Written by DNS Tools editorial · Last updated 2026-10-09
Prefer one focused check?
Parse a domain's SPF record, follow every include and redirect, and count DNS lookups and void lookups against the limits receivers enforce.
Walk the _dmarc tree for a domain, read its policy and tags, and check separately whether external report destinations are authorised.
Check MX records, priorities, null MX and whether each mail server name resolves to a public address. Understand how inbound mail is routed for a domain.
See which TLS versions a server accepts, the negotiated protocol and cipher, and the full certificate chain with names, validity, key and signature details.
Paste message headers to trace the Received chain and read Authentication-Results, DKIM, ARC and From alignment. Every result is labelled a claim.
Test a fixed list of 31 common TCP ports on a public host and learn which services are reachable from the internet, with safe guidance for restricting them.
Check DNSSEC for a domain: DNSKEY and DS presence, DS-to-key match, algorithms, signature validity window and what validating public resolvers return.
Check for a security.txt file at the standard location, validate its Contact and Expires fields, and see how to give researchers a safe way to report issues.
Building your security posture.
Layers are checked in parallel. Each shows how many of its checks have actually finished, and anything that fails or times out is reported as such.
What should you fix?
Ordered by security impact, not protocol.