Tool Scoring
Three tools return a number instead of a list: the email check, the header check and the network report. Each weights its findings, because a checklist that counts every missing item the same gives a site with no Content-Security-Policy the same mark as one with no Permissions-Policy. This page lists every weight and why it has the value it has.
Email security
Seven checks, 100 points. Authentication decides whether someone else can send mail in your name, so it carries the most weight. Transport and reporting follow.
| Check | Points | Why that weight |
|---|---|---|
| DMARC | 25 | The only record that tells a receiver what to do with a failure, and the only one that produces reports |
| SPF | 20 | Names who may send. Without it DMARC has half its evidence |
| DKIM | 20 | Signs the message, so it survives forwarding where SPF does not |
| DNSSEC | 15 | Protects the records above from being answered by someone else |
| MTA-STS | 12 | Stops a downgrade to plain text, but only for senders that support it |
| TLS-RPT | 8 | Reports transport failures. Useful, but changes nothing by itself |
| BIMI | 0 | A logo. It changes nothing about whether a message is trusted |
BIMI scores zero by design. It is checked and reported because a broken BIMI record is worth
knowing about, and because its prerequisites are worth stating, it needs DMARC at
p=quarantine or p=reject to have any effect at all. What it does not do
is make a domain safer, so it does not move the score.
Only the checks actually requested count. Deselecting one removes it from the calculation instead of scoring it zero, which is why a run with three checks can still reach 100. The score is the share of available points, not a count of green marks.
HTTP security headers
Seven scored findings, weighted by what each header prevents rather than by how easy it is to set.
| Finding | Weight | Prevents |
|---|---|---|
| Content-Security-Policy | 25 | Script injection, the class with the widest blast radius |
| Strict-Transport-Security | 20 | The first plain-HTTP request on every later visit |
| Framing protection | 15 | Clickjacking, from either frame-ancestors or X-Frame-Options |
| X-Content-Type-Options | 15 | MIME sniffing turning an upload into a script |
| Referrer-Policy | 10 | Leaking paths and query strings to third parties |
| Permissions-Policy | 10 | Embedded content reaching camera, microphone or location |
| Version disclosure | 5 | Naming the exact build in Server or X-Powered-By |
| Cross-origin isolation | 0 | Reported, not scored: COOP, COEP and CORP are situational |
How the number is produced
Each finding gets 0 to 100 points of its own, then those are weighted. A finding marked as not applicable drops out of both the numerator and the denominator, so it neither helps nor hurts:
score = sum(points x weight) / sum(100 x weight) x 100That is why a site can score well with a header missing, if everything else is strong, and why a perfect CSP does not rescue a site that has nothing else.
Three findings that are not a simple present-or-absent
-
max-age=0scores worse than a missing HSTS header. It is the documented way to switch HSTS off: every visitor is released back to plain HTTP on their next first request. A site that never sent the header at least never made a promise it is now withdrawing. -
frame-ancestorscounts as framing protection. It is the specified replacement for X-Frame-Options, so a site that sets it correctly is not marked down for dropping the older header. -
A CSP is read, not just detected.
unsafe-inlineorunsafe-evalin a script directive, or a missingdefault-srcto catch the directives that were not named, cost points even though the header is present.
Every finding names the directive to change rather than only the header that is missing. See Security Headers.
Network ranking
The network report does not score, it ranks. A total report count on its own makes every large hosting provider look criminal: a provider with a million customers will always collect more reports than a range of ten addresses, and that says nothing about how it is run.
Three figures are therefore placed against every other network in the data:
| Figure | What it separates |
|---|---|
| Addresses known here | The size of the network's presence in the data |
| Reports per address | A big provider from a busy one |
| Total reports | Context only, it follows from the first two |
The gap between the first two positions is the result. A large provider ranks high on addresses and low on reports per address. A concentrated network does the opposite, and that is the pattern worth acting on: blocking a whole range is a decision the second figure supports and the first one does not.
How the percentile is computed
Every network with at least one report and no whitelist entry is grouped, the three figures are sorted, and a 101-step ladder is stored from the 0th to the 100th percentile. A lookup then places the network on that ladder. The ladder is rebuilt once a day and shared by every request, so a single lookup never scans the address table.
Whitelisted addresses are excluded from the ranking entirely. They would otherwise pull the distribution towards zero and make every ordinary network look worse than it is.
What a high rank does not mean
Two of the densest networks in the data are scanning services. They generate reports because they scan the internet on purpose, not because they are compromised. Reports per address show where activity is concentrated; what it means still needs the operator's context. The same applies to consumer ISPs behind carrier-grade NAT, where one address carries the traffic of many subscribers.
See ASN Report. For the score of a single address, which uses entirely different arithmetic, see Confidence Score.
Last updated: · Maintained by the ReportedIP team