Public DNS
A, AAAA, MX, NS, TXT, CAA, CNAME, SOA and PTR from authoritative and recursive resolvers.
Data Sources
Where our data comes from
CheckDomainHealth uses public internet infrastructure and third-party reputation lists. We do not claim ownership of registry, DNS or blacklist data — we query it to produce diagnostic summaries.
Last reviewed: July 5, 2026 · See also Methodology, Editorial Policy and Privacy Policy
Source categories
Six public data types queried by the Domain Health Checker and individual tools.
RDAP / WHOIS
Registration, expiry, registrar, status codes and nameserver fields from registry services.
Email records
SPF, DKIM and DMARC TXT records plus MX routing targets from public DNS.
TLS certificates
Live TLS handshakes for chain, expiry, hostname match and issuance policy signals.
Reputation lists
Configured DNSBL and reputation zones for mail and web-related IP targets.
HTTP & website
HTTP(S) requests and response headers observed from our servers at lookup time.
DNS and nameservers
Record lookups use standard DNS queries against the global DNS system. Nameserver delegation is read from NS records at the parent zone and verified against responses from the listed nameservers.
Results reflect what public resolvers return at lookup time. TTL values, caching and regional propagation can cause temporary differences from a registrar DNS panel. Use the DNS Lookup tool for record-level detail.
Domain registration (RDAP / WHOIS)
Registration, expiry, registrar, status codes and nameserver fields come from RDAP services operated by registries and registrars. When RDAP is unavailable, a WHOIS fallback may be used.
Privacy services may redact registrant contact fields while expiry, status and nameserver data often remain visible. See the WHOIS Lookup and Domain Expiry Checker for registration-focused views.
Email authentication records
SPF, DKIM and DMARC are read from TXT records at the domain and selector locations defined by each standard. MX records identify mail routing targets used for related checks.
These tools inspect published DNS only — they do not send email or connect to SMTP servers. Focused checks: SPF Checker, DKIM Checker, DMARC Checker and MX Lookup.
Blacklist and reputation providers
Blacklist checks query configured DNS-based blocklists and reputation zones. Provider availability depends on network access, API keys where required, and each list’s published policy.
When a provider is not connected, the report marks that check as not connected rather than failed. See the Blacklist Checker and Reverse DNS Checker for reputation-focused results.
HTTP, SSL and website signals
Website status and HTTP header checks use HTTP(S) requests from our servers. SSL inspection uses direct TLS connections on port 443 to read certificate chains, expiry and hostname coverage.
Results reflect what our servers observe at request time, which may differ from a visitor’s browser, geographic location or CDN edge. See the SSL Checker, Website Status Checker and HTTP Header Checker.
Availability and limitations
- Third-party providers may rate-limit, block or change response formats without notice.
- Public data is a snapshot in time — not a continuous monitoring service.
- Privacy-protected registration data may hide some registrant fields.
- Blacklist coverage depends on which providers are connected at scan time.
- HTTP and TLS results reflect our server vantage point, not every user path.
For how checks interpret these sources, see Methodology. For content standards on guides and tool pages, see Editorial Policy.
Common questions
No. We query public DNS, RDAP/WHOIS, TLS, HTTP and reputation systems operated by registries, providers and third parties. We do not claim ownership of that data — we summarize it for diagnostic purposes.
Propagation delays, regional resolvers, split DNS, CDN edges and privacy-protected registration fields can cause differences between what you see in a control panel and what public lookups return at scan time.
The report marks that check as not connected rather than failed. Not connected means no verdict is available — it should not be treated the same as a clear or passing result.
Domain names entered into tools may be processed to run checks and maintain service reliability. We do not sell personal data. See the Privacy Policy for how information is handled.
See the Methodology page for how DNS, email, SSL, website, registration and reputation checks are run and scored.
We review this page when providers, integrations or check logic change. The last reviewed date is shown at the top of the page.
Ready to check a domain?
Run a free domain health report using the public DNS, registration, TLS, HTTP and reputation sources described on this page.