Ask which question the source can answer
A DMARC investigation may need to answer several questions: what behavior the published protocol specifies, which tag names are registered, whether a correction has an authoritative disposition, and what a particular implementation actually does. These questions require different evidence. Treating a search result, registry row and product screenshot as interchangeable authority makes it easy to apply the right fact to the wrong decision.
RFC 9989 contains the current core DMARC specification. Aggregate and failure reporting are specified separately in RFC 9990 and RFC 9991. Their separation matters when a source discusses report format, external authorization or privacy rather than policy evaluation. Record the exact document and section supporting a claim instead of citing “DMARC” as though it were one undifferentiated page. RFC 9989, section 6 and Appendix C; RFC 9990, section 1; RFC 9991, section 1
Read a specification with its scope and normative language
Preserve the document number, title, publication context, section and exact requirement language. A MUST is not the same as a SHOULD, MAY or explanatory example. Also identify the actor: domain owner, mail receiver, report generator or report consumer. A statement about a receiver’s evaluation behavior does not necessarily instruct the domain owner to publish a new DNS tag.
Read surrounding conditions before extracting a sentence into a checklist. A rule can apply only after policy discovery, only to an external report destination, or only when a receiver chooses a particular handling action. Removing the condition can turn useful guidance into a false universal requirement. Keep the condition alongside the requirement in the working evidence record.
A published specification does not prove universal deployment. Implementation version and configuration must be checked separately. Likewise, it is not automatically a legal obligation for every organization. Any contractual, regulatory or procurement requirement needs its own current authority and scope rather than being inferred from a standards-track document.
Use the registry for assignments, not a complete algorithm
The retained IANA DMARC registry is a primary source for registered tags, their references, status and descriptions. In the captured registry, the DMARC Tags table references RFC 9989 and marks pct historic with its RFC 7489 reference. That is useful evidence when distinguishing historical configuration vocabulary from current registered status.
The registry row does not supply the full processing algorithm or a vendor’s rollout schedule. Follow its reference to the specification for semantics and handling. A historic tag entry should not be transformed into an unsupported claim that every deployed receiver rejects records containing that tag. Determine the applicable parsing rules and actual implementation behavior before predicting an outcome.
Retain the registry capture date and the exact row used. Registry content can change independently of an old screenshot in a training document. A review should make clear whether it is describing the current retained assignment or a historical entry relevant to an older implementation. IANA DMARC Tags registry
Handle drafts and correction claims cautiously
RFC 2026 explains the distinction between evolving Internet-Drafts and publication through the RFC mechanism. This article uses that historical process source narrowly to avoid treating an unfinished proposal as an established implementation requirement. It does not claim that the 1996 text is a complete account of every current IETF procedure or later process update.
A draft can be valuable research context, but retain its exact version and describe its status honestly. Do not convert a proposal into a deployment assertion merely because it appears on an official site. The same discipline applies to a reported correction: a claim that wording is wrong is not enough to establish the current authoritative treatment or how an implementation should change. RFC 2026, section 2.2
Current erratum status remains unverified. Before relying on a proposed correction, inspect its official RFC Editor entry, record its identifier and current disposition, and check how it affects the relevant requirement. This guide does not establish that any specific erratum is accepted, verified or applicable.
Authority comparison worksheet
Create one row per decision-relevant claim. Include the claim, actor, condition, source class, exact URL, retained date, document version or registry row, quoted requirement and interpretation. Add a separate column for correction status and the affected implementation version. If either is unknown, use an explicit unresolved state rather than a guessed default.
A second section should record conflicts. Does a provider guide use historical terminology while documenting a still-current UI? Does a registry status differ from an old example? Does a proposed erratum challenge an edge case that the implementation has never tested? Each conflict needs a scoped resolution plan, not a broad instruction to trust whichever page looks newest.
Acceptance requires a reviewer to trace the operational decision back to the appropriate authority and distinguish it from actual implementation evidence. A source comparison can be complete while a production change remains blocked. Conversely, an implementation test can show behavior without establishing that the behavior is the preferred interpretation of a disputed requirement.
Fictional diagnosis: a familiar sampling tag
Imagine a fictional internal guide that presents pct as a current universal rollout control. A reviewer finds the current retained IANA entry marking it historic and the relevant change discussion in RFC 9989. No live policy was changed and no receiver was tested in this example.
The supported editorial correction is to stop presenting the old instruction as the current core standard without qualification. It is not to assert that all providers have already removed support or that an organization must immediately delete the tag from every production record. The reviewer should record the affected guide, source evidence and implementations requiring verification.
If someone cites an alleged erratum to justify a different interpretation, its exact status must be checked before it is used as authority. In this manuscript that check remains unavailable, so the responsible conclusion is an open correction-status item, not an invented resolution. The example illustrates source discipline rather than a completed migration.
Open evidence and publication status
The catalogue requires checking current RFC, IANA and erratum status and recording the affected implementation version. Current retained RFC and registry evidence supports the documentary discussion, but current erratum-status verification and implementation-version evidence remain open. This limitation prevents the manuscript from being presented as a completed operational source adjudication.
All six release gates remain open. A qualified reviewer should revisit the unresolved correction status through an authorized available source before closing the original-evidence gate. No DNS changes, software rollout, legal commitment or provider account access occurred. The useful deliverable is a source-selection method with explicit evidence boundaries, not a claim that every ambiguity has been settled.