Decide what evidence is needed before collecting it
Authentication evidence is not one uniform dataset. An aggregate report, a failed-message report, a full message sample and a DNS change log can answer different questions while exposing different information. Retention and access rules should follow the diagnostic purpose and actual fields, rather than the name of the folder where everything happens to be stored.
This guide proposes a governance workflow, not a legal retention schedule. It uses the May 2026 DMARC reporting specifications and identified NIST controls reviewed on 8 November 2026. No customer report, mailbox or evidence repository was inspected. No retention setting was changed, sample approved, file shared or data deleted.
Build a field map by evidence class
For aggregate reporting, record the report origin, reporting interval, domain, connecting mail-system IP, message count and relevant authentication identifiers and results. RFC 9990 describes domain-level aggregate data rather than message content or individual-user details. Nevertheless, inspect the actual schema and any vendor extensions before applying that description to a received file. Infrastructure and volume information can still deserve restricted business access. RFC 9990
Failure reports require a separate classification. RFC 9991 explains that they can expose message headers and sometimes the entire message, including personal or confidential information. Requesting failure reports is therefore a distinct data-collection decision, not a harmless way to make an aggregate dashboard more detailed. Confirm necessity, scope and recipients before enabling or forwarding them. RFC 9991
Full message samples can contain addresses, subject lines, routing history, attachments, tracking identifiers and content unrelated to the investigation. DNS observations generally answer a configuration question, while application logs may connect that configuration to a real service or user. Map those categories separately so that access to a low-content technical summary does not automatically expose the original message.
Tie each field to a purpose and an owner
For every evidence class, write the question it answers, why the requested fields are necessary and who is accountable for their use. A request to understand alignment might need domains and trusted authentication results, not a message body. A different incident may need a restricted original sample. Neither case justifies collecting every available field by default.
Specify the approved storage location, allowed readers, export rights and retention trigger. Distinguish the investigator who can inspect a restricted sample from a service owner who needs only a conclusion. A ticket containing an unrestricted attachment can undermine controls on the original repository, so the field map must include copies and derived summaries.
NIST SP 800-53 Rev. 5 AC-6 provides the least-privilege principle, while SI-12 addresses information management across its lifecycle. They support defining access and retention deliberately; they do not prescribe one universal number of days for DMARC material. The cited PDF is the December 2020 updated edition, with later Release 5.2.0 identified on the publication page. NIST security and privacy controls
Redact without overstating what the sample proves
Create a derivative sample only when its audience and purpose are approved. Keep an explicit record of removed or substituted fields. Stable placeholders can preserve relationships between domains or addresses without exposing the original values, but such a transformation may change what can be verified from the sample.
For example, altering a signed header or body can invalidate the DKIM signature. A redacted message can still illustrate a parser finding, but it cannot automatically prove the original cryptographic verification result. Where verification matters, have an authorized analyst inspect the protected original and attach a bounded finding with provenance. RFC 6376
Hashing a file can help detect later alteration; it does not prove that the data was truthful, collected with permission or safe to distribute. Likewise, replacing an address with a hash is not a general guarantee of anonymity. Consider whether contextual fields or a small set of possible values allow someone to infer the original information.
Choose retention by evidence value and obligation
Separate raw inputs, parsed fields, investigation extracts and decision records. They need not have identical lifetimes. RFC 9990 leaves post-processing storage choices to the report evaluator; it does not impose a fixed retention period. A local retention decision should explain what continued value remains after extraction and which organizational obligations apply. RFC 9990
For audit and decision records, NIST AU-11 uses an organization-defined period consistent with applicable retention requirements. Have the accountable records, privacy or legal function resolve any relevant obligation or preservation hold. Do not use this article to erase material subject to an incident or legal preservation decision. NIST audit retention control
Define when the retention clock begins, who can extend it, how exceptions are reviewed and how deletion is evidenced. Account for backups, exports and vendor copies rather than claiming immediate erasure from one dashboard action. A request to review the schedule does not authorize deletion or permanent purging.
Control transfers and automated processing
Before sharing evidence externally, approve the specific fields or sample, named destination, purpose and access scope. DNS authorization for an external DMARC reporting destination is a protocol mechanism, not a substitute for the organization's decision about processing and disclosure. Review both independently. RFC 9990
Treat received reports as untrusted inputs. RFC 9990 identifies malicious report content and forged reporting data as risks. Parsing limits and provenance checks should be evaluated in the actual implementation, not assumed because a file is XML. An analysis agent should receive only the approved subset and no independent permission to export it or change repository access.
A fictional field-map exercise could retain domain-level alignment observations in an analyst view while keeping a necessary original message in a separately restricted incident store. Its retention values remain undecided until the responsible owner approves them. The exercise is a design example, not an approved sample or proof that a deletion process works.
Required original evidence: A data-field map and approved minimal evidence sample with an explicit retention decision. The field map in this draft is proposed, the approval and sample are absent, and the commissioning gate remains open.