Separate the event from the decision
A new specification, registry update, correction claim or provider notice can trigger investigation without authorizing a production change. A useful standards change register records the event first, then tracks the analysis and decision it produces. It should not become a chronological list of links with no connection to actual routes or implementation versions.
For DMARC, a change can affect core policy evaluation, aggregate reporting or failure reporting. RFC 9989, RFC 9990 and RFC 9991 separate those functions. Tagging the event by function helps route it to the right owner and prevents a report-format update from being mistaken for a command to rewrite every domain’s policy. RFC 9989, section 6 and Appendix C; RFC 9990, section 1; RFC 9991, section 1
Capture the source event without overstating it
Give each event a stable identifier and retain its source URL, publication or observation date, exact document version, affected section and short statement of the change. Preserve a snapshot hash where appropriate so later reviewers can distinguish the source originally assessed from a page that subsequently changed. Record the source class: specification, registry, correction-status record or provider documentation.
Write the normative actor and conditions beside the event. A receiver-side recommendation is not automatically a domain-owner requirement. A provider’s account onboarding instruction may be necessary for that product without becoming a universal protocol rule. A proposed change or unresolved correction should remain visibly provisional.
Do not infer current status from an old internal note. Recheck the authoritative source when the decision depends on freshness. If a source is unavailable, retain the limitation and continue independent analysis; do not replace missing evidence with a search snippet or an unsupported declaration that the change was accepted.
Map impact to owned implementations
The impact section should name the parser, evaluator, reporting collector, DNS publishing workflow or documentation set potentially affected. Record implementation version and configuration, portfolio groups, route owners and the evidence supporting relevance. A broad label such as “all mail” is rarely useful unless the analysis genuinely covers every route.
Separate direct impact from possible impact. A record generator may need an editorial update even when deployed policies remain unchanged. A report consumer may need schema handling while the mail receiver’s alignment logic is unaffected. A training guide may require corrected terminology before any software release. These differences should produce separate tasks and acceptance criteria.
Add an explicit not-applicable rationale when a reviewed event does not affect the organization’s role or implementation. That is different from ignoring it. A later product migration can invalidate the rationale, so preserve the assumptions that would trigger reassessment rather than permanently suppressing the event.
Link standards differences to testable questions
A standards event should become a precise question: does this implementation parse the required version value, apply the relevant discovery behavior, or handle the current reporting schema? RFC 9989 retains v=DMARC1 while describing changes from RFC 7489. The register should record the actual changed behavior rather than inventing a version-switch task.
For each question, identify fixture versions, expected results, implementation version and the planned observation method. A documentary review can support a proposed expected outcome but cannot claim an executed pass. Differences need a reasoned disposition: implementation defect, unsupported feature, erroneous expectation, environmental block or intentionally deferred scope. RFC 9989, section 4.7 and Appendix C
The register should link to full test artifacts rather than squeeze them into a summary field. This keeps the decision readable while preserving the evidence needed to reproduce it. No test suite or software implementation is executed by this article.
Decision and rollback worksheet
Use fields for event identifier, authority, affected scope, initial interpretation, uncertainty, proposed action, evidence required, owner, review date and status. Add a decision record with rationale, approved scope, observed results, residual risk and reevaluation trigger. Do not overwrite the original proposal when the decision changes; append a dated revision that explains why.
Possible dispositions include adopt within a bounded scope, defer pending evidence, retain existing behavior under a documented constraint, or mark not applicable. None should be presented as a legal conclusion unless an appropriate legal source and qualified review support it. A technical standards register is not a substitute for contractual or regulatory analysis.
For an approved production change, retain its separate authorization, rollback conditions and post-change verification plan. The register can point to these records without itself granting permission to change DNS, create credentials, send test messages or deploy code. An entry marked ready for review is not the same as released.
Fictional change record: historical tag guidance
Imagine a fictional register entry prompted by the retained IANA registry marking pct historic and RFC 9989 explaining its removal from the current core specification. The event is classified as affecting an internal policy-generation guide and potentially an older evaluator. No production record or software was changed for this example.
The proposed action is to update the guide’s standards description while requesting implementation-specific evidence before changing the evaluator’s behavior. The register keeps those decisions separate. A hypothetical later test could establish the evaluator’s current handling, but this manuscript supplies no such observation. Its test-status field remains planned, not passed.
The entry’s reevaluation triggers include a software upgrade, a provider change and new authoritative clarification. The useful output is a traceable reason for the limited editorial action and the operational hold. It is not a blanket announcement that all receivers have adopted the same behavior. IANA DMARC Tags registry; RFC 9989, Appendix A.6
Maintain the register without manufacturing progress
Review open entries on a cadence appropriate to their impact, with urgency determined by actual consequences rather than the age of a link. Merge duplicates while preserving source references and decisions. Close an entry only when its stated acceptance criteria are met or a reviewed decision explicitly ends the work. A closed documentary review should not conceal an unresolved production task.
The catalogue requires a change record linking a standards event to a tested operational decision. This draft provides a proposed register structure and fictional entry only. The tested decision, original execution evidence and owner release remain open, along with the other release gates. No live configuration, deployment or external communication occurred.
Before publication as an operational case study, obtain the actual versioned record, supporting test artifacts and decision approval. Preserve exceptions and failed expectations as useful evidence. A register that shows why a change was deferred is more trustworthy than one that labels every new source implemented without demonstrating what happened.