Methodology
Everything this scanner reports is derived from public DNS and one public HTTPS path, evaluated against published standards. This page documents exactly how, so you can check our work or disagree with it specifically.
How the configuration score is calculated
The score is deterministic and you can compute it by hand. It starts at 100 and subtracts a fixed weight for each finding, by severity:
| Severity | Shown as | Weight | Meaning |
|---|---|---|---|
critical | Critical | −40 | The protection concerned is not in effect at all. |
high | Error | −15 | A material gap in configuration. |
medium | Warning | −7 | Works today; fragile or below current guidance. |
low | Recommendation | −2 | Minor deviation or hygiene. |
info | Informational | 0 | An observation. Never affects the score. |
The result is clamped between 0 and 100. Two further rules apply:
- If a scan did not complete, no score is shown at all. A partial scan cannot produce a meaningful total.
- Findings withheld because independent resolvers disagreed are excluded from the calculation.
What the score is not
It is a measure of how your DNS configuration compares to the published standards. It is not a security rating, a risk score, or a prediction of whether your mail reaches the inbox. Deliverability depends on content, recipient engagement, list hygiene, sending reputation and per-provider heuristics that no external observer can measure. We do not model any of that and do not claim to.
Severity describes the configuration, not your business risk. p=none is rated high
because it is a documented non-enforcing state, not because we have assessed your exposure.
Where the rules come from
| Area | Document |
|---|---|
| SPF | RFC 7208 |
| DKIM | RFC 6376, RFC 8301 |
| DMARC | RFC 9989, RFC 9990 |
| MTA-STS | RFC 8461 |
| TLS reporting | RFC 8460 |
| Null MX | RFC 7505 |
| DMARC tag status | IANA DMARC registry |
Every finding in a report links to the specific document and section it comes from.
How we avoid reporting things that are not true
- Two independent resolvers. Where they disagree on a record, the affected finding is withheld and labelled rather than reported from one resolver's view.
- No absence claims from failed lookups. If a scan hits its time budget, every finding that would assert a record is missing is suppressed. A check that did not run is not evidence of absence.
- Evidence attached. Each finding carries the raw record that produced it.
- Deterministic rules only. Parsing and evaluation are ordinary code with no model involved. No language model produces, alters or ranks a finding.
What we deliberately do not check
- Every DKIM selector. Not possible, because DNS provides no way to enumerate them. We test a fixed published list of well-known names and say so.
- Your mail servers directly. We do not connect to port 25 or probe your infrastructure. Only public DNS and the public well-known MTA-STS path.
- Blocklists or reputation. Different problem, different product.
- BIMI. Not an RFC, and requires a paid certificate.