How our scores work
Reviewed by Prabath Thalangama · Last updated October 22, 2026
Every score on this site comes from fixed, published rules rather than an opaque model. This page lists those rules so you can predict a result, reproduce it, and decide how much weight to give it.
How is a single tool scored?
Each diagnostic starts at 100 and loses points for every finding, by severity. The score never goes below 0.
| Severity | Points | Typical example |
|---|---|---|
| Critical | -40 | The check failed in a way that breaks something: an expired certificate, an SPF record over the lookup limit, an open zone transfer. |
| Error | -30 | The check could not complete correctly. |
| Warning | -15 | Works, but weakens security or deliverability: DMARC p=none, a missing security header, a weak DKIM key. |
| Info | 0 | Worth knowing, no deduction: for example a record type the domain doesn't use. |
How is the Super Scanner score calculated?
The Super Scanner runs 24 checks against one domain at the same time and reports their average, rounded to a whole number. Each check is scored with the rules above, so one critical problem pulls the overall score down noticeably without hiding everything else that passed.
| Area | Checks included |
|---|---|
| DNS | A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, SRV and DS lookups, WHOIS/RDAP, DNSSEC validation, zone transfer (AXFR) exposure |
| SPF, DMARC, BIMI, MTA-STS and TLS-RPT | |
| Website | HTTP response and redirects, security headers, HSTS preload eligibility |
| TLS | SSL/TLS certificate, chain, protocol and cipher |
| Security | DNS blacklist (DNSBL) listings, subdomain takeover via dangling CNAMEs |
Not included: DKIM (it needs a selector, which a domain-only scan cannot know), DNS propagation, reverse DNS (it takes an IP address), and ping, traceroute and port checks, which test raw reachability rather than domain health.
How is the SSL/TLS grade calculated?
The SSL checker connects on port 443 with full certificate and host-name verification, records the protocol and cipher the server negotiates, and starts from 100 points:
| Condition | Points |
|---|---|
| Negotiated TLS 1.3 | 0 |
| Negotiated TLS 1.2 | -5 |
| Negotiated TLS 1.1, 1.0 or SSL | -40 |
| Weak cipher (RC4, 3DES, DES, MD5, NULL or EXPORT) | -40 |
| Certificate expires in under 30 days | -5 |
| Certificate expires in under 14 days | -20 |
| Grade | Points |
|---|---|
| A+ | 100 |
| A | 85-99 |
| B | 70-84 |
| C | 55-69 |
| D | 40-54 |
| F | Under 40, an expired certificate, or a failed handshake |
The grade reflects what a modern client actually negotiates. It does not enumerate every legacy protocol or cipher the server would also accept, and HTTP headers such as HSTS are scored separately by the security headers check.
How is the email deliverability score (0-10) calculated?
The deliverability test scores a real message you send to a one-time address, adding points for each check it passes:
| Check | Points |
|---|---|
| SPF passes for the sending IP | 2 |
| DKIM signature verifies | 2 |
| DMARC aligns with the From domain | 2 |
| Sending IP not on Spamhaus ZEN, SORBS, Barracuda or SpamCop | 2 |
| Sending IP has reverse DNS (PTR) | 1 |
| No content problems: spam-trigger subject words, an all-caps subject, HTML without a plain-text part, or a missing Message-ID | 1 |
A 10 means authentication and the basic reputation checks are clean. Mailbox providers also weigh your sending history, engagement and complaint rates, which no outside test can see.
How is the security headers score calculated?
The security headers check starts at 100 and loses 15 points for each missing important header (Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy). The others (Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy) are reported without a deduction. It checks that each header is present, not how strict its value is.
Where does the data come from?
- All network checks run from our servers in background workers, with a timeout on every request. Targets are validated first, and private, loopback, link-local and cloud metadata addresses are refused.
- Record lookups go through our servers' recursive resolver, so they show what the internet currently sees rather than your local cache. The propagation checker compares Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), OpenDNS and Verisign, and DNSSEC is validated through validating public resolvers.
- Domain registration data comes from RDAP, the structured successor to WHOIS.
- The blacklist checker queries more than 80 public DNSBLs. Answers outside 127.0.0.0/8, and Spamhaus's 127.255.255.x error codes, are never counted as listings.
- Browser-based utilities (JSON, XML, JWT, hashes, passwords, Kubernetes YAML, DKIM keys) run entirely in your browser and send nothing to us.
What is and isn't stored is described in the privacy policy. Found a score that looks wrong? Tell us.