Reading statuses: PASS, IMPROVE, RISK and UNKNOWN

Status, severity and coverage are three different things

A DNS Tools result answers three separate questions. Status says what was verified for a given check. Severity says how much an adverse finding matters. Coverage says how many of the planned checks reached a conclusion. Keeping them apart avoids a common misreading, in which a missing result is taken as a good one.

Only IMPROVE and RISK carry a severity. Every other status has severity none.

PASS

PASS means a protective control was verified. The check ran, obtained reliable evidence and found the control in place, for example a valid DMARC record with an enforcing policy. PASS is a statement about that single control. It does not mean the whole domain is secure.

IMPROVE

IMPROVE means a weakness or improvement opportunity was verified. A recognised protective control is available but is not in place or not enforced. It does not mean vulnerable. An example is a site that serves HTTPS but does not send an HSTS header.

An IMPROVE finding carries a severity of LOW or MEDIUM. The model caps it there on purpose: on its own, an improvement is never HIGH or CRITICAL.

RISK

RISK means a verified material security concern. The evidence shows something that meaningfully weakens the domain, such as a certificate that has expired. A RISK finding carries a severity from LOW to CRITICAL, and any HIGH or CRITICAL RISK finding makes the overall posture High Risk.

UNKNOWN

UNKNOWN means there was insufficient reliable evidence to conclude anything. A server timed out, a query did not complete, a module hit its time limit, or a planned check never reported. UNKNOWN is counted neither as clean nor as adverse. It is a gap in coverage.

This is the most important rule in the product: UNKNOWN is never clean. If the three core checks, DMARC, SPF and MX records, are UNKNOWN and nothing adverse was found, the posture is Unknown and no posture is asserted. Re-run the assessment later, or verify the control directly.

NOT_APPLICABLE and INFORMATIONAL

NOT_APPLICABLE means the check does not apply to this domain, for example SMTP transport on a domain that publishes a null MX. It counts as concluded, because the question was answered, but it is not a pass.

INFORMATIONAL means an observation was recorded without an adverse security conclusion, such as the set of nameservers in use. It also counts as concluded.

NOT CONFIGURED

NOT CONFIGURED means an optional capability is not enabled on this server. The usual case is reputation providers. It says nothing about the domain. It is outside both the concluded and the unknown counts, so an optional source that was never enabled cannot make a completed assessment look failed or incomplete, and it must never be read as clean.

Coverage and assessment state

Coverage is the number of planned checks that reached a conclusion, as a share of planned checks. A check is concluded if its status is PASS, IMPROVE, RISK, NOT_APPLICABLE or INFORMATIONAL. UNKNOWN checks are the gap. NOT CONFIGURED checks are excluded from the planned total.

A scan with no UNKNOWN checks is complete. A scan that finished with at least one UNKNOWN check is partial, and its checks are listed with the reason each one could not be concluded.

Overall posture and why it can be provisional

Posture is derived from the findings, in this order: any HIGH or CRITICAL RISK gives High Risk; any other RISK or a MEDIUM IMPROVE gives Needs Attention; missing core checks with nothing adverse gives Unknown; only low-severity improvements gives Good; otherwise Strong.

If any check is UNKNOWN, a Good or Strong posture is marked provisional, because the unresolved checks could change the reading. Each category (such as Email authentication or Website security) gets its own label by the same logic.

Worked examples

Consider a domain whose DMARC record exists with a policy of none, whose SPF record is valid, and whose MX records resolve. The DMARC check is IMPROVE with a severity that is at most MEDIUM, because monitoring is in place but nothing is enforced. SPF and MX are PASS. Coverage is complete if every other planned check also concluded, and the posture is Good or Needs Attention depending on the severity given to the DMARC finding.

Now consider a domain whose mail server did not answer within the time limit. The SMTP check is UNKNOWN, with the reason shown. It does not appear as a weakness, because nothing adverse was verified, but it also does not appear as a pass. Coverage falls below one hundred percent, the scan is marked partial, and any Good or Strong posture is labelled provisional.

Finally, consider a domain with no reputation provider enabled on the server. The reputation check is NOT CONFIGURED. Coverage is unaffected and the scan can still be complete, but the reputation category is labelled Not configured, and you should not read that label as a clean bill of health.

Common misreadings

A few errors recur when people read results for the first time.

• Reading a high percentage of coverage as a good score. Coverage measures how much was verified, not how well the domain is protected.
• Reading IMPROVE as a failure. It is a verified opportunity, and a low-severity IMPROVE is consistent with a Good posture.
• Reading NOT_APPLICABLE as PASS. The check did not apply; it did not verify a control.
• Ignoring UNKNOWN because nothing red appeared. Open each one and read the reason.
• Assuming severity is a probability. It describes how much an adverse finding matters, not how likely it is to be exploited.

A short reading routine

Use the same routine each time so that gaps do not get lost.

1. Read the coverage statement first. Note how many checks were not concluded.
2. Open every UNKNOWN item and read its reason before reading the posture.
3. Work through RISK items, then IMPROVE items, in the order shown.
4. Ignore NOT CONFIGURED items for the posture, but remember what they mean.
5. After a change, re-run and compare, rather than assuming the change worked.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09