This page explains exactly where DomainDNSCheck's results come from, how each check works, how long results are cached, how the scores are calculated and what the tools cannot tell you. Every check is passive: it reads public information and never scans ports, tests for vulnerabilities, crawls a site or attempts a login.
Data sources
| Area | Source | How it is reached |
|---|---|---|
| DNS records, DNSSEC | Public recursive resolvers using DNS-over-HTTPS (by default Cloudflare 1.1.1.1 and Google Public DNS) | HTTPS JSON API, with automatic failover between resolvers |
| Registration data | The registry or registrar RDAP server responsible for the domain | Found through the IANA RDAP bootstrap registry |
| IP network data | Regional internet registry RDAP servers (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) | IANA bootstrap |
| SSL/TLS certificates | The website itself, on port 443 | A direct TLS connection to a validated public address |
| HTTP status, redirects, security headers | The website itself, on ports 80 and 443 | Each request and every redirect target is resolved and validated before connecting |
| MTA-STS policy | https://mta-sts.<domain>/.well-known/mta-sts.txt |
Same validated HTTPS connection |
| Certificate Transparency | A public CT search service (crt.sh) | Its documented JSON interface |
| Domain structure | The Public Suffix List | Bundled and refreshed weekly |
DomainDNSCheck never connects to private, loopback, link-local or other reserved network addresses, and checks every redirect target before following it.
Caching
To keep the service fast and fair to the providers it relies on, results are cached for a short time. A change you have just made may therefore take a few minutes to appear.
| Check | Cache time |
|---|---|
| DNS records | 5 minutes (resolver comparison: 1 minute) |
| DNSSEC | 15 minutes |
| HTTP, redirects, headers | 5 minutes |
| Email security | 10 minutes |
| SSL/TLS | 1 hour |
| Registration (RDAP), IP data, Certificate Transparency | 6 hours |
Failed lookups are not cached, so a temporary provider problem is retried on the next request.
How results are reported
Every finding has one of five statuses:
- Pass — the check succeeded and the configuration meets the relevant standard or best practice.
- Warning — it works, but something should be improved.
- Fail — something is broken, missing or insecure.
- Info — useful context that is neither good nor bad.
- Unknown — the check could not be completed, for example because a provider timed out.
Unknown is never treated as a failure. If a DNS resolver or registry does not answer, the result says the check could not be completed; it does not claim that a record or domain does not exist.
Scores
Domain report (configuration health)
Six areas — registration (weight 15), DNS (20), DNSSEC (10), SSL/TLS (20), web configuration (15) and email security (20) — each start at 100. Findings marked Fail or Warning deduct the points listed in the published rules. The overall score is the weighted average of the areas that could be checked; areas without data are left out rather than scored as zero. Every deduction is shown under "Why this score?".
Domain security report
A separate, versioned score for protection against takeover, forged DNS, interception, email spoofing and look-alike names. Areas: domain control (20), DNS protection (20), transport security (20), email anti-spoofing (25), web security headers (10) and identity / IDN risk (5). Critical findings, such as an expired certificate, prevent a Strong rating regardless of the score. Ratings: Strong 85 and above with no critical finding, Good 70, Needs attention 50, Weak below 50.
Email security posture
Starts at 100; each problem listed in the rules deducts points. Missing optional features such as MTA-STS are suggested but do not deduct. p=none in DMARC is explained as monitoring mode rather than treated as broken. Ratings: Strong 90 and above with no critical problem, Good 75, Needs attention 50, Weak below.
Scores are practical indicators, not certifications or security audits.
Known limits
- DNS propagation. Comparing public resolvers shows what those resolvers currently have cached. Large resolvers are anycast networks, so this is not a measurement of every location in the world.
- Domain availability. A lookup can show that a name appears unregistered, but only a registrar or registry can confirm availability. DomainDNSCheck never states that a name is available without registrar confirmation.
- WHOIS. Registration data comes from RDAP, the modern replacement for WHOIS. Some country-code registries publish neither RDAP nor a public interface; their results are reported as unsupported.
- DKIM. Selectors cannot be discovered reliably from DNS, so DKIM is only checked for a selector you provide.
- Certificate Transparency. A name in a certificate proves that a certificate was issued, not that the host exists today or is controlled by the same party. Passive subdomain results are "publicly observed hostnames", never a complete list.
- IDN look-alikes. Visual-confusion results are risk indicators about how a name looks. They do not say anything about who owns a domain or why it was registered.
- BIMI. A BIMI record only publishes a logo location; DomainDNSCheck does not verify brand ownership.
Privacy
Lookups are not linked to visitors and result pages are not published or indexed. See the privacy policy for details, and the disclaimer for how to use the results.