Decide what diagnosis requires before collecting content
Failure reports can expose information about individual messages, unlike aggregate reports that summarize groups of observations. Updating a collection pipeline for RFC 9991 therefore starts with a necessity decision: which diagnostic question requires message-specific evidence, who may receive it and what data is actually needed? Enabling collection first and deciding retention later can create an unnecessary store of private correspondence.
A request in DNS does not guarantee that receivers generate reports. RFC 9991 sections 2 and 7 describe receiver willingness, policy constraints and substantial privacy concerns. Missing reports do not prove the absence of authentication failures. Keep coverage uncertainty visible instead of treating silence as a clean bill of health.
Map the updated format precisely
RFC 9991 updates the failure-reporting format derived from RFC 6591. Its section 4 requires Identity-Alignment and conditionally requires DKIM-Domain, DKIM-Identity and DKIM-Selector for DKIM failures of an aligned identifier, or SPF-DNS for SPF failure of an aligned identifier. Delivery-Result is optional. A field map should preserve those conditions rather than demanding every field in every report or inventing missing values.
The meaning of Identity-Alignment is easy to reverse: it lists mechanisms that failed to authenticate an aligned identity. The value none means all attempted methods were successful at authenticating an aligned identity. It does not mean that no alignment information exists. RFC 9991 section 4 supplies the authoritative definition; implementers should compare actual inputs and result types before attaching a simplified dashboard label.
Keep DMARC failure reports distinct from mechanism-specific DKIM or SPF reports, which a receiver can choose under its own policy and applicable reporting options. A collector should identify the report type before interpreting fields. An unexpected combination deserves a recorded validation decision, not a silent conversion into a generic DMARC failure count.
Treat destination verification as one control among several
Failure-report requests use ruf and relevant fo options. For an external destination, RFC 9991 section 5 requires the verification procedure in RFC 9990 section 4, substituting ruf for rua where appropriate. This guards against forcing reports on an unwilling destination; it does not establish organizational permission to disclose the underlying message content.
Record the actual recipient organization, purpose, transfer route and approved data scope. An address inside the organization's apparent domain may still forward to a third party. Trace that route through authorized administrative evidence rather than assuming the destination is internal from its spelling. A changed reporting address needs both the technical verification and the appropriate sharing decision.
The specification also restricts consideration of ruf in records with psd=y unless specific agreements exist. Do not generalize one domain owner's request into permission for a public suffix operator to collect everyone else's failure content. Report generation, recipient authorization and individual data handling remain distinct questions.
Design minimization before storage and display
RFC 9991 section 7 explains that reports may expose headers, body content, identifiers and previously hidden destinations. A report about a legitimate message that failed accidentally can be especially sensitive. Choose the smallest diagnostic field set, a short justified retention period and roles that need access. No universal retention duration is prescribed here.
Redaction reduces exposure but should not be advertised as guaranteed anonymity. A subject, routing detail or quoted fragment can remain identifying after address local parts are removed. Track the transformation applied, the fields retained and the consequences for diagnosis. Where original bytes must be retained for a separately approved purpose, isolate them from ordinary analyst views and exports rather than copying them into every log.
Treat attachments and report text as untrusted material. Prevent automatic rendering or execution of embedded content, and apply ingestion limits and safe display behavior. RFC 9991 discusses additional damage from distributing spam, phishing or malware content in reports. The proposed collection design should not turn a diagnostic mailbox into an unrestricted redistribution channel.
Fictional example of a minimal intake review
In a fictional paper case, a report contains Identity-Alignment: spf and header material with unnecessary recipient addresses. The proposed field map records the failed aligned SPF mechanism and keeps only the diagnostic data needed for the defined investigation. A restricted evidence reference replaces a full header dump in the ordinary case view.
The reviewer then asks whether the retained fields still support the stated question, whether exports enforce the same restrictions and whether deletion reaches derived copies. Those are proposed acceptance checks. No report was collected, redacted, transferred or deleted for this exercise, and the invented field values do not establish a real receiver's support.
A second planned check covers absence of optional fields. The collector should represent missing Delivery-Result as unavailable, not as successful delivery. That preserves uncertainty and avoids converting a privacy-minimized report into an unsupported operational conclusion.
Keep generation and collection limits reviewable
The specification requires outgoing report rate limits, and section 5.1 recommends DMARC-aligned report streams to reduce loop risks. A collector should also define its own bounded intake and alerting behavior. Receiving fewer samples under a limit changes coverage; it should not silently change the denominator used to describe failures.
The original gate remains open: Map RFC 9991 to the collection pipeline and review minimal-field, redaction and access behaviour. The commissioning requirement is retained verbatim: Validate current primary specifications and retain a worked example before drafting. Documentary mapping and a fictional case are supplied, but no real pipeline, privacy controls or access behavior has been tested. Human technical/privacy review, owner approval and publication authorization remain necessary.