Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Choose representative scenarios
Start with the mail your organization must preserve. Include an aligned direct sender, an authenticated but unaligned service, a forwarding path, an unknown source on shared infrastructure and a missing-evidence case. Define what a reviewer should learn from each scenario before showing it to a supplier. Use fictional or appropriately redacted material and keep every candidate on the same evidence version.
A platform evaluation should distinguish protocol interpretation, investigation workflow, evidence export and operational responsibility. A polished dashboard may parse a report correctly while leaving ownership unresolved. Another system may make uncertainty visible but need more operator time. Preserve both observations rather than reducing them to one unexplained score.
Require evidence at each decision
For each scenario, specify the raw input, expected interpretation, acceptable uncertainty, operator action and artifact required to prove completion. For an unaligned service, a useful answer identifies the authenticated domain, visible From domain and missing alignment. It should not declare the service malicious solely because those identities differ. For shared infrastructure, require a confidence label and a verification request to an accountable owner.
The checkpoint's scenario pack supplies explicit expected outcomes and an observed local evaluator result. The evaluator checks only exact-domain identity comparisons and bounded classification rules. It does not parse raw DMARC reports, validate DNS, verify signatures or exercise any commercial platform. The pack is a reproducible starting point for a controlled evaluation, not a benchmark result.
Use acceptance gates before weighting preferences
Treat preservation of raw evidence, correct handling of unknowns and reliable export as gates if they are essential to your operations. Then compare operator effort and usability using recorded tasks and consistent starting conditions. Record interventions by the vendor or test operator because those interventions change what the demonstration proves. Do not substitute unverified product promises for observed outcomes.
No competitor ranking or product-specific assertion is supplied. Use current documentation and authorized tenant tests before drawing a purchasing conclusion. A shared scenario method supports consistent evaluation, but does not substitute for evidence about the particular implementation you are considering.
Completed scenario and effort matrix
The fictional matrix pairs each case with a required classification and retained normalized input. Direct mail requires aligned_exact_domain and an assumed ten operator minutes. An authenticated unaligned service requires unaligned_exact_domain and twenty minutes. Forwarded mail with stipulated surviving aligned DKIM requires aligned_exact_domain and twenty-five minutes. Shared infrastructure without a stipulated aligned authentication path requires unaligned_exact_domain, but its business legitimacy remains unknown; allow thirty minutes for investigation. Missing received evidence requires unknown and fifteen minutes.
These five estimates total one hundred minutes. Observed operator time is deliberately null because no human or commercial workflow was timed. The evaluation mail administrator operates each case, the evaluation owner approves conclusions, and every case requires export of the input, result and unresolved action before exit. The supplied local matrix checks classification only. Owner confirmation, current product capability and live sending evidence remain separate evaluation requirements rather than automatically passed cells.
Reproduce and extend the evidence
From evidence/fixtures/batch0662_v2/ in this review package, run python fixtures.py. Read evidence/fixture_results.json alongside evidence/inputs.json and retain the script and input hashes with any rerun. The script uses only Python standard-library components and performs no external sending, account access or production configuration changes. Its assertions check the stated fictional cases and negative controls. A passing local assertion is evidence of this bounded test, not proof of a provider capability. Before using the method for a live decision, replace invented inputs with authorized observations, preserve the original version and record any deviations from the method.
For the revised matrix, scoped controls and decision ledgers, also run python revision_fixtures.py from that same folder and inspect evidence/revision_results.json. The two proof-of-concept exports preserve baseline and deliberately mutated outputs separately.
Retained local test files
The review package retains the exact original scripts under evidence/fixtures/batch0662_v2/. Original outputs are preserved in prior_evidence/ and the rerun outputs in evidence/ beneath that folder. All relevant scripts were rerun successfully in this review. The SMTP fixtures bind only to 127.0.0.1; the evaluation fixtures are offline. These bounded local outcomes do not demonstrate any public-provider or production-mail result.