Trust & Transparency
Methodology
How each diagnostic is computed, what it can and cannot tell you, and how to interpret the result.
Every tool on CheckItNowTools is documented here. For the upstream sources we query, see Data sources. For our editorial and commercial practices, see our Advertising disclosure.
IP lookup
- How it works
- We resolve your public IP via an HTTPS request to a geolocation API at request time, then classify the network type (residential, hosting, VPN/proxy) by ISP name and ASN heuristics.
- Limitations
- IP geolocation is city-accurate at best. ISP names and ASNs are heuristic indicators of VPN/hosting use — not proof.
- How to interpret
- Treat the location as approximate. A 'VPN/proxy' verdict means the network is commonly used for that purpose, not that you are necessarily routing through one.
DNS lookup
- How it works
- DNS queries are sent over DNS-over-HTTPS (DoH) to Cloudflare 1.1.1.1, with cross-checks against Google 8.8.8.8 when results differ.
- Limitations
- Results reflect what those resolvers see — propagation may differ in other regions. TTL caching can mask very recent changes.
- How to interpret
- If a recent change is missing, wait for the published TTL to elapse and recheck. Cross-resolver mismatches usually indicate propagation in progress.
WHOIS / RDAP
- How it works
- We query the registrar's RDAP endpoint (IANA-bootstrapped) and fall back to port-43 WHOIS where RDAP is unavailable.
- Limitations
- Many registrars redact contact information under privacy services and GDPR. Registration dates are authoritative; contact data may be obscured.
- How to interpret
- An empty contact block is normal for privacy-protected domains, not suspicious by itself.
Blacklist / DNSBL
- How it works
- The target is queried in parallel against a curated panel of DNSBLs. We report the count of lists returning a positive response and the per-list verdict.
- Limitations
- A single listing does not mean a host is malicious — false positives occur. Removal can take 24–72 hours after the underlying issue is fixed.
- How to interpret
- 0 listings is the expected baseline. 1–2 listings warrant investigation. 3+ listings indicates a real reputation issue worth resolving.
SSL / TLS certificate
- How it works
- A real TLS handshake is performed to the host. We report the leaf certificate's subject, SANs, issuer, validity dates, and signature algorithm.
- Limitations
- We do not chase intermediate chain installation issues. Expired roots and OCSP problems are not surfaced.
- How to interpret
- A missing SAN for the requested host is a real misconfiguration. An expiration within 14 days warrants immediate renewal.
HTTP / security headers
- How it works
- We issue a request to the target and score the response headers against the OWASP Secure Headers Project recommendations.
- Limitations
- Headers reflect the origin we reach — CDN edges and origin servers can differ. We do not test header behavior across all routes.
- How to interpret
- Missing CSP, HSTS, or X-Content-Type-Options on a sensitive endpoint is a legitimate concern; on a static marketing page it is lower priority.
Domain / IP reputation
- How it works
- We combine DNSBL listings, certificate signals, and HTTP/security header posture into a single qualitative verdict (Safe / Caution / Risky).
- Limitations
- Reputation is a snapshot — it can change minute-to-minute. We do not include historical malware feeds or paid threat-intel.
- How to interpret
- Use the verdict as a triage signal, not a final judgment. Combine with WHOIS, domain age, and your own context.
Phishing / URL safety
- How it works
- We resolve the URL, fetch reputation, and inspect the response for HTTPS enforcement, redirect chains, and security headers.
- Limitations
- Brand-new phishing pages (under 24 hours old) often have no reputation yet. Visual lookalike detection is not yet implemented.
- How to interpret
- A clean reputation on a fresh domain is the most common false-negative pattern. When in doubt, do not click.
Reverse DNS (PTR)
- How it works
- We query the appropriate <code>in-addr.arpa</code> (IPv4) or <code>ip6.arpa</code> (IPv6) zone for a PTR record over DoH.
- Limitations
- Many IPs have no PTR record. ISPs control PTR — the result reflects the network owner's labeling, not the user.
- How to interpret
- A missing PTR is normal on consumer connections. Mail servers without a PTR are commonly rejected by spam filters.
Last reviewed: June 2026. If a tool changes how it computes a verdict, this page updates in the same release.