Review tag status before editing a familiar record
A DMARC record can remain recognizable while containing instructions that no longer belong to the current active tag set. That is a reason to investigate its meaning, not a reason to run a blind cleanup. Start with the exact published owner name and complete record, then separate standards status, historical intent, observed implementation behavior and the business decision about removal.
The current IANA DMARC registry lists pct, rf and ri as historic. It lists t, rua, ruf and the other current policy and alignment tags as active. Registry status is authoritative documentary evidence about the protocol, but it is not a scan of deployed receivers. A service can still encounter older records, parsers or reports after a tag becomes historic.
Give each legacy tag its own question
For pct, identify the rollout assumption that depended on sampling. RFC 9989 Appendix A.6 explains its retirement and the reason for retaining testing semantics through t. Do not translate pct=25 into an invented t value or present t=y as the same percentage. Any replacement plan needs an explicit comparison of the desired treatment and relevant implementation behavior.
For rf, identify whether a system was using the record to choose a failure-report format. Current failure-report handling belongs to RFC 9991, which describes the augmented authentication failure reporting format. A historic format-selection tag is not a reason to assume a receiver will send full message content, accept an arbitrary format or stop sending reports. Review the collecting software and the reports actually available.
For ri, identify which monitoring or ingestion assumption relied on a requested interval. RFC 9990 defines current aggregate reporting. Removing a historic interval tag does not establish a contractual reporting schedule or prove that every receiver will immediately change cadence. Preserve observed reporting periods and late-arrival behavior separately from the former request.
Avoid deleting the reporting controls that remain active
Do not confuse rf with ruf or ri with rua because their names are similar. The active reporting destinations still have distinct purposes: rua requests aggregate feedback and ruf requests message-specific failure feedback. The fo tag remains active for failure-reporting options. Each destination and option needs its own necessity and authorization review, especially where reports can expose message information.
RFC 9989 sections 4.7 and 4.8 define the current record and tag syntax. The version remains DMARC1, with the required version tag first. Unknown-tag handling should not be used as a justification for accepting an incorrectly identified record or inventing a new version. The review should distinguish a tag that is historic in the registry from a spelling mistake and from an active tag with an unacceptable value.
External reporting destinations introduce another dependency. RFC 9990 section 4 specifies destination verification for aggregate reporting, while RFC 9991 section 5 applies that procedure to failure reporting with the appropriate substitution. DNS verification is not a substitute for the owner's privacy and data-sharing decision. A record cleanup should not silently add, remove or redirect a report recipient.
Build a reviewable tag status record
The accompanying map groups the current registry entries and identifies the next review question. For an actual domain, expand it into one row per published tag: exact value, current status, specification reference, intended function, known dependent systems, proposed action, approver and evidence. Retain the original record and its source timestamp so the decision can be reconstructed later.
Give unknown dependencies an owner rather than describing them as obsolete merely because the standards status changed. A legacy report consumer might need compatibility support even after production policy is updated. Conversely, compatibility code should not fabricate current meaning for a retired tag. Preserve the original input and the interpretation profile used by the system.
Propose a minimal difference and test the relevant behavior in an authorized environment before execution. If the cleanup also changes p, reporting destinations or alignment settings, those are separate consequential changes to review explicitly. An approval to remove a stale comment does not establish approval for stronger treatment of business mail.
Fictional worked example of a legacy export
An invented export for example.com contains pct=25, rf=afrf and ri=3600 alongside rua and ruf destinations. A preliminary script labels every tag beginning with r as removable. The reviewer stops that plan because it conflates historic format and interval controls with active destinations.
The documentary table marks the three historic tags correctly, but the workflow still needs to identify the old rollout objective, the consumer's accepted failure format and the reporting schedule the operations team actually uses. The proposed difference is not executed. No recipient is changed, no DNS lookup is represented as observed, and no compatibility test is claimed.
This example is intended to improve the approval question: which exact values can be removed or replaced without losing an understood function? A shorter record is not automatically a safer record, and a familiar record is not automatically current.
Separate documentary completion from operational readiness
The exact catalogue requirement is: Create a tag-status table from IANA and the current RFC, with behaviour tests where relevant. The source-backed status map is provided, but domain-specific behavior tests and approval remain open. The commissioning requirement is also retained: Validate current primary specifications and retain a worked example before drafting. Full specifications and a fictional pre-draft case support this manuscript; they do not prove receiver adoption, complete the unavailable errata review or authorize publication. A topic-specific SME must review the final interpretation and the actual change evidence.