How RDAPWatch checks and scores a domain
Every result on this site comes from five live checks — blacklist, SSL/TLS, email authentication, registration and DNS — each with a published pass/warn/fail threshold taken from the standard that defines it. This page is the full method: what each check reads, where the threshold comes from, how the 100-point score is weighted, and what the checks deliberately do not claim.
Written and maintained by the team that builds the check engine. Thresholds change only when the underlying standard does, and this page is updated in the same change.
Blacklist weight 30/100
What is read. The domain's A record and the IPs behind its MX records are queried against 25 public DNSBL zones (29 including the Spamhaus zones, which need a Data Query Service key).
How it runs. Standard DNSBL lookup: the IP is reversed into the list zone and resolved. Every zone in the list was verified live against its SOA and the conventional 127.0.0.2 test entry; a zone that stopped answering was removed rather than left in, because a dead zone returns NXDOMAIN for every query and would silently read as "not listed".
Thresholds. Tier 1 (authoritative, low false positive — Spamhaus, SpamCop, Barracuda, PSBL) — a hit is a fail. Tier 2 (smaller, advisory) — hits alone are a warn. Tier 3 (netblock/ASN collateral lists and pay-to-delist operators) — never changes the status and costs at most 2 points, shown on its own advisory line.
Reference: RFC 5782 — DNS Blacklists and Whitelists · Run it: Blacklist checker
SSL / TLS weight 25/100
What is read. The certificate the host actually serves is fetched over a TLS connection and read: expiry, issuer, the hostnames it covers (CN + SANs), chain completeness and negotiated TLS version.
How it runs. Expiry is counted to the day. Hostname matching follows the certificate SAN rules, including single-label wildcards. A certificate that is valid but does not cover the name you browsed to is a failure, not a warning — browsers treat it that way.
Thresholds. Expired or hostname mismatch — fail. Under 14 days to expiry, an incomplete chain, or TLS below 1.2 — warn. Note that the CA/Browser Forum maximum certificate lifetime dropped to 200 days on 15 March 2026 and steps down to 100 days in 2027 and 47 days in 2029, so renewal automation matters more each year.
Reference: CA/Browser Forum — Baseline Requirements · Run it: SSL / TLS checker
Email authentication weight 25/100
What is read. SPF, DKIM and DMARC records are resolved and parsed: the SPF policy and its DNS-lookup count, a DKIM public key at the selector, and the DMARC policy and alignment.
How it runs. SPF is evaluated for the mechanism count that counts against the RFC limit, not just for the record existing. DKIM is probed across common selectors when you do not supply one, so "no DKIM found" means the usual selectors were empty, not that DKIM is impossible.
Thresholds. No SPF record, more than one SPF record, or SPF above 10 DNS lookups (the RFC 7208 §4.6.4 limit, beyond which evaluation must return permerror) — fail; so is a missing DMARC record. 8 to 10 lookups, DMARC at p=none, no DKIM key found at the probed selectors, or no MX at all — warn. The worst of the four sub-results becomes the check status. "No DKIM found" is deliberately a warn, not a fail: we can only probe known selectors, so the answer is inconclusive rather than negative.
Reference: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC, May 2026) · Run it: Email authentication checker
Registration weight 10/100
What is read. Creation date, expiry date, registrar, EPP status codes (transfer/delete/update locks) and the nameservers the registry has on file.
How it runs. Read over RDAP — the structured, standardised successor to WHOIS — via an RDAP bootstrap that resolves the authoritative server for the TLD. Registry nameservers are compared with the live NS records in DNS; a mismatch is surfaced because it is what a hijack looks like early.
Thresholds. Already expired — fail. Expiring in under 30 days, no clientTransferProhibited lock, or a mismatch between the registry nameservers and the live NS records — warn. Some ccTLD registries publish no EPP status array over RDAP at all; lock state is then reported as unknown and no warning is raised, rather than crying wolf about a lock that may well exist.
Reference: RFC 9224 — Finding the Authoritative RDAP Service · Run it: Registration checker
DNS weight 10/100
What is read. A snapshot of A, AAAA, MX, NS, TXT and CAA records, resolved over DoH.
How it runs. Queries go to two independent DoH resolvers so a single resolver outage or a poisoned answer does not become your result. For monitored domains the snapshot becomes a baseline, and later changes are diffed against it.
Thresholds. No NS and no address record at all — the domain does not resolve — fail. Resolving but with no CAA record — warn. CAA is advisory: it restricts which CAs may issue certificates for your domain (RFC 8659), so its absence is a missed hardening step rather than a break. Everything else in the snapshot is recorded for the baseline diff rather than scored.
Reference: RFC 8659 — DNS Certification Authority Authorization · Run it: DNS checker
Scoring, currency and limits
How is the 0-100 score calculated?
Each check carries a fixed weight — blacklist 30, SSL 25, email 25, registration 10, DNS 10, summing to 100. A pass earns the full weight, a warn earns half, a fail earns none. Advisory penalties (capped at 2 points) are then subtracted. A check that errored is excluded from both sides of the fraction, so one transient RDAP timeout cannot tank an otherwise healthy score.
Why does my score differ from another checker?
Because the thresholds differ, and every checker chooses its own. The thresholds used here are listed above with the standard each comes from, so you can see whether a difference is a disagreement about facts or about severity. Blacklist results in particular vary by which lists a tool queries and how it weights collateral netblock listings.
How current are the results?
Free checks run live at the moment you request them; nothing is served from a stale cache beyond a few minutes of rate-limit caching. Monitored domains are re-checked daily on the free plan and every 15 minutes for SSL and DNS on paid plans, and alerts are confirmed by a second check before they are sent.
What do these checks deliberately not do?
They do not scan for malware or vulnerabilities, do not assess content or SEO, do not send test email through your server, and do not judge deliverability at any individual mailbox provider — a clean report means the infrastructure signals checked here are healthy, not that every message will reach the inbox.
Corrections
If a check reports something you can show to be wrong — a threshold that misreads the standard, a list that no longer belongs, a registry whose RDAP fields we parse incorrectly — that is a bug in the engine, not a display quirk, and it is fixed at the source so the free checker, the monitoring cron and the API all change together. The checks share one implementation precisely so they cannot drift apart.