Any tool can give you a number. The number is only worth something if it survives the next question: what should I do on Monday morning?
A Domain Health report is built to answer that. It runs every check we have against one domain, grades each finding, and rolls the result into a single score with a letter grade. This guide explains exactly how that number is produced — no mystery weighting — and the order in which to work through what it found.
How the score is calculated
The report is organised into components: the MX records, SMTP behaviour, SPF, DKIM, DMARC, blocklists, the web response, the certificate, DNS delegation, registration data, and so on. Each component runs its own checks, and each individual check comes back as an error, a warning, a pass, or informational.
Each component is then scored on its own:
- Start at 100.
- Subtract 15 for every error.
- Subtract 5 for every warning.
- Never go below 0.
The domain score is the average of the component scores, and the letter grade follows directly:
| Score | Grade | What it means in practice |
|---|---|---|
| 90–100 | A | Nothing is broken. Remaining items are refinements. |
| 80–89 | B | Solid, with one real weakness or several small ones. |
| 65–79 | C | Something is actively costing you delivery or resilience. |
| 50–64 | D | Multiple failures; expect visible symptoms. |
| Below 50 | F | Core infrastructure is misconfigured or unreachable. |
Why the score and the status can disagree
The report also carries an overall status, and it is the worst result found anywhere — not an average. A domain can score 91 with an A and still be marked Problems found, because one blocklist listing is an error regardless of how good everything else is.
Read the score as "how healthy is this domain overall" and the status as "is there something wrong right now". They answer different questions, and both are useful.
The five categories
- Blacklist — the domain and its mail and web addresses against every enabled blocklist.
- Mail Server — MX records, resolution, reverse DNS, SMTP banner and STARTTLS, SPF, DKIM, DMARC, and the newer transport policies.
- Web Server — the HTTP response, redirects, security headers, and the certificate chain and expiry.
- DNS — delegation consistency between parent and zone, name server responses, SOA values, DNSSEC, and CAA.
- Registration — registrar, creation and expiry dates, and transfer locks.
Triage: what to fix first
Work in this order, regardless of what looks most alarming.
1. Things that are breaking delivery today
A blocklist listing, a domain with no MX record, an SPF record returning a permanent error, a mail server refusing connections, a site returning a 5xx. These have current, measurable cost: mail bouncing, customers unable to reach you. Fix them before anything else, even if each one is only a single error in the report.
2. Things that will break on a known date
A certificate expiring in nine days. A domain registration expiring next month. These are not hurting you yet, and they are guaranteed to hurt you later. They are also the cheapest items on the list to resolve, because they need a calendar entry and a renewal rather than a diagnosis.
3. Things that weaken you
A DMARC policy still at p=none. Missing DNSSEC or CAA. A single name server. No MTA-STS. None of these cause an outage on their own; each one removes a layer of protection or resilience. Schedule them, do them properly, and do not let them distract from the first two groups.
4. Informational findings
Notes about how your setup works rather than problems with it. Read them once so nothing surprises you later.
What breaks without it
The failure mode here is not technical, it is human: a long list of findings with no order to it produces either paralysis or the wrong work.
Teams routinely spend an afternoon enabling DNSSEC — worthwhile, but nothing was on fire — while a compromised mailbox keeps their sending address listed and their invoices keep bouncing. Or they chase every warning to reach a perfect score, when several warnings are deliberate choices for their setup and the score was never the point.
A report read in the wrong order also hides trends. If you only ever look at today's number, you cannot tell whether an 84 is a domain slowly improving from 60 or one sliding down from 95.
How to check it in 30 seconds
Run a Domain Health report on your domain and read it in this order:
- The status, to know whether anything is wrong right now.
- The Problems tab, which lists every error and warning together, most severe first.
- The category tiles, to see where the damage is concentrated.
- The score, last — as a way to measure the effect of your fixes, not as the thing to optimise.
If the findings are all on the mail side, Email Health gives the same treatment to authentication and deliverability alone, in more detail.
A worked example
A report comes back at 84 (B) with Problems found: five errors, two warnings, seventy passes. The category tiles show all five errors in Blacklist, both warnings in Mail Server, and nothing in Web Server, DNS or Registration.
That distribution tells you almost everything. DNS and web are healthy, which is why the average stays in the eighties. The Blacklist component has collapsed — five errors takes it to 25 — and the two Mail Server warnings are missing MTA-STS and TLS-RPT, which are group-three items.
So the entire Monday morning is one task: find out why those addresses are listed and deal with the cause, using how blacklists work. The transport policies can wait for a quiet afternoon. Chasing the B grade itself would have been the wrong instinct.
Fix it
- List the errors first, in the order the report gives them.
- Separate them into "costing me today", "will cost me on a date", and "makes me weaker".
- Do every item in the first group before starting the second.
- Put the dated items in a calendar as well as a ticket — a warning you scroll past is not a plan.
- Re-run the report after each fix; authoritative checks show the change immediately, with no waiting for caches.
- Record the score after the work, so the next report has something to compare against.
Then keep it that way
A report is a snapshot. Monitoring turns it into a line.
Once a domain is added to your account, StatusDNS re-runs these checks on the schedule your plan allows, stores each result, and recalculates the score using exactly the rules above. The domain page shows the score over time, the status of each monitor, and what changed between runs — so a drop from 91 to 76 comes with the specific check that caused it, not just a smaller number.
State changes generate alerts by email, and on plans that include them by Slack or webhook: new blocklist listings, DNS records added or removed, checks that start failing, and certificate or registration expiries as their dates approach. The reasoning behind the cadence is in why checking once is not the same as monitoring.