Make interoperability a reproducible comparison
A statement that a receiver supports updated DMARC is not an interoperability result. The useful question is whether identified implementations, given controlled equivalent inputs, produce the expected discovery, alignment, policy and reporting behavior. A comparison needs to preserve those stages rather than reducing the experiment to whether two messages reached an inbox.
Begin with a versioned case catalogue and a named test owner. Record the receiver software or service, configuration, accessible version information and any unknowns. A managed service may not disclose its implementation version; that limitation belongs in the matrix. Do not replace missing information with an adoption claim derived from a product announcement or a recent report timestamp.
Freeze the inputs that could change the result
For each case, retain the message bytes, envelope and connecting-source assumptions, relevant DNS data, observation timing and configuration profile. Make differences between two test runs intentional and visible. If one route modifies a signed message or uses a different envelope domain, the comparison is no longer solely about DMARC implementation behavior.
Use only authorized domains, receivers and controlled non-sensitive messages. Keep fictional design cases separate from executable fixtures and actual delivery samples. Write the expected result and its specification reference before running a test; otherwise a surprising outcome can be retroactively described as expected. An unrun case should remain explicitly not run, not receive a pass inferred from documentation.
The sender inventory also matters. Include representative legitimate routes, especially indirect and periodic services, when deciding whether laboratory coverage is relevant to a production change. A protocol case can be correct while omitting the business flow that will actually be affected.
Compare discovery and alignment before disposition
RFC 9989 section 4.10 describes DNS tree-walk behavior, while earlier implementations can use their supported legacy discovery method. Cases should cover an explicit Author Domain policy and controlled fallback arrangements. Add applicable subdomain and non-existent-domain policy cases only with clearly specified DNS conditions; a label saying subdomain is not enough to define the expected policy.
Capture the record selected and the authenticated identifiers used for alignment. Then record the selected p, sp or np policy and testing state. RFC 9989 section 4.4 defines the alignment relationship. Passing SPF or DKIM for an unrelated identity must not be mislabeled as successful DMARC merely because a receiver ultimately accepted the message.
Finally record local overrides and actual disposition as separate outcomes. Content filtering, routing and local decisions can create different delivery results even when the ordinary DMARC calculation agrees. Diagnose the earliest differing stage rather than attributing every mailbox difference to policy discovery.
Include the testing transition without assuming equivalence
A useful case compares how identified implementations process a record containing p=reject and t=y. Under RFC 9989 section 4.7, the testing treatment for a failing message is one level lower, quarantine. A legacy implementation that does not recognize t may follow different supported logic. This is an expected compatibility question to measure, not a reason to deploy that record as a universal safety switch.
Separate historical pct cases from t cases. A plan that once requested sampling should not be declared compatible merely because an updated receiver ignores the old control without a syntax error. The intended business effect, the specified mechanism and the observed result all need their own fields.
Retain unknown-tag, missing-policy and malformed-input cases within a controlled test scope. Do not use a production domain as an experimental target for deliberately ambiguous records. Test design itself should identify the relevant approval and recovery requirements before any operational execution.
Test reporting as a separate capability
RFC 9990 defines aggregate-report structure, including optional discovery_method and testing context. A report carrying those fields can support an observation about that report; an omitted optional field does not prove legacy behavior. Preserve the raw report and parser profile, because a consumer can lose information even when the receiver generated it correctly.
Report periods can include policy transitions, so one aggregate is not always a transcript of a single frozen policy. Align the comparison's time window and source evidence before using counts to explain a particular message. Deduplication and schema compatibility belong to the reporting test plan rather than being hidden in a dashboard.
Failure reporting is another independent dimension. RFC 9991 leaves generation subject to receiver willingness and privacy constraints. No failure report is not sufficient evidence of a failed interoperability test. Record whether reporting was requested, supported, authorized, received and interpretable without collecting unnecessary message content.
Fictional matrix with no observed outcome cells
A fictional worksheet names Receiver A as a current-semantics reference and Receiver B as a legacy profile. Both are assigned the same invented message and DNS snapshot for the p=reject;t=y case. The expected-policy column for A is derived from the specification. B's implementation and all actual outcomes still require evidence; no product is presumed to behave like the label.
The planned matrix also includes a direct aligned control, an unrelated authenticated-domain case, a fallback discovery case and aggregate-format cases. Every execution cell remains not run. This makes the worksheet useful preparation without manufacturing proof of conformance or receiver adoption.
Preserve the exact release requirement
The original evidence gate is: Keep a versioned interoperability matrix with identical input cases and full observed outcomes. The commissioning requirement is: Validate current primary specifications and retain a worked example before drafting. The retained fictional matrix satisfies neither live observation nor production readiness. Named implementation evidence, controlled results, human SME review, business rollout approval and publication authorization remain open. This manuscript has performed no receiver test, DNS change or message transmission.