How DNS Doctor decides each verdict
Every verdict is deterministic and reproducible. This page is the citable source for how the numbers are counted and where DNS Doctor deliberately refuses to guess.
How DNS Doctor counts SPF lookups
SPF allows at most 10 DNS lookups when a record is evaluated (RFC 7208 §4.6.4). DNS Doctor counts them in code, following includes recursively, so the count is authoritative rather than a guess — a record that resolves to more than 10 lookups returns a permanent error at receivers and stops authenticating your mail, even though the record still looks valid.
Each of these mechanisms costs one lookup: include, a, mx, ptr, exists, and the redirect= modifier. The all, ip4, and ip6 mechanisms cost zero — they resolve no DNS. A nested include adds its own lookups on top, resolved recursively against live DNS, which is why a record with only a handful of visible terms can still blow the limit through a provider's deep include chain.
The counter is the same deterministic engine the free SPF lookup counter and the scanner use, so the number you see is the number a receiver computes. SPF is diagnose-only: DNS Doctor never auto-generates a shorter SPF record, because mechanically trimming a policy can silently de-authorize a real sender. It names the offending mechanism and leaves the fix to a human who knows which senders are legitimate.
Why p=reject requires an alignment signal
DNS Doctor only recommends a rejecting DMARC policy (p=reject) when there is evidence that your legitimate mail is aligned — a passing, aligned SPF result and a DKIM signature. Without that signal it caps its recommendation at quarantine. Moving to reject without alignment does not stop spoofing; it silently rejects your own mail.
A single scan can see whether SPF passes with alignment and whether a DKIM selector is published, and that gate decides whether the scanner suggests reject or caps at quarantine. Reaching enforcement safely, though, is not a point-in-time question — it needs roughly 30 days of aggregate (RUA) report evidence.
The monitoring readiness engine unlocks the next policy step only when every known sending source is at least 99% aligned over the trailing 30-day window, the unaligned share of unknown mail stays under 0.5% of volume, and the window actually contains mail. Aligned mail already passes at reject by definition, so a fully-aligned forwarder never blocks the upgrade — only the unaligned unknown share does. The record itself is generated and validated by the deterministic engine; the AI layer never writes it.
A temporary failure is never a failure
When a DNS lookup fails transiently, DNS Doctor reports temperror — a distinct, honest state — and never a failing verdict. Telling you your domain is broken because a resolver timed out would be worse than saying nothing. The same discipline applies everywhere the truth is "we could not check" rather than "this is wrong".
temperror is excluded from the gradeable set, because a timeout is missing evidence, not a finding — it is never counted as a failure. It is not simply ignored, though: if SPF or DMARC is the check that could not be resolved, the grade is re-set to B and marked incomplete, so a missing signal never reads as a clean bill of health. DKIM is reported as "checked common selectors" — a selector we did not find is reported as not-found for the selectors we tried, never as a definitive "you have no DKIM", because DKIM selectors are chosen by the sending platform and there is no way to enumerate them all.
Blacklist checks are equally careful about what they can and cannot assert. Spamhaus is deliberately not queried through public resolvers — it returns a special code to high-volume public queries that is easy to misread as a listing — so the report carries an honest "not checked" line rather than a fabricated "blacklisted". Every check returns one of pass, warn, fail, info, or temperror, and info covers the honest "not found / unavailable" cases.
How the A–F grade is computed
The letter grade is a pure function of the check verdicts, applied by a fixed, versioned rubric (v1). SPF and DMARC carry the most weight because they decide whether spoofed mail is delivered; temporary failures are never counted as findings, and if SPF or DMARC could not be resolved the grade is set to B and marked incomplete rather than reported as if we had the evidence.
Both SPF and DMARC failing grades an F. Either one failing grades a D. Any other check failing (DKIM, MX, DNS, expiry, blacklist) grades a C. Any warning grades a B. All gradeable checks passing grades an A. temperror and info checks are excluded from the gradeable set; if SPF or DMARC ends up excluded that way, the grade becomes B and is flagged incomplete — deliberately in both directions, so a missing signal never reads as a clean bill of health and a resolver timeout never reads as a failing one.
The rubric is a stable public contract — it feeds report titles and preview images — so any change to it is versioned and recorded, never a silent re-weighting.
The same deterministic engine is available programmatically: a public REST API v1 and an MCP server at /mcp. The full machine-readable contract lives at /llms-full.txt. An agent gets a validated record, never a generated guess.