Avoid the all-or-nothing review
A provider help page may still cite RFC 7489 while accurately describing a current account screen or supported sending route. Conversely, a newly dated page can repeat historical protocol advice. The useful review unit is the individual instruction or claim, not the age of the citation alone. An auditor should identify what remains valid, what the current standards changed and what depends on the provider’s actual implementation.
RFC 9989 provides the current core DMARC specification and describes changes from RFC 7489. Aggregate and failure reporting are now specified separately in RFC 9990 and RFC 9991. Use those sources to assess protocol statements, but do not treat them as evidence that a provider has already changed every UI field or deployed evaluator. RFC 9989, Appendix C; RFC 9990, section 1; RFC 9991, section 1
Preserve the exact product context
Before annotating a guide, record its URL, retained date, product, plan or account scope where stated, region, route and relevant prerequisites. A vendor brand can contain multiple mail products with different configuration paths. A guide for a custom SMTP route may not apply to a default API route, and instructions for one hosted mail product may not cover another product from the same company.
Keep account-generated values distinct from explanatory examples. A guide’s sample selector or DNS target should not be copied as a universal production value. Likewise, a UI instruction can remain useful even when its surrounding standards explanation needs updating. Preserve that distinction so the reader does not discard a valid onboarding prerequisite merely because a historical RFC appears in the introduction.
This manuscript does not audit a named provider’s current account or assert that a specific service is out of compliance. It supplies a method for a future source-grounded review. Any actual product instruction must be checked against a readable primary guide and the authorized account context before it is presented as applicable.
Classify each instruction by authority
Use at least four annotation categories: product workflow, protocol requirement, provider-specific eligibility or policy, and explanatory recommendation. Product workflows need current provider evidence. Protocol requirements need the appropriate specification section. Provider eligibility can be stricter or differently scoped than the protocol minimum and must not be generalized to every receiver. Recommendations should disclose their rationale and limits.
For each line, write the actor and condition. A receiver’s policy-discovery behavior is different from a domain owner’s DNS publication task. A requirement to configure a particular account field may be necessary for that service without changing the standard’s record syntax. A report destination’s receiving permission is distinct from the sender’s request to send reports there.
When a sentence combines categories, split it. For example, an instruction to enter a reporting address can be a valid UI step while a claim that any external address automatically receives reports is incomplete. The review should preserve the useful step and attach the missing authorization condition rather than replacing the whole guide with generic advice.
Compare specific changed concepts
The current core DMARC version value remains DMARC1. A review must not invent a DMARC2 record or imply that updating an RFC citation requires a DNS version switch. The current specification also documents removal of pct, while the retained IANA registry marks that tag historic. Those facts support correcting a claim that pct is a current core-standard sampling control without proving how every deployed provider handles it.
Policy discovery and organizational-domain determination also need comparison against the current specification rather than an old simplified algorithm. Reporting statements should be checked against RFC 9990 or RFC 9991 as appropriate. Record the exact difference and its operational significance; do not use “DMARCbis changed everything” as a substitute for a section-level assessment. RFC 9989, section 4.7, 4.10 and Appendix A.6; IANA DMARC Tags registry
Annotation worksheet and acceptance criteria
Create a worksheet containing the guide excerpt, source snapshot, product scope, instruction category, current authority, proposed annotation and implementation evidence still required. Assign one of four outcomes: retained as applicable, retained with a scope note, updated because the standards claim changed, or unresolved pending provider evidence. These are editorial outcomes, not claims that any production system passed a test.
The worksheet should also identify the owner who can confirm account-specific values and any separately authorized test needed to establish behavior. If the provider guide is inaccessible, label the source gap rather than substituting a generic setup sequence and calling it verified.
Acceptance requires each annotation to stand on its own evidence. A reviewer should be able to see why a screen-navigation step was retained while a protocol explanation was revised. Keep the original excerpt and proposed wording together so the change does not accidentally introduce a new commitment, unsupported feature or universal deliverability promise.
Fictional review of a legacy-cited setup page
Imagine a fictional provider page with three instructions: enter the account-generated DKIM records, add a reporting address through the settings screen, and use pct as the current standard’s rollout control. The page cites RFC 7489. No such named page was audited here; these invented instructions illustrate the classification method.
The DKIM step might remain valid if the current product documentation and account values support it. The reporting-address step might remain valid as a UI action while requiring an additional external-authorization explanation. The pct statement would need a current-standards annotation, while the provider’s actual handling of that field would remain an implementation question. One citation therefore leads to three different review outcomes.
The proposed next action is to retain supported product instructions, correct standards language and obtain provider-specific evidence for unresolved behavior. It is not to delete all existing records, bypass setup requirements or declare the provider insecure. The fictional example demonstrates how a careful review can be useful without overclaiming access or test results.
Keep operational and editorial release separate
An editorial update can improve a guide before production verification is complete, provided its limits are visible. Do not describe an annotated document as proof that a live account is configured correctly. Conversely, a successful account test should not be generalized to every customer plan, region or receiver implementation.
The catalogue requires annotations identifying which steps remain valid, which changed and which depend on provider implementation. A real source-specific annotated guide remains open for this draft. No current named-provider rollout, account navigation, DNS edit or message test is claimed. The original-evidence gate and the other five release gates remain open.
Before operational publication, obtain the actual readable provider source and preserve the exact excerpts, source dates and current standards references. A qualified reviewer should check that every retained instruction matches the product scope and that unresolved implementation behavior remains unresolved. This approach produces a usable guide without pretending that an old citation alone proves either correctness or failure.