Define the question before choosing software
A DKIM2 lab should resolve a narrow uncertainty, such as whether two implementations reconstruct the same modified message or classify an envelope mismatch consistently. “See whether DKIM2 works” is too broad to produce an interpretable result. Write a question, a version scope and a pass/fail criterion before selecting a fixture. Keep a separate decision for whether any observed result would justify further experimentation, not automatic production adoption.
As reviewed on 8 November 2026, core spec-09 is an active Internet-Draft dated 1 November, while DNS-03 is dated 2 November and BCP-01 is dated 9 September. Pin all documents a case depends on. A software label saying “DKIM2” is insufficient if its parser follows a previous revision or a separate profile with different coverage.
Distinguish a reported implementation from a selected build
The Milter deployment-profile -08 draft reports DarkChain and DarkChains as beta code for that individual profile. Its status section explicitly disclaims verification of contributor-supplied information and IETF endorsement. That is a lead for an evaluator, not an independently tested recommendation. The profile's limited and extended functions must not be silently equated with every requirement in the WG core draft.
Before running software, an approved plan should identify repository provenance, immutable commit or release, build configuration, cryptographic libraries and the claimed protocol/profile coverage. Record unsupported features as unsupported, not as failed tests of a different implementation promise. Installation and execution are separate operational actions; no source checkout, build, installation or mail transaction was performed for this package.
Build a small case set with meaningful contrasts
Start with an existing classic-DKIM baseline to ensure the test harness is not confusing ordinary mail handling with experimental behavior. Then specify a fictional unchanged DKIM2 path, a declared footer modification and an undeclared alteration. Keep the original and modified message bytes in the eventual controlled fixture. If a case changes several variables at once, a failure may reveal little about the mechanism being investigated.
Add an envelope mismatch, a null body recipe and a temporary DNS failure. Under core -09 sections 13–14, these are not interchangeable “bad mail” cases. A null body recipe prevents checking earlier body state; a temporary key lookup problem has a different result category from completed verification that fails. Preserve the exact diagnostic and the missing input.
A timestamp case should retain the original SMTP acceptance time. A replay-related case should distinguish intended distribution, unexpected onward delivery and repeated observations of the original instance. Mark every expected result as a hypothesis until software actually produces an observation. This package supplies an original case design, not executed sample messages or a results table with fabricated passes.
Preserve the inputs needed for reproduction
For each authorized run, record an opaque case identifier, message-byte hash, envelope sender and recipients, acceptance time, signer and verifier versions, key snapshot and relevant policy records. Store original messages and private data only under the approved access and retention plan. A hash identifies an artifact; it does not reconstruct missing bytes or prove that a diagnostic came from the claimed program.
Separate expected result, observed result and reviewer interpretation. Keep intermediate outputs for candidate failures: recipe reconstruction, signature verification, chain checks and domain matching. If the harness never reached the intended check because parsing failed first, record that fact. Do not report a downstream feature as tested merely because the overall run returned an error.
Use a second implementation only after checking that it targets the same pinned behavior. Agreement between two programs is useful but not absolute proof of correctness; they may share code or the same mistaken assumption. Disagreement is likewise not automatically a defect if one implements an older draft. The version comparison belongs beside the result, not hidden in a footnote.
Review safety and privacy before execution
Recipes can preserve material removed from the visible message. Synthetic content is therefore preferable for an initial lab: a reversible redaction test should not reintroduce a real secret into the evidence archive. Use controlled recipients, isolated signing keys and a namespace whose owner approved the experiment. Set limits that prevent unintended delivery, forwarding loops or unsolicited replay traffic.
Specify stop conditions for unexplained outbound mail, unexpected recipient expansion, production DNS impact or sensitive content appearing in logs. Do not disable established authentication or filtering simply to obtain a clean experimental success. Cleanup should cover test signing, records, artifacts and credentials, with retention needs documented separately. An experiment is not complete merely because the last message was delivered.
Keep reporting and deployment conclusions modest
The BCP-01 draft discusses mixed DKIM1/DKIM2 operation and leaves aspects of DMARC integration open. Published RFC 9989 still defines its own authentication mechanisms. A lab result cannot amend that specification or establish that every external receiver interprets the experimental message in the same way.
Similarly, RFC 9990 aggregate reporting and RFC 9991 failure reporting are not generic transports for whatever experimental fields a developer would like to collect. Keep local lab diagnostics distinct from supported report formats. A missing external report is not proof of rejection, and a received report does not automatically expose the complete DKIM2 verification path.
State the unfinished evidence plainly
The exact commission is: Record lab scope, versions, cases, results and the boundary between experiment and production. Scope, current document versions and proposed cases are retained here. Software pins, actual runs, observed results, reproducibility checks and verified cleanup are absent. The original-evidence gate therefore remains open; no lab success, security guarantee or EmailAuth capability is claimed.
A technical owner should approve the protocol interpretation, a security owner should authorize any real experiment, and an independent reviewer should assess the resulting evidence before a next-stage decision. Production applicability, site and visual acceptance, and publication permission remain separate gates. A good lab produces a bounded answer that another engineer can challenge, not a new production requirement inferred from an unfinished standard.