Methodology · model v1.0
How the Folderly Rating is computed
The Folderly Rating is a 0–100 score of a domain's email sending posture, computed entirely from externally verifiable public data: DNS records, blocklist zones, and registry information. This page is the complete algorithm — every signal, every weight, both caps. There is no proprietary black box, because for a score you're asked to trust, the algorithm is the product.
What the Rating measures — and what it doesn't
The Rating measures configuration, not behavior. It answers: “is this domain set up the way mailbox providers demand since the 2024 Google/Yahoo and 2025 Microsoft sender requirements?” It does not claim to predict inbox placement — real provider reputation also depends on engagement, complaint rates and sending history, which are not externally observable. A domain can hold an A and still land in spam through bad sending behavior; closing that gap is what the Folderly platform does.
Pillar A — Authentication (45 points)
The bulk-sender mandates made authentication the binary gate to the inbox; it carries the plurality of weight.
| Signal | Points | How it scores |
|---|---|---|
| SPF | 14 | Record present (6) · syntactically valid and ≤10 DNS lookups (4) · terminal qualifier: -all (4), ~all (3), ?all (1), +all (0 and caps the grade at F — it declares an open relay) |
| DKIM | 9 | Key ≥1024-bit found via common-selector probe (9) · key under 1024 bits (2) · not detected = 5 points, labeled unknown — never zero (see probing limits below); the floor rises to 7 when DMARC is p=reject with rua, since a domain can't safely run reject without working DKIM |
| DMARC | 22 | Record present (6) · policy p=reject (14), quarantine (10), none (4) · rua reporting address (2) · pct<100 on an enforcing policy scores one tier down — partial enforcement is not enforcement |
Pillar B — Reputation (30 points)
| Signal | Points | How it scores |
|---|---|---|
| Blocklists | 24 | Tier 1 (Spamhaus DBL/ZEN, SURBL — low false-positive, consumed by mailbox providers): any listing loses all 24 points and caps the grade at D. Tier 2 (SpamCop, Barracuda): −8 per listing. Aggressive Tier-3 lists (UCEPROTECT-class) carry zero weight — their false-positive rate would make the score fear-mongering. A list we cannot verify from our resolver is disclosed as 'not verifiable', never guessed |
| Reverse DNS (MX) | 6 | All checked MX hosts have PTR records that forward-confirm (6) · partial (3) · none (0) |
Pillar C — Infrastructure & hygiene (25 points)
| Signal | Points | How it scores |
|---|---|---|
| MX sanity | 8 | MX present and resolving to reachable, public hosts; Null MX and dangling records score 0 |
| MTA-STS | 4 | Policy fetchable with mode=enforce (4) · testing (2) |
| TLS-RPT | 2 | _smtp._tls record present |
| DNSSEC | 3 | Zone signed (DS records present) |
| BIMI | 2 | Valid default._bimi record |
| Domain age | 4 | ≥2 years (4) · 6–24 months (2) · under 6 months (0) — fresh domains are the profile providers throttle hardest. RDAP-unavailable scores the middle bucket, disclosed |
| Not parked | 2 | No parking-service fingerprints; a parked classification also caps the grade at D |
Grade bands and the two caps
Two overrides, both rendered as explained line items, never silent: an active Tier-1 blocklist listing or a parked/disposable classification caps the displayed grade at D; SPF ending in +all caps at F.
DKIM probing limits, in plain language
DKIM selectors are only discoverable by guessing common names (google, selector1, k1, …). Teams using custom or rotated selectors — and Amazon SES's random per-identity selectors — are invisible to any probe. Absence of a probe hit therefore proves nothing, which is why we report “not detected via common selectors” rather than “missing,” and score the unknown case at a neutral floor instead of zero. Detected keys are labeled detected, not verified — cryptographic verification requires observing a real signed message.
Unknown is never fail
A DNS timeout, a blocked blocklist mirror, or an RDAP outage produces an “excluded, disclosed” line — not a lost point and not a free pass. A wrong number is worse than a delayed one. Scores cache for one hour, so a refresh returns the same number rather than jittering on transient lookups.
Gaming the score (please do)
Every legitimate way to raise a Folderly Rating is identical to actually fixing deliverability: publish DMARC and ratchet to reject, repair SPF lookup bloat, get delisted, deploy MTA-STS. Goodhart's law is, for once, on your side. The weights are public precisely because optimizing for them improves the thing they measure.
Data handling
- Scores are computed from public DNS, blocklist and registry data only — no login, no crawling behind authentication.
- Checked email addresses are reduced to their domain for scoring and are not stored.
- Report-request emails are used for the requested report; no list-adding without explicit opt-in, no resale, no retention beyond the report lifecycle.
- Signal results cache for 1 hour; cached scores are returned verbatim for determinism.
Versioning
Every score carries its model version (currently v1.0). Weight changes ship as a minor version with a changelog entry on this page; a re-grade event would be a major version with a 30-day overlap showing both numbers.