DNS diagnostics: controlled error checks and authentication study protocol

Observed controlled-test findings — 16 September 2026

Three selected DNS diagnostic checks passed; received-message authentication behavior remains unmeasured.

These checks do not validate SPF recursion, DKIM signatures, message alignment, forwarding effects, receiver decisions or the incidence of real authentication failures.

1. TestDomainValidation rejected the six invalid forms in its fixture and normalized the supplied HTTPS domain input. This is input handling, not ownership or authentication proof.
2. TestUnavailableDNSDoesNotPass used a canceled context. All four returned diagnostics avoided pass status, and no website-IP rDNS result was substituted.
3. TestDNSPolicyParsing kept p=none distinct from sp=reject and did not mistake an include domain containing “all” for an SPF -all mechanism.

Define the decision

A limited controlled software investigation was completed on 16 September 2026 against implementation e77303e. Its observations are reported below. The broader field-study protocol remains unperformed; software fixtures are not campaign or participant data. The decision is: Which configuration failures explain an authentication result, and which are forwarding or alignment effects? The observation unit is one received message with its original headers. Define the population and owner before collecting records; do not substitute an available convenience dataset without documenting the change.

Work through the procedure

1. Record envelope sender, visible From, DKIM d=, receiver Authentication-Results and DNS capture time. Separate direct delivery from forwarding.
2. Use owned test domains and controlled receivers. Change one configuration at a time; retain a known-good control. Never break production DNS for this study.
3. Before collection, write the primary outcome, observation window, exclusion rules and stopping conditions. Preserve excluded observations with a reason rather than quietly removing them.
4. Pilot the procedure with fictional or owned test data, resolve ambiguous fields, and freeze a dated protocol version before the main run.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

direct delivery; SPF pass; DKIM pass; DMARC fail; visible From differs from both authenticated domains
Suggested record fields: observation_id, condition, evidence_reference, outcome, exclusion_reason, reviewer, protocol_version
Status: illustrative record only; this example is not an observed result. See the separate controlled findings above.

Read the result

Classify authentication mechanism failures separately from alignment failures. A receiver header is evidence for that message, not every provider. Keep the numerator, denominator and missing evidence visible. If the available observations cannot answer the registered question, report that limitation rather than selecting a more favorable metric after collection.

Collect the evidence

Observation unit: message.

Owned test domains and original received headers; do not change production DNS.

Preserve one known-good control; change a single configuration at a time.

Analysis: Authentication failures by mechanism and alignment, with unavailable checks separate.

Download the JSON collection template under Source references. Set an owner, eligibility rules, outcome definition, observation window and sample justification before collecting records. Templates contain no participant data or results; keep original private records outside the public website.

Check before moving on

1. Name the person responsible for collection and review.
2. Check that the evidence can be inspected without exposing private messages or credentials.
3. Record deviations from the protocol and analyze their possible effect.
4. Retain a dated, redacted evidence worksheet with the final interpretation.

Limits and next action

A missing header or changed DNS snapshot is an unresolved observation, not proof of failure. Publish results only after the evidence, method and limitations have been reviewed. This protocol provides no benchmark, expected lift or completed field-study claim.

Source: Method or workflow reference