Scope the reporting activity before choosing controls
GDPR analysis concerns a processing activity, not simply the presence of a DMARC record. Establish whether the relevant controller or processor and activity fall within the Regulation's material and territorial scope. EU establishment and certain activities directed at people in the Union are different applicability paths under Articles 2 and 3. Neither a European recipient address nor an overseas hosting location settles the question alone. GDPR has applied since 25 May 2018; the EUR-Lex entry and its linked consolidated text were reviewed on 8 November 2026. GDPR primary text.
Describe why the organisation wants reports, who receives them, what decisions they support and whether message-level evidence is necessary. Separate domain-security investigation from employee monitoring, customer profiling or unrelated analytics. A reporting feature being available does not justify every possible use of its output. The privacy owner should approve the purpose and applicable legal basis before a new processing arrangement starts.
Distinguish aggregate fields from message content
RFC 9990 defines aggregate reporting using domain-level authentication information. Its schema includes the connecting mail-server IP address, message counts, policy evaluation and author-domain identifiers; some envelope-domain fields are optional. The privacy section describes this reporting model as excluding individual user addresses, individual IP addresses and message content. Do not tell readers that a conforming aggregate report necessarily contains a recipient's full mailbox or original message. Aggregate reporting specification.
The operational review must nevertheless inspect the actual input and processing. A vendor may enrich a record, add account information, retain uploaded message samples or combine reports with other logs. The privacy question then concerns that real dataset and its identifiability, not only the standard's intended schema. Document malformed or unexpected fields rather than silently treating them as authorised collection. A field named source_ip should be interpreted in its reporting context, not automatically labelled an individual end user's address.
Failure reports require a different assessment. RFC 9991 permits detailed information about failed messages and explains that reports can expose headers, addresses, content and previously hidden forwarding destinations. Its privacy section urges controlled destinations, minimisation and limited diagnostic use. Redaction may reduce exposure without eliminating all identifying information. Receivers can restrict or decline this reporting; publishing a request does not guarantee receipt. Failure reporting specification.
Assign a lawful purpose and processing relationship
Where personal data is processed, record the selected Article 6 basis and its supporting reasoning. Security purposes do not automatically establish either consent or legitimate interests. EDPB guidance describes the need for a real, lawful interest, necessity and balancing against individuals' rights where legitimate interests is relied upon. Public authorities cannot use Article 6(1)(f) for processing in the performance of their tasks. Obtain the appropriate legal assessment rather than selecting a basis from a software menu. EDPB lawful-processing guidance and GDPR Article 6.
Map each party's actual role: receiving mail service, domain owner, reporting processor, support provider and any downstream recipient. Controller and processor labels depend on who determines purposes and means and who acts on whose instructions. Where Article 28 applies, the processing agreement must address the required instructions and safeguards. A reporting mailbox's DNS authorisation is not a data-processing agreement or approval for unrelated onward use.
Design access and retention around necessity
Article 5 requires minimisation and storage limitation, while Articles 25 and 32 address protective design and risk-appropriate security. Apply these to the actual report pipeline: intake mailbox, parser, dashboard, exports, support tickets and backups. Give each authorised role the least information needed for its task. A support engineer troubleshooting an aggregate import does not automatically need an unredacted failed-message attachment. GDPR consolidated text.
There is no universal DMARC retention period supplied by this article. Set a justified period for each dataset and purpose, with any legally required preservation considered separately. Specify when deletion occurs, how exports and copies are covered, and who verifies the process. Test the approved behaviour with safe fixtures before relying on it. A retention value displayed in an interface is not evidence that every backup or support attachment follows that value.
Examine transfers and higher-risk collection
Record storage and access locations, subcontractors and onward disclosures. If Chapter V applies to a transfer, the responsible reviewer must establish the appropriate transfer route and safeguards. Encryption is a protection, not an automatic replacement for the transfer assessment. An EU-region label does not, without further evidence, describe all remote access or support processing. GDPR transfer provisions.
Consider whether the proposed operation is likely to create high risk requiring a data protection impact assessment under Article 35. Failure-report content, scale, sensitive information and combination with behavioural datasets can affect that evaluation. Do not declare every aggregate-report deployment subject to a DPIA, or exempt every security tool. Transparency, individuals' rights and incident handling also need the privacy owner's attention within the actual service design.
Prepare a fictional field map without inventing approval
In a fictional organisation, routine aggregate reports go to a security dashboard while occasional diagnostic samples would enter a support queue. The proposed map records the standard aggregate fields separately from possible full-message content, names intended recipients, and leaves lawful-basis approval, processor terms, transfer assessment and retention acceptance unfilled. No report was collected or customer data inspected for this example.
The exact commissioning requirement is: Map actual report fields and processing relationships for privacy review. This package provides a proposed field-and-relationship map, not the actual deployment evidence. Before making implementation or compliance claims, the owner must supply authorised samples or schemas, verified recipients and contractual relationships, access and deletion evidence, and privacy-specialist review. Technical SME, production-route, visual and publication gates also remain open. No reports were enabled, uploaded, transferred or deleted, and no EmailAuth privacy capability is asserted.