Define what acceptance will mean
A domain portfolio can contain employee mail, transactional applications, marketing services, inactive names and delegated subdomains. One green check beside a corporate domain does not establish that these different routes behave correctly. An acceptance pack should define the domains, identities, implementations and routes being assessed before it lists tests. Its purpose is to support a bounded release decision, not to manufacture a universal compliance badge.
The current core DMARC specification is RFC 9989, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991. A migration review must distinguish those functions. The protocol record still identifies itself with v=DMARC1; a change in the specification does not create a DNS value named DMARC2. Keep the specification version and the on-wire record value as separate fields in the pack. RFC 9989, section 4.7 and Appendix C
Partition the portfolio by behavior, not just ownership
Create groups whose members share a meaningful operational property: an employee-mail route, a particular supplier integration, a delegated subdomain model or a non-sending policy scope. Preserve exceptions rather than forcing every domain into the same template. Two domains owned by the same business can use different providers and policy-discovery paths, while several brands may share one underlying route.
For each group, record the business owner, DNS owner, sending application, relevant From and authentication domains, and implementation under review. Separate a real production inventory from a proposed example list. A domain’s presence in an asset register does not prove that all its sending streams have been found. Unknown routes should remain visible as gaps, not be silently counted as accepted.
Decide what the pack can establish. Offline parser fixtures can demonstrate specified input handling under a named implementation, but they do not prove live DNS availability or received-message behavior. A DNS snapshot can support policy discovery at one time, but it does not show every receiver’s deployment. Keep these evidence levels explicit throughout the release decision.
Build distinct protocol test families
Policy tests should cover valid and invalid version placement and value, supported tags, policy discovery and the relevant DNS tree-walk behavior. Alignment tests should distinguish raw SPF or DKIM success from alignment with the RFC5322.From domain. Include cases where one aligned mechanism passes and another fails, so the pack does not accidentally require both to pass for DMARC success.
Reporting tests belong in separate families. Aggregate reporting has its own discovery, external-destination verification and XML structure. Failure reporting has a different format and privacy surface. A successful policy parse is not evidence that report delivery or safe report processing works. The pack should link each expected outcome to the precise section that supplies it, while marking implementation-specific behavior separately. RFC 9989, section 4.4, 4.7 and 4.10; RFC 9990, section 3, 4 and Appendix A; RFC 9991, section 4 and 5
Version fixtures and observations together
Every fixture needs an identifier, content hash, purpose, source requirement, input assumptions and expected result. Every execution needs the implementation name and version, configuration, execution time, observed result, logs and reviewer. If the fixture changes, preserve a new version rather than silently replacing the old input under the same identifier. Otherwise an apparent improvement could be caused by easier tests rather than corrected behavior.
Expected results must be written before interpreting the observed run. When a result differs, classify whether the expectation was wrong, the implementation differs, the fixture was invalid or the environment prevented a meaningful test. A skipped or blocked test is not a pass. A result accepted by local policy should not be relabeled as standards-conforming without explaining the relevant discretion.
Keep secrets and unnecessary message content out of fixtures. Use bounded, authorized synthetic inputs for laboratory work and separately approved evidence for production routes. This article does not provide an executed fixture suite or authorization to send test messages, change records or access provider accounts.
Portfolio acceptance worksheet
The worksheet should connect a portfolio group to fixture identifiers, expected outcomes, observed outcomes, unresolved differences and a release decision. Include a coverage column showing which domains or routes are represented and why that grouping is justified. A representative case can support a documented inference, but it cannot silently become proof for unrelated implementations or suppliers.
Add separate gate columns for original evidence, human review, source applicability, production routes, visual accessibility and owner release. These gates can remain open even when an offline parser test passes. Record who can close each one and what artifact is required. The release owner should see a concise exception list rather than a percentage that hides unsupported scopes.
The pack should also contain a rollback and reevaluation trigger. A provider change, DNS delegation change, new sending route or specification clarification can invalidate an earlier acceptance assumption. Preserve the event that requires reevaluation and the affected fixture families so the next review starts from a known baseline rather than reconstructing intent from scattered tickets.
Fictional portfolio decision
Imagine a fictional portfolio with employee mail, a receipt service and an inactive brand domain. The proposed pack assigns alignment cases to the two sending routes and policy-discovery cases to all three groups. A hypothetical laboratory implementation handles the valid version value correctly but differs on one discovery fixture. No execution actually occurred; these are invented conditions illustrating a release decision.
The correct response would not be to mark the whole portfolio ready because most cases appeared acceptable. The reviewer would retain the discovery difference, identify which groups depend on it and ask for implementation evidence before releasing that scope. The receipt service would still need its own authorized route evidence, even if the laboratory alignment logic were correct.
A proposed outcome could accept a bounded offline behavior while holding production readiness. That distinction is useful rather than embarrassing: it tells the owner exactly what the evidence supports. The example does not claim that a named receiver has adopted RFC 9989 or that a real domain has passed a test.
Original evidence remains open
The catalogue requires a versioned fixture set and expected-versus-observed results, not merely a checklist. This manuscript describes how to build that pack, but no fixture execution, live query or observed result has been supplied. The original evidence requirement therefore remains open, as do all six release gates.
Before operational publication, a qualified reviewer should verify that each expected result has a current authoritative basis and that every observation belongs to the stated implementation version. Do not treat a source citation as a substitute for an execution log. The final acceptance claim should name the covered portfolio scope, its exceptions and the outstanding operational dependencies.