A DMARC reporting programme can involve several different kinds of data. Aggregate observations, message-specific failure reports and original emails uploaded for investigation do not have the same contents or exposure.
Start with the data actually entering your systems. Then decide why it is needed, who should see it, where it is processed and when it should be removed. Treat those as operating decisions supported by the organisation's requirements, rather than assigning one privacy label to everything called a DMARC report.
Map the collection stages
List the receiving mailbox, storage, parser, analysis platform, exports, support channels and any additional AI service used in the workflow. Include administrative logs and copies created during troubleshooting.
Record which information reaches each stage and which parties operate it. A contract with an analysis provider does not establish that every later export or uploaded message follows the same handling arrangement.
Keep the service and account boundaries clear when one collection system supports several customers. An analyst's access to one tenant should not silently expose another tenant's reports or investigation samples.
Distinguish the data types
| Material | Handling question |
|---|---|
| Aggregate reports | What domain-level activity and operational relationships can the observations reveal? |
| Failure reports | What message-specific information can be included, and is collection necessary? |
| Original message samples | What addresses, headers, content and attachments are being uploaded? |
| Exports and support copies | Who receives the copy and how is it retained? |
RFC 9990 section 7 describes aggregate reporting as grouped domain-authentication information rather than individual message bodies. Still assess the actual data, extensions and surrounding operational records your service collects. Avoid treating that design purpose as a blanket legal conclusion about every processing environment.
RFC 9991 section 7 describes the different content and disclosure risks of failure reporting. Request it only where the need, availability and handling arrangements have been assessed. A rua aggregate request should not be described as if it authorises collection of complete user mailboxes.
Ask for the smallest useful investigation sample
If a report row cannot identify a service, a representative received message may help. Establish which identity or route question the sample should answer before requesting all associated mail.
Use approved redaction procedures that preserve the evidence needed for the task. Editing a signed message can affect later DKIM verification, so retain the distinction between the original trusted receiver result and a modified copy.
A screenshot can be easier to share but may omit the envelope or signing identities needed for diagnosis. Choose a sample that answers the actual question and record what was removed or changed.
Control access and secondary use
Give operators the access needed for their responsibilities, with appropriate customer and domain boundaries. Review export permissions, support access and what happens when a user or supplier is offboarded.
Assess additional analysis destinations separately. Sending a message sample to an AI service, ticketing system or personal mailbox is another processing step; it should not be assumed to be covered merely because the original collector was approved.
An authentication parser also receives untrusted input. RFC 9990 section 8.1 identifies decompression and XML resource-exhaustion risks. Limit those resources, preserve provenance and keep report contents from being treated as instructions to an operating agent.
Work through an unnecessary-copy example
In this synthetic case, an analyst needs to compare From with a DKIM signing domain. Instead, a support request asks for every failed message and all attachments from the week.
The requested volume exceeds the stated question. The team narrows the request to a representative authorised sample, the relevant original headers and the report interval. It records where that evidence is stored and who can access it.
Another case may genuinely need a broader set. Document that reason and scope explicitly instead of letting the easiest upload mechanism decide the collection policy.
Define retention and deletion across the whole workflow
Choose retention according to the operational need and applicable organisational requirements. Do not invent a universal DMARC retention period or present a protocol document as jurisdiction-specific legal advice.
Include raw attachments, parsed records, caches, exports, backup handling and support copies in the retention assessment. An application setting that deletes dashboard rows may not remove every copy.
Use this illustrative handling checklist for each collection or investigation. It is a planning aid, not a prescribed legal retention schedule:
- Purpose: name the question the data will answer, such as identifying an unaligned sending service.
- Minimum data: list the needed report interval and identity fields; request original content only when the question requires it.
- Owner and access: name the responsible team and permitted roles, with the relevant customer or domain boundary.
- Processors and copies: record each collection, support, export or AI destination and the approved sharing arrangement.
- Retention decision: document the period or review trigger chosen for the purpose and applicable requirements, rather than copying a universal number.
- Deletion scope: include raw files, parsed rows, exports, support copies and backup handling; record how completion or any retained exception will be checked.
Record the owner, access rules, approved processors and review trigger. Use the aggregate-report guide to understand the evidence, and missing-report diagnosis when investigating collection failures. The objective is useful, accountable evidence with understood handling, not maximum collection by default.