Domain Health Report Fields

The field reference for the report datapulse_live_domain_health returns in raw_output. For what the tool does, how to call it and how to read the verdict, see datapulse_help(topic="domain_health").

Conventions

• Arrays are always present, never null; an empty list is []. Booleans are always present.

• The report distinguishes “we looked and the answer is no” from “we could not tell”, everywhere. Several checks can come back not-determined, and each says so in its own way:

  Field	Not determined as
  nameservers.serials_consistent	null
  nameservers.ipv4_prefixes_24, ipv6_prefixes_48	null
  web.*.*[].tls.tls10, tls11	null (reports since 2026-10-05, ad5846c; earlier builds wrote false)
  wildcard.consistent	null
  caa.hosts.*.permitted	absent, with note saying why
  mail.dmarc.unresolved	true
  wildcard.status	"unknown"
  tlsa.result	"unknown"
  hsts_preload	"unknown", with hsts_preload_error
  dns.resolver_reachable.*	a skipped: string

  Not determined is neither the good case nor the bad one. Branch three ways.

  Both shortcuts are wrong, in opposite directions. Folding null into the pass reports a clean audit for a run that checked nothing. Folding it into the fail is worse: if serials_consistent is not true then the servers disagree turns “no nameserver answered” into “the nameservers disagree with each other”, which is an affirmative finding someone will act on. The same inversion hides in if prefixes == 0 then there is no diversity and in if wildcard.status != "present" then there is no wildcard, which folds unknown into absent.

  if serials_consistent is null:  not determined — say so, or omit the finding
  elif serials_consistent:        the serials agree
  else:                           the serials disagree
  

• wildcard.status is the same three-way choice carried as a value rather than a null: present, absent, unknown.

• A zone no delegated nameserver answers for is reported as the single finding zone_unreachable and the probe stops there: web is {}, and mail, caa, tlsa, wildcard and the hsts_preload keys are absent, because every one of those checks needs an answer from the zone. delegation, dns, dnssec and the nameservers audit that established it are present.

• An object is omitted only when the whole check did not apply: mail and nameservers for a name that is not a zone apex, mail also for a name that cannot receive mail at all (one carrying reserved_name or public_suffix, or one that does not exist), web.www for anything that is not a registrable domain, glue when the parent could not be asked, tls when 443 did not answer, quic when the probe was not run, hsts when no header was served, web.apex / web.www (and web itself, as {}) when the name resolved to no usable addresses.

• Optional scalars appear only when they have a value: unicode_domain, not_a_zone, enclosing_zone, reserved_addresses, hsts_preload_covered_by, hsts_preload_policy, hsts_preload_include_subdomains, hsts_preload_error, deadline_reached, cname, retries, ede, detail, parent_only, child_only, error.

• Key on findings[].code, which never changes once shipped; message wording may. On a report from before findings existed (before 2026-10-05), key on error and warning prefixes (apex: certificate expired, www (ipv4): redirect chain, nameserver <name>:, resolver returned SERVFAIL:, apex: CAA records do not permit, MTA-STS:, DKIM selector, HSTS).

• Findings are per host and cause, not per address, and carry a count: apex: certificate expired on 1 of 1 addresses: ..., apex: certificate handshake failed on 7 of 7 addresses: .... No address appears in a finding. Which address failed is in the web section, under web.apex.ipv4[].tls and its IPv6 equivalent. The nameserver findings already had this shape.

• Error text from a probe carries only the condition, not the socket that hit it: i/o timeout, not read tcp4 10.12.60.35:46962->80.245.156.34:443: i/o timeout. That applies to tls.error, the HTTP result error and the MTA-STS fetch error as well as the finding text, so two runs that failed the same way now compare equal instead of differing by an ephemeral port.

Top level

findings

Each entry is {code, severity, host, message}.

• severity is fail, warn or info, a closed set, and a code always has the same severity. fail entries are exactly errors and set ok to false. warn entries are exactly warnings, in the same order. info entries appear only in findings, except in reports from the first 2026-10-05 builds, which also listed them in warnings.
• warn is a defect worth fixing. info is a configuration fact that is normal for some well-run domains and is recorded rather than scored; it says something only when compared against a reference, which the probe does not hold.
• host is apex, www, a nameserver or MX host name, or empty for the domain as a whole.
• message states only what was observed; there is no advice or citation in it.

The severities were calibrated against 40 flagship apexes and 40 of their subdomains. A finding most of those operators carry is a choice, not a defect, and is info. On that set no warn code fires on more than 3 of the 80.

http_probe_refused is a 401, 403, 407, 417 or 429 on every address: large sites answer a non-browser client this way, so it says nothing about the site, while a 404 or 410 still warns. http_cleartext_preloaded is plain HTTP on a host the HSTS preload list covers, a request no browser makes.

http_response_inconsistent means one run asked the same URL more than once (once at each address) and got different answers, which the message lists with counts. It compares only what that run saw, so a server that varies, such as a CDN whose cache key ignores the Host header, can look consistent on one run and not the next; report it as observed in that run. redirect_self is an address answering a redirect to the very URL it was asked for. cert_mismatch_between_addresses fires only when addresses’ certificates differ in chain verdict or in the names they cover, not when a CDN merely serves different leaves.

Not produced since 2026-10-06. redirect_loop (fail) and redirect_downgrade, redirect_hop_limit, redirect_broken, redirect_ends_error (warn) came from following redirect chains, which the probe no longer does (redirect_log: false). They appear only in older reports. The browser’s chain is the scrape’s redirect_chain (datapulse_scrape_submit, datapulse_scrape_result, datapulse_domain_overview), where a loop, an https-to-http hop or a chain ending in 4xx/5xx is read directly from the hops.

dns

Each entry under dns.apex (keys A, AAAA, MX, NS, TXT) and dns.www (A, AAAA) has status (ok, nxrrset, nxdomain, failure, timeout), trust (secure, insecure, bogus; on an nxdomain lookup, secure means the denial of existence validated, not that the name is signed), records (rdata strings, when any), and optionally cname (chain followed), error, retries (a query retried after a timeout, the same key the nameserver audit uses). dns.resolver_reachable maps ipv4 / ipv6 to yes, no, or a string starting with skipped that names the reason. It measures the configured resolver, not the domain being probed: the check is exempt from dns_concurrency, so a target whose own nameservers hang cannot starve it and make a healthy resolver read no.

web

web.apex and web.www each have:

Each address entry:

What the TLS verdict covers, and what it does not. chain names the single most urgent defect; chain_problems lists every one of them, headline first. The badssl fallback certificate is both expired and served for a name it does not cover, and reads chain: "expired" with chain_problems: ["expired", "hostname_mismatch"]. Key on chain for a headline and iterate chain_problems before telling anyone the certificate is fixed, because renewing on the strength of chain alone would leave the site broken.

incomplete_chain and untrusted_root are close together and easy to confuse. incomplete_chain means the server did not send the intermediate, but the certificate’s AIA URL was fetched and that repair produced a chain that verifies. The URL is named in tls.error on the affected address, and only there: there is no AIA field on tls.cert. untrusted_root means the chain does not verify even with the intermediate supplied, whether or not an AIA fetch succeeded. The distinction cannot be read off the issuer’s name, because a certificate can be issued by a CA whose name is well known under a root no trust store carries.

valid and incomplete_chain differ in who has to do the repair, and that decides which clients break. A browser generally fetches the missing intermediate itself, so an incomplete chain often looks fine in Chrome while failing in curl, Java and some mobile clients. One address of a host can be misconfigured while its sibling is correct, so the same name can report valid and incomplete_chain at once, which is why every address is probed rather than one.

Live examples of incomplete_chain are transient by nature: a domain observed serving one certificate on one address may be repaired within hours, and un.org was fixed on 2026-09-07 between two probes. Treat a public domain as a snapshot, not a fixture.

valid means the chain as served verified against the trust store at probe time, with no repair needed. It is not a statement about revocation, which is not checked, so a revoked certificate whose chain is intact reports valid. cert.key and the signature algorithm are reported but not judged: there is no weak-key or weak-signature finding, so a 1024-bit RSA key appears in the output without a warning attached.

mail

Present only for a name that could configure mail: absent for a host inside a zone, for a reserved name, and for a name that does not exist. Its absence is the answer, not a gap.

nameservers (zone apexes only)

A nameserver’s verdict turns on whether it answered at all, not on how many addresses failed:

Answering with REFUSED on one address of nine is proven lameness and stays an error; a node that merely goes quiet while its siblings answer authoritatively is a warning, because a flaky anycast node is not a misconfiguration of the domain. The reason for a silent address is the fixed text no answer, rather than whichever of dig timed out or no servers could be reached arrived first, so the string no longer varies between runs on the same domain. | serials_consistent | Every server reported the same SOA serial, or null when no server answered authoritatively and nothing was compared. true means the serials were actually checked. The drift warning names the address as well as the name, because the disagreeing server is often one node behind an anycast address: aluminium-supplier.com has a node of dns9.hichina.com serving serial 2016081111 while its siblings serve 2026082616, a decade apart | | ipv4_prefixes_24, ipv6_prefixes_48 | Distinct prefixes across all addresses; 1 means no diversity, null means no address was examined | | glue | required (in-bailiwick names), missing, mismatch; omitted when the parent could not be asked, or when no nameserver address was known to compare it against | | ns_cname, unresolvable | NS names that are CNAMEs, or that the resolver said have no address. Both are errors | | unresolved | NS names whose address lookup never completed. A gap in the check rather than a fault in the domain, so it is a warning, not an error |

caa

caa contains hosts and nothing else: one verdict for apex and one for www, each judged against the certificate that host actually served. There is no domain-wide CAA verdict, because a domain need not have one.

Both arrays are always present. published empty alongside a non-empty effective is how the report says the set was inherited from the apex.

permitted is true when no records govern the name (any CA may issue). It is absent whenever nothing could be judged, and note distinguishes two materially different reasons, which a caller must not collapse:

• Nothing to check. no certificate observed, because the host serves no TLS, so there is no issuer to compare against the policy. This is by far the common case: in one 49-domain batch all 42 null verdicts were this one. The policy was read fine; there was simply nothing to judge against it.
• Could not check. The CAA lookup did not complete, so the policy itself is unknown. issuer not in the CAA mapping table is a third, narrower variant of the same idea.

The difference matters because “any CA may issue” is a security-relevant all-clear, and it is never derived from a query that failed. A host with no TLS is unremarkable; a policy that could not be read is a gap in the check.

A wildcard certificate is judged against issuewild when the governing set has one, so a CA that issue permits can still be forbidden for wildcards (RFC 8659 gives issuewild precedence for wildcards).

A CAA identifier need not resemble the issuer’s organisation name. A CA that has acquired other CAs honours each brand’s identifier at issuance, so posteo.de permits geotrust.com and is correctly served a certificate whose organisation reads DigiCert Inc, DigiCert having acquired GeoTrust. Reading caa.hosts.*.issuer beside published will therefore turn up pairs that look mismatched and are not, and the verdict in permitted accounts for the brands each CA issues under. Do not re-derive it by comparing the two strings yourself.

Two hosts can reach opposite verdicts from one CAA set, and that is not a bug. apache.org permits Let’s Encrypt at the apex and forbids it at www, from the same effective records and the same issuer. The apex is served a non-wildcard certificate, judged against issue, while www.apache.org is served *.apache.org, judged against issuewild, and the zone publishes issuewild "ssl.com" only. When two hosts disagree, check whether the served certificate is a wildcard before concluding the verdict is wrong.

tlsa

A domain where nothing could be determined

On 2026-09-07, while its nameservers were down, microsoft.jp.net fired every not-determined path at once. An earlier build asserted from those four failed lookups that it publishes no DMARC record, that any CA may issue for it, that it has no DANE, and that it has no wildcard. The same outage now yields mail.dmarc.unresolved, caa.hosts.*.permitted absent, tlsa.result: "unknown" and wildcard.status: "unknown", while still failing on what was actually observed: nameservers answering nothing, and www lookups timing out. Four confident negatives became four honest unknowns without losing a single real error.

Its nameservers have since recovered, so probing it today returns ordinary answers. That is the nature of live examples, and the reason this one is dated.

wildcard

Whether the zone answers names that were never published, tested by looking up random 12-letter labels.

unknown is the reason this is a tri-state. A single present: false previously covered NXDOMAIN, NODATA, timeout and failure alike, so a lookup that quietly failed was indistinguishable from a clean zone. Do not render unknown as false.

A wildcard on its own raises no warning; only www_via_wildcard produces one. It is data to score, not a fault. consistent: false is worth scoring separately, since a catch-all that rotates its answers is a different shape from a stable one.

Enumerations