GDPR and email authentication: two angles not to confuse

RUA versus RUF: the right privacy setting

The practical consequence is clear, and it aligns with the increasingly common position across the ecosystem: favouring aggregate reports, and treating forensic reports with extreme caution, or forgoing them by default. The distinction between the two, and why RUF is now discouraged, is developed in DMARC rua vs ruf reports and, from the specific privacy angle, in the privacy of DMARC forensic reports.

The GDPR reasoning is one of minimisation: collect only what is necessary for the purpose. That purpose — securing the domain and mapping its sending sources — is fully served by aggregate reports. Forensic adds little security value while multiplying personal-data exposure. The calculation therefore tilts heavily toward aggregate only.

Minimisation, retention, processors

Where DMARC reports are operated, a few GDPR principles apply directly:

• Legal basis and purpose. The processing rests on the legitimate interest in securing the domain and its communications — a solid basis, provided the purpose stays security and not some repurposed use.
• Minimisation. Aggregate preferred, forensic avoided, and no more fields exfiltrated than necessary.
• Retention. A proportionate duration, set and enforced: reports years old have no remaining security value and become a liability. An explicit retention tier, automatically purged, is the good practice.
• Processors. A provider entrusted with the analysis of those reports becomes a processor under GDPR: the relationship needs a contractual frame, and the hosting location needs checking. Hosting within the Union, under European law, considerably simplifies the compliance analysis.

Those same requirements feed the record of processing and document themselves once and for all — work that ties directly into the evidence logic of an ISO 27001 ISMS.

A concrete example

Let's take an SME whose domain stayed at p=none. An attacker emails its client base with a message displaying the authentic support address, announcing an "account security update" and pointing to a credential-harvesting page. Several clients enter their details. From a GDPR standpoint, the company faces a possible breach affecting its clients' data, exploiting its own domain as the vector — an uncomfortable position where it is both victim and controller questioned about its security measures.

The same scenario, domain at p=reject, ends differently: the forged message is rejected at delivery, it never reaches the inboxes, and there is no harvesting, no breach, no notification. It is the most tangible demonstration that email authentication is a security measure within the meaning of Article 32, and not a technical abstraction.

DMARC and breach notification

GDPR requires notifying certain data breaches to the supervisory authority within 72 hours, and sometimes informing the data subjects. A successful spoofing campaign against a domain can be a breach, or trigger one: credentials extracted from its clients, personal data pulled by a fake message in its name — exactly the kind of event that engages the notification duty, with its train of investigation, communication and regulatory strain.

The reasoning joins that of operational resilience: each spoofing DMARC blocks upstream is a breach that does not happen. Structurally reducing an attacker's ability to impersonate the organisation means reducing the frequency of notifiable incidents — a concrete compliance benefit, measurable in incidents avoided, not just in principle.

Documenting the processing in the record

Where DMARC reports are operated, the analysis is a processing activity to enter in the record under Article 30. The good news: it is simple to describe. Purpose — securing the domain and mapping legitimate sending sources. Data categories — essentially source IP addresses and authentication metadata for aggregate, and that is all as long as the setup sticks to it. Legal basis — legitimate interest in securing the organisation's communications. Retention — a bounded tier, automatically purged. Recipients — the possible analysis provider, framed as a processor.

Filled in once, this record reuses as-is as an evidence brick in an ISO 27001 arrangement, which shares the same documentation requirement. The effort is not duplicated: one clean processing activity, described once and presented under both frameworks.

Is a DPIA required?

The question comes up often. For aggregate reports alone, the personal-data exposure is low and the security purpose well framed: a data protection impact assessment is generally not required, though a quick risk evaluation remains good hygiene. The calculation changes as soon as forensic reports are enabled, which can carry third-party personal data in volume and at a far more intrusive granularity. That is one more reason, on the privacy front this time, to stick to aggregate by default — the very minimisation principle that structures this whole reasoning.

The double benefit: compliance and protecting people

There is an elegance to this intersection. Driving a domain to p=reject meets the security obligation and directly protects the data subjects — clients, users, employees — against frauds that would exploit the organisation's identity to extract their data. Compliance and real protection point, here, in the same direction, which is far from always the case in regulatory matters.

It is also why entities subject to NIS2 or other sector regimes gain from treating DMARC as a common control: the same effort satisfies GDPR's security obligation, the regulatory resilience requirement, and the concrete protection of people. In practice, that makes the budget conversation easier too: one line item, several boxes ticked, and a measurable reduction in the incidents that would otherwise cost far more to clean up than to prevent.

Privacy by design, in practice

There is a quiet lesson here about privacy by design. The right DMARC setup is also the privacy-minimal one: aggregate reports for the security value, forensic switched off to avoid hoovering up third-party personal data. There is no trade of security against privacy — the same configuration optimises both. That coincidence is rare enough in regulatory life to be worth naming, and it makes the decision easy: enforcing the policy, keeping the reporting aggregate, bounding the retention — and Article 32 is satisfied, the processing minimised, and the hardest privacy questions spared, in one move. When a control's most secure setting is also its most privacy-respecting, there is no dilemma left to resolve — only the work to do.

Measuring the real exposure

It all starts with the free diagnosis. A pass of the domain through our free DMARC analyzer says whether it is currently spoofable, and our privacy policy shows how we apply these very principles to domain analysis ourselves. The posture of a whole sector compares, for its part, in the DMARC Observatory.

Framing authentication properly — policy enforcement on the security side, cautious report settings on the privacy side — is exactly what Thomas, the virtual CISO, is for: he identifies the sending sources from aggregate reports, never depending on forensic, and guides the climb to p=reject. Free domain analysis · exploring the Observatory · getting started with Thomas.