Assess the evidence before assigning severity
A domain-health assessment should explain which authentication dependencies were checked, what the observations support and what remains unknown. A single score can hide the difference between a broken production sender, an untested selector and an unrelated website issue. This is a diagnostic guide and proposed assessment design, not a functioning EmailAuth scanner. No customer domain has been queried and no live result is presented.
Start with the intended use of each domain: active employee mail, application mail, marketing, receiving-only or deliberately non-sending. Identify the business owner and known senders. The same missing record can have different consequences in different contexts, and a configuration that looks restrictive may disrupt legitimate indirect mail. Prioritize an evidenced business risk, not the number of colored warnings a page can display.
Preserve a reproducible observation
For every proposed check, record the exact domain or owner name, query type, observation time, resolver or authoritative server, response status and relevant answer data. Distinguish an authoritative observation from a cached recursive answer. RFC 1034 describes these roles; the control panel where an administrator edits a record is not itself proof of the answer a receiver obtained.
Classify missing data carefully. NXDOMAIN, an existing name without the requested type, a referral, an alias chain and SERVFAIL are not interchangeable. RFC 2308 distinguishes negative responses and the context needed to interpret them. An empty answer section alone does not prove NODATA. Keep timeout and resolution failure visible rather than converting them into a permanent configuration finding.
Record caching and collection limits without promising that a particular delay proves worldwide convergence. A retry from one resolver may clarify a transient problem but does not reconstruct the original receiver's view. The assessment must preserve uncertainty when the underlying observation is incomplete.
Check SPF as an evaluated authorization policy
Locate the SPF policy for the actual SPF identity, not automatically the visible From domain. RFC 7208 requires record selection and distinguishes no record from multiple matching records. Several strings within one TXT record are not automatically several SPF records. Preserve the resource-record structure when explaining a syntax finding.
For a message-specific evaluation, record the connecting IP and relevant envelope identity, including the HELO case when applicable. Check the evaluated mechanisms and their DNS dependencies. The ten-lookup limit concerns specified DNS-querying terms during evaluation, including recursive processing; it is not simply a count of every DNS packet or every word in the policy. Section 4.6.4 also defines additional limits. Explain the failing path rather than suggesting indiscriminate record flattening.
Distinguish permanent policy errors from temporary DNS problems and from a valid policy that does not authorize a particular source. A syntactically valid record can still omit a legitimate sender or authorize too much. Business ownership is needed to decide whether a source should be present.
Require selector and message evidence for DKIM
A domain name alone does not enumerate every DKIM selector in use. Obtain selector and signing-domain values from authorized message evidence or a verified sender inventory. RFC 6376 explains selector use. An unsuccessful guess at a common selector is not evidence that the entire domain lacks DKIM.
Check the selected public key and algorithm under applicable updates, including RFC 8301. A published key establishes a DNS dependency, not that a sender possesses the private key, signs the intended traffic or produces signatures that survive transit. Inspect actual receiver-side verification evidence when authorized. Protect message content and private keys; neither belongs in a public diagnostic report merely to make an example look complete.
Evaluate DMARC and operational impact separately
Current DMARC needs an eligible passing mechanism aligned with the Author Domain. Raw SPF and DKIM success can coexist with DMARC failure when their domains do not align. Record the policy discovery and identifier assumptions, particularly where current DNS Tree Walk behavior and legacy implementations may differ. Do not treat a policy string as proof that every receiver follows the same implementation.
Prioritize confirmed disruption to critical legitimate traffic, then unresolved dependencies with material exposure, then lower-impact hygiene work. Keep the proposed severity rationale visible. A p=reject record alone does not complete an authentication program, and applying it indiscriminately can harm general-purpose domains with indirect mail flows. Receiver handling, sender ownership and monitoring continuity need separate review.
In a fictional assessment, receipts.example has a documented payment-mail sender whose observed DKIM verification fails, while a guessed unused selector also returns no record. The first finding deserves investigation because it concerns a known business flow; the second remains inconclusive. Neither observation occurred here. The example illustrates how context changes priority without inventing a real diagnostic transcript.
Verify the correction and the assessment itself
For each finding, specify the proposed action, approver, expected observation and safe recovery condition. Repeat the relevant check after an authorized correction and compare evidence rather than only comparing scores. RFC 8601 requires attention to the trust boundary of authentication-result headers. Final SMTP acceptance also does not establish inbox placement, as the transport responsibilities in RFC 5321 make clear.
A working assessment needs tests for valid inputs, malformed records, aliases, negative responses, temporary failures, missing selectors and unsupported cases, with expected outcomes and explained errors. The exact commissioning requirement remains open: A functioning tool with expected-result fixtures, original inputs, observation time and explained errors. This guide and its proposed map do not satisfy that tool gate. Publication as a working resource requires implementation, authorized original observations and reproducible tests, followed by technical and owner approval.