Skip to content

Scoring methodology

How the rating works.

Every SecLens.ONE score is a 0-100 rating built from weighted, RFC-based checks. No black box: this page is the scoring ledger for the live assessor.

Open-source assessor

One number, four grades

Each check earns points independently; the points are summed on a 0-100 scale. Higher grades require enforced policies, not just published records.

Excellent
90-100

Enforced policies across the board. This domain is hard to spoof and its transport is protected.

Good
70-89

Strong fundamentals in place, usually missing one or two advanced protections such as DANE or TLS-RPT.

Fair
40-69

Basic records exist but policies are weak or unenforced. Spoofing is often still possible.

Poor
0-39

Little to no effective protection. Mail from this domain can typically be forged.

Mail domains and no-mail domains are scored differently

A domain that never sends or receives mail should not be penalized for missing mail infrastructure, but it still needs spoofing protection. SecLens.ONE detects RFC 7505 Null MX and applies a dedicated profile. Both rubrics sum to 100 points. A domain that publishes no MX records at all is scored on the no-mail rubric. The row weights still sum to 100, and that domain scores 0 on the Null MX record row.

Mail profile

Domains with regular MX records · 100 pts

Core protection · 60 pts
DMARC
25
SPF
20
MTA-STS
15
Plus transport & integrity · 40 pts
DKIM
10
DNSSEC
10
DANE
10
TLS-RPT
10
Total100 pts
Null-MX profile

Domains declaring “we send no mail” (MX 0 .)

With DNSSEC · 100 pts
DMARC (p=reject)
35
Null MX record
25
Strict SPF (v=spf1 -all)
25
DNSSEC
15
TLD without DNSSEC · redistributed
DMARC (p=reject)
40
Null MX record
30
Strict SPF (v=spf1 -all)
30
DNSSEC
excluded
When DNSSEC is not applicable, its 15 points move into Null MX, SPF, and DMARC (30 / 30 / 40).

How each protocol earns its points

Rules below apply to the mail profile. Points reward enforcement, not decoration. Each protocol is either additive (components stack) or exclusive tiers (single highest matching level).

DMARC SPF MTA-STS DKIM DNSSEC DANE TLS-RPT

DMARC RFC 7489: anti-spoofing policy

Exclusive tiers max 25 pts

Highest-weighted check: DMARC is what actually stops spoofed mail. Policy (p=) only; sp= is informational. Full points require the policy to apply to 100% of mail (pct omitted or 100). Lower pct scales points (e.g. p=reject; pct=50 → 13).

  • 25 p=reject applying to 100% of mail (pct omitted or 100).
  • 15 p=quarantine applying to 100% of mail (pct omitted or 100).
  • 0 p=none, missing record, invalid syntax, or pct=0. Monitoring alone protects nobody.

SPF RFC 7208: sender authorization

Additive max 20 pts

Components stack when the record is present and free of syntax permanent errors. Soft-fail is not an extra +5 on top of hard-fail. It is a weaker policy slot.

  • +5 Syntactically valid v=spf1 record is published.
  • +10 Policy slot: hard fail -all (unauthorized senders rejected).
  • +5 Policy slot alternative: soft fail ~all awards +5 instead of +10 (and 0 if the record otherwise fails).
  • +5 Lookup budget: effective DNS lookups ≤20 (redirects followed).
  • 0 Syntax permanent errors forfeit all SPF points (invalid ip4/ip6, wrong version, multiple all, …).
Full 20 = +5 valid + +10 hard-fail + +5 lookups. Soft-fail path maxes at 15 (+5 + +5 + +5).

MTA-STS RFC 8461: TLS enforcement

Exclusive tiers max 15 pts

Exclusive tiers: you earn the single highest matching level, not a sum of 5+10+15.

  • 5 DNS only: _mta-sts TXT is advertised.
  • 10 Policy body also fetchable over HTTPS (mode may still be testing or incomplete).
  • 15 Full pass: mode: enforce, all MX hosts covered, valid id and syntax.
  • 0 No _mta-sts advertisement.

DKIM RFC 6376: message signing

Exclusive tiers max 10 pts

Selectors are not enumerable from the outside. SecLens.ONE probes a curated list of widely used selectors. Subtree presence alone does not score. Full points require a production key (not revoked, not t=y).

  • 10 At least one production key: syntax OK, not revoked, and not a test key (t=y). No wildcard DNS trickery.
  • 0 No selectors found, a wildcard answers every selector probe, or only revoked / test-only keys.

DNSSEC RFC 9364: DNS chain of trust

Exclusive tiers max 10 pts

Half credit for DS only; full credit when DS + DNSKEY are published and a trusted DoH resolver reported the AD bit. SecLens.ONE does not perform its own cryptographic chain validation and opens no DNS TCP.

  • 5 DS present at the parent with valid syntax (DS-only half credit).
  • 10 DS + DNSKEY published, and a trusted DoH resolver reported the AD bit. SecLens.ONE does not perform its own cryptographic chain validation and opens no DNS TCP.
  • n/a If the TLD does not support DNSSEC, the check is excluded rather than failed (Null-MX profile redistributes those points).

DANE RFC 7672: certificate pinning via DNS

Exclusive tiers max 10 pts

DNS TLSA presence only. No SMTP connection and no certificate match. Prefer TLSA 3 1 1 (DANE-EE + SPKI) and keep pins updated through cert/key rotation; stale pins break trust for DANE-validating senders.

  • 5 TLSA published for at least one (public) MX host.
  • 10 TLSA published for every (public) MX, syntax OK, and DNSSEC AD observed as above. No SMTP connection and no certificate match.
  • 0 No TLSA for any MX host.

TLS-RPT RFC 8460: TLS failure reporting

Exclusive tiers max 10 pts

Exclusive tiers for reporting readiness.

  • 5 Syntactically valid _smtp._tls record present (no valid reporting URI yet).
  • 10 At least one valid mailto: or https: reporting endpoint (full pass).
  • 0 Missing or invalid advertisement.

The Null-MX profile in detail

Parked or web-only domains are a favorite spoofing target because nobody watches them. A domain that publishes MX 0 . (RFC 7505) tells the world it never sends mail, and can be fully hardened with four controls:

Null-MX checklist RFC 7505: no-mail profile

max 100 pts
  • 25
    Null MX record 30 without DNSSEC

    Single valid MX 0 .; no mixed regular MX (RFC 7505 §3).

  • 25
    Strict SPF 30 without DNSSEC

    Exactly v=spf1 -all.

  • 35
    DMARC reject 40 without DNSSEC

    p=reject only. Quarantine and none score 0 here.

  • 15
    DNSSEC n/a · redistributed

    DS + DNSKEY published and resolver AD observed, or excluded when the TLD cannot support it.

With DNSSEC the four rows sum to 100; without it, the 15 DNSSEC points move into Null MX, SPF, and DMARC (30 / 30 / 40). Full posture on a Null MX domain scores 100 on either weighting. A domain with no MX scores 0 on the Null MX record row, so its ceiling is 75 with DNSSEC and 70 without.

Why the weights look like this

Enforcement beats presence

A DMARC record with p=none earns zero. Points reflect protection delivered, not checkbox compliance.

Everything is verifiable

Every check runs against live public DNS and HTTPS. Each report shows raw evidence next to the verdict. The assessment engine is open source.

Broken syntax earns nothing

RFC-level syntax errors score zero for that check. Receivers cannot reliably act on them either.

Fair to every domain type

No-mail domains get their own profile, and DNSSEC is excluded where the TLD makes it impossible.

Passive by design

Every SecLens.ONE assessment is a passive read of information domain owners publish for automated consumption. There is no active probing of mail servers: no SMTP connections, no test messages, no port probing, no banner grabbing.

What we touch

Standard DNS queries through a public recursive resolver, plus a single HTTPS retrieval of the MTA-STS policy file, a plain-text document published for automated fetching (RFC 8461).

What we never touch

Mail servers themselves. No SMTP sessions, no messages sent or solicited, and no service beyond DNS and the standardized MTA-STS endpoint. Per-domain load is a bounded handful of lookups.

See your own score.

Free, instant, and scored exactly as described above.

Assess domain View scoring source