Safinity Axon · Methodology
How Axon checks and scores your email health
Axon is rules-based: every check is a concrete lookup against your public records, and every point is explained below. No AI, no opaque model, no guessing.
What the score is
Your score runs from 0 to 100 and comes with a letter grade from A to F. It sums up your domain's public email configuration — the records providers check before trusting your mail. Higher is better, and the number and letter always mean the same thing:
| Band | Rating | What it means |
|---|---|---|
| A (90–100) | Excellent | Your public email setup is in great shape. |
| B (80–89) | Acceptable | Mostly healthy, with a few things worth fixing. |
| C (70–79) | Needs improvement | Real problems that likely affect whether providers trust your mail. |
| D (60–69) | Poor | Serious problems — some of your mail is probably being distrusted. |
| F (0–59) | Critical | Your mail setup is broken or wide open to abuse. |
What we check
Five groups of checks, each answering one plain question about your setup. The technical name of each check is listed in parentheses — those names also appear in the Technical details on your report.
Email authentication
SPF · DKIM · DMARC
- Whether you publish a sender policy, and whether there is exactly one (SPF record — auth_spf.record)
- Whether your sender policy is strict enough and stays within lookup limits (SPF policy — auth_spf.evaluation)
- Whether your mail-signing key is present, strong, and current — only when you give us the selector (DKIM — auth_dkim.selector)
- Whether you tell providers what to do with mail that fails checks (DMARC — auth_dmarc.record)
Mail routing
DNS · MX
- Whether mail-routing records exist and are well formed (MX records — dns_mx.records)
- Whether the servers named in those records actually have addresses (MX host addresses — dns_mx.hosts)
- Whether your domain answers for every possible name, which can blur results (Wildcard DNS — dns_mx.wildcard)
- Whether your nameservers answer consistently (Nameserver health — dns_zone.ns_soa)
- Whether your mail servers' addresses map back to names (Reverse DNS — dns_zone.ptr)
Mail server connection
SMTP · TLS
- Whether your mail server answers, offers encryption, and presents a valid certificate — without ever sending mail (SMTP connection — transport_smtp.probe)
Reputation & blocklists
Blocklists
- Whether your mail servers appear on public blocklists (Blocklist check — reputation.dnsbl)
Policy & reporting
MTA-STS · TLS-RPT · BIMI
- Whether you publish a policy requiring encrypted delivery (MTA-STS record — policy_mta_sts.record)
- Whether that policy can actually be fetched and parsed (MTA-STS policy — policy_mta_sts.fetch)
- Whether you collect reports about encryption failures (TLS-RPT — policy_tls_rpt.record)
- Whether you publish a brand logo record — informational only, never a promise of logo display (BIMI — policy_bimi.record)
How points work
You start at 100. Each problem we find deducts points based on how much it usually hurts delivery — small gaps cost a little, broken foundations cost a lot. Each check group has a budget, so one area can never sink the whole score on its own:
| Check group | Budget |
|---|---|
| Email authentication | 40 points |
| Reputation & blocklists | 25 points |
| Mail routing | 15 points |
| Mail server connection | 15 points |
| Policy & reporting | 5 points |
Three honest rules sit on top of the budgets. First, hard caps for catastrophic states: if there is no usable route for your mail at all, the score is capped at 39; if every mail server is unreachable, it is capped at 39; a high-confidence listing on a consequential blocklist caps it at 59. Second, no double-counting: several findings with the same root cause cost you once, not once each. Third, recoverable points: the "up to +N points" on a finding is what fixing that root cause would actually give back — which is why the improvement callout on your report always says "potentially".
These numbers — budgets, deductions, caps — are versioned configuration, currently scoring version 1.0.0. They are tuned against published test fixtures and disclosed here; if they ever change, the version on your report changes with them.
Confidence, coverage, and "Score unavailable"
Coverage is the share of checks — in the groups that ran — that produced real evidence instead of timing out or being skipped. Confidence comes straight from coverage: High at 90% or more, Moderate at 70% or more, Low below that. A check you skip on purpose, like DKIM without a selector, lowers coverage but never costs points.
Below 50% coverage there is no defensible number, so we don't invent one: your report shows "Score unavailable" with the reason and what to try next. The findings we did gather still render — the evidence is real even when the number isn't. These thresholds are versioned configuration, like the budgets.
When checks are turned off
Some check groups can be turned off on a deployment — for example while outbound connections to mail servers are disabled. A turned-off group is removed from scoring entirely, and the remaining groups' budgets are scaled up in proportion so the score still runs from 0 to 100. Turned-off groups are always labeled "Not evaluated on this deployment" and never count as passing or failing.
Worked example, matching this deployment's launch posture: with Mail server connection and Reputation & blocklists off, the remaining budgets (40 + 15 + 5 = 60) are scaled by 100/60 — so Email authentication counts for up to about 66.7 points, Mail routing 25, and Policy & reporting 8.3. Your report shows a notice whenever this happens.
What this score can and cannot tell you
This score sums up your domain's public email configuration — the records providers check before trusting your mail. It cannot tell you whether any particular message reached the inbox: content, sending habits, complaint rates, and each provider's private reputation data all matter and aren't visible to us.
Versions
Every report carries three version strings: the scoring version (how points work), the check-engine version (what we run), and the report schema version (the shape of the payload). They matter when you compare scans over time: only compare scores within the same scoring version. Current versions: scoring 1.0.0, check engine 1.0.0, report schema 1.
Data & privacy
Scans read public data only — the DNS records any provider can look up. We store the scanned domain, the records we observed, the findings, and the source IP address (for abuse prevention). Scan data is deleted after 30 days. Share links expire after 7 days, and creating a new one replaces the old. No account, no email gate. Read the privacy policy.