How Folderly Lens
scores your estate.

Every signal we check, every weight, every verdict band — documented. The verdict your estate gets is reproducible: same DNS, same result. No black box, no proprietary cooperative average. You can verify any finding yourself with dig and a Spamhaus lookup.

Methodology v3 · external-only · last updated 2026-09-30

1. What we check

Folderly Lens queries only public, observable signals — the same records a mailbox provider's reputation engine reads when it decides whether to trust your mail. Zero access to your sending platform. No API keys, no inbox connection, no test sends.

The live collector runs these per domain or IP, in parallel, in real time:

2. How the score works

Domain and IP scores use separate deterministic formulas. A numeric Lens score is published only when required evidence is complete. Domains require SPF, DMARC, MX, and at least one checkable domain RBL; IPs require PTR, forward-confirmed rDNS (FCrDNS), and at least one checkable IP RBL. A checkable missing record is a confirmed failure, while a failed lookup is unknown. Optional DKIM selector probes, RDAP, MTA-STS, and TLS-RPT do not block required coverage.

If any required check is unknown, the score is null, not 100. The result reports scoreStatus: partial when some required checks completed or unavailable when none completed or the domain itself does not resolve, and names missing checks in coverage. Verified absence remains checked evidence. Confirmed adverse findings retain their verdict even when the score is unavailable. Fresh15 age checks and informational-only replies do not satisfy the reputation blocklist requirement.

For IPs with complete required coverage, risk is min(100, listed × 35 + soft signals × 8 + no PTR × 20 + PTR mismatch × 15), then the score is max(0, 100 − risk). A trusted Spamhaus listing or at least two independent listed RBLs produces KILL; one or more listed RBLs, missing PTR, PTR mismatch, or a score below 80 produces REHAB. These confirmed findings persist with incomplete evidence and a null score. Without an adverse finding, incomplete required coverage produces ERROR; complete coverage permits KEEP.

For domains, the precedence is KILL for a trusted Spamhaus listing or at least two listed domain RBLs; REHAB-URGENT for a checkable failed DMARC policy; REHAB for failed MX, one listing, a score below 80, a DMARC warning, or failed SPF; ERROR for otherwise incomplete required coverage; and KEEP otherwise.

For complete scores, KILL is at most 45 and REHAB-URGENT at most 69. REHAB has no 79-point cap: a confirmed issue may require remediation even when the configuration score is 80 or higher. The action verdict and evidence must be read alongside the score.

The estate score is an equal arithmetic average only when every real submitted asset has a complete numeric score. Any partial, unavailable, unresolved, or pending asset beyond the free cap withholds the aggregate. Portfolio EXAMPLE rows are illustrative and do not count as live results. Confirmed adverse verdicts dominate the estate summary even while overall coverage remains incomplete.

3. Confidence is separate from risk

The public score answers "how risky does this asset look?" Confidence answers "how complete is the public evidence?" A dirty IP can be high-confidence when RDAP, PTR, FCrDNS, and RBL probes all completed. A clean-looking domain can be medium-confidence if Lens cannot confirm the actual sending IPs or all common DKIM selectors.

4. Audit register exports and saved snapshots

The in-page artifact is an external public-signal register. It exports the scanned evidence as CSV, a copyable client brief, a copyable fix plan, and a saved report link. The saved report stores only the public scan artifact in Folderly Lens report storage; it does not create an account, connect a mailbox, or claim private receiver data.

Each accepted server scan receives a random scanId and a private receipt retained for 30 days. Random per-tab session and per-attempt UUIDs provide optional correlation without deriving a visitor fingerprint from an IP or email. The ledger stores normalized checked targets, bounded inventory counts, source, timestamps and status, collector/model version, score status, coverage, check states, and bounded reason codes; it does not retain arbitrary raw input or visitor identity.

If receipt storage fails, the collected DNS result remains valid and the interface explicitly warns that its durable receipt is unavailable. The existing authenticated retention job cleans up expired scan receipts. Saved report snapshots have a separate 90-day default retention; an optional scanId links context but does not server-verify a client-submitted report's evidence or scores.

5. What the verdicts mean

6. The external-only guarantee

Every signal is something a reseller, a vendor, or a mailbox provider cannot hide from you. A reseller can claim "isolated infrastructure" — the MX record shows whether it's true. A vendor can claim "fully authenticated" — the DMARC record shows whether it's enforced. Public records don't negotiate.

Because we read only public state, the verdict is fully reproducible. Run the scan from a coffee shop's wifi with zero credentials and you get the same answer. Re-run after remediation and the diff objectively measures whether your fixes worked.

7. What we don't do

Honesty about the limits is the point. Folderly Lens is a risk score, not an inbox-placement score — it measures public structural conditions, not where your mail actually lands today. Lens does not measure inbox placement.

• No mailbox-receiver data. We don't have complaint rates, spam-folder rates, or open rates — those require a mailbox-provider cooperative we're not part of.
• No inbox-placement predictions. "Your mail will land in the Gmail inbox" requires seed-send tests. That's Folderly's managed warm-up territory, not Lens.
• No private mailbox-provider IP reputation. Lens checks public IP RBL, PTR, and rDNS signals. Gmail's private view of your IP lives in Postmaster Tools — an authenticated surface Lens does not claim to replace.
• We never represent INDETERMINATE as clean. If a blocklist rate-limits us at query time, you'll see "couldn't check — retry," never a false all-clear.