GDPR and DMARC reporting

10 April 2026 · 14 min read

DMARC reporting is one of the few places in email operations where a security control hands you, unprompted, a steady stream of data about other people's mail. The moment you publish a record with an rua or ruf tag, mailbox providers around the world begin posting you structured information about messages that used your domain: who sent them, from which IP, whether they passed authentication, and in the case of failure reports, sometimes the headers and body of individual messages belonging to real recipients. Under the UK GDPR and the EU GDPR, some of that data is personal data, and the act of collecting and storing it makes you a controller (or a processor) with obligations attached.

This article is specifically about the data-protection side of DMARC reporting: which fields in aggregate and forensic reports count as personal data, why forensic reports are the genuine compliance hazard while aggregate reports are largely benign, what lawful basis covers the collection, how retention and international transfers apply, and the concrete configuration choices that keep you compliant without losing the security benefit. It is not a general GDPR primer and not a general DMARC explainer. If you want the broader picture of what each report type contains, DMARC aggregate vs forensic reports covers the mechanics, and our compliance overview sits alongside this. Here we stay on the regulation.

Why DMARC reporting touches data protection at all

It surprises people that an email-authentication control raises GDPR questions. The confusion usually comes from thinking of DMARC as something you do to your own domain. But the reports do not describe your domain in the abstract. They describe messages, and messages have senders, recipients, IP addresses and, in the forensic case, content. Several of those fields are capable of identifying a natural person.

The GDPR applies to the processing of personal data: any information relating to an identified or identifiable natural person. "Processing" expressly includes collection, storage, structuring and retention, which is exactly what a DMARC report pipeline does. So the relevant question is never "does DMARC count as processing" (it does, the moment you store a report), but "which fields in these reports are personal data, and what therefore do I owe in respect of them".

The answer differs sharply between the two report types, and that difference is the single most important thing to understand. Aggregate reports were deliberately designed to be statistical and content-free. Forensic reports were deliberately designed to be detailed and per-message. One is a low data-protection risk you can manage with ordinary good practice. The other is a high-risk channel that most of the email industry has quietly abandoned precisely because of GDPR.

Aggregate reports (rua): low risk, but not zero

An aggregate report is a daily XML census. For each distinct sending source it tells you a source IP, a message count, the SPF and DKIM results, the domains those mechanisms authenticated, and the DMARC alignment and disposition. There are no subject lines, no recipient addresses, no message bodies. That design is exactly why aggregate reporting survived the arrival of the GDPR while forensic reporting did not.

A typical aggregate record row looks like this once decompressed:

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>318</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
</record>

The only field here that can be personal data is the source IP address. And IP addresses can be personal data. The position in EU law, established in the Breyer case (C-582/14) and carried into UK practice, is that a dynamic IP address is personal data in the hands of someone who has, or can lawfully obtain, the means to link it to an individual. For most aggregate-report source IPs, that linkage is implausible: they are the outbound mail servers of large sending platforms, corporate gateways and ESPs, not individual people's home connections. But the principle matters in two edge cases.

• Sole traders and very small senders on static IPs. If a self-employed person sends mail from a fixed IP that resolves to them, that IP relates to an identifiable individual.
• On-premises or residential senders. Occasionally an aggregate report surfaces a source IP that belongs to a single person's connection rather than shared infrastructure.

So the honest characterisation is: aggregate reports contain a small amount of data that is sometimes personal data, namely source IP addresses, and contain no message content whatsoever. That is a manageable, low-risk processing activity. You can and should collect aggregate reports. You simply treat the dataset as one that may contain occasional personal data, give it a lawful basis, retain it for a sensible period and secure it. Nothing exotic.

This is why every serious DMARC operator, including hosted services, collects aggregate data freely. The security value is enormous (it is the entire data source for reaching p=reject) and the data-protection footprint is light. The aggregate report (RUA) glossary entry has the field-by-field breakdown if you want it.

Forensic reports (ruf): the real compliance hazard

Forensic reports, also called failure reports, are a completely different proposition. Where an aggregate report is a count, a forensic report is a copy of an individual message that failed DMARC, generated at the moment of failure rather than batched. Defined in RFC 6591 using the Authentication Failure Reporting Format, a forensic report typically wraps a redacted or full copy of the offending message, and can include:

• The full message headers: From, To, Cc, Subject, Date, Message-ID and the Received chain.
• The recipient address the message was destined for.
• The source IP and SMTP transaction details.
• Often the message body, in whole or part.

Read that list again with a data-protection hat on. The To field is a named recipient: a natural person's email address, which is personal data by definition. The Subject line frequently contains personal data and not rarely special category data (think a subject line referencing health, a legal matter or finances). The body, if included, can contain anything. And here is the sting: the people whose personal data appears in a forensic report are almost never your contacts. They are the recipients of mail that spoofed your domain. You have no relationship with them, no notice given to them, and no realistic way to fulfil a data-subject request about data you received unsolicited from a third-party mail server.

That is the crux. A forensic report makes you the involuntary recipient of personal data, and sometimes sensitive personal data, belonging to people you have never dealt with, captured from messages you did not send. There is no clean lawful basis for accumulating that, no notice you can give the data subjects, and a real risk that a forensic mailbox slowly fills with exactly the kind of content a regulator would ask hard questions about.

Why the industry walked away from ruf

This is not a hypothetical worry that compliance teams invented. It is the documented reason the major mailbox providers stopped sending forensic reports. Faced with the GDPR's arrival, providers like Google, Microsoft and Yahoo recognised that emitting a forensic report meant they were disclosing their own users' message content (recipients, subjects, bodies) to a third party (you, the domain owner) without a basis for doing so. Rather than build a redaction-and-consent regime for a niche feature, they overwhelmingly stopped sending forensic reports altogether.

The practical consequence for you in 2026 is twofold:

1. If you publish a ruf tag, you will receive a trickle of forensic reports from a few smaller or regional providers, and on many domains, none at all. You cannot build any process on them.
2. Every forensic report you do receive is a small data-protection liability landing in your mailbox, unbidden.

This is the rare case where the compliant choice and the operationally sensible choice are the same: most domains should simply not publish a ruf tag. You lose almost no security signal, because aggregate reports already tell you which sources fail, and you avoid receiving third-party message content you have no good reason to hold. The forensic report (RUF) glossary entry expands on the format.

The controller and processor question

Once you accept that you are processing personal data (even just IP addresses), the next GDPR question is your role: are you a controller, a processor, or do you have a controller-processor relationship to document?

• If you run your own DMARC reporting in-house, collecting reports to a mailbox you own and analysing them yourself, you are the controller. You decide the purposes (improving email authentication and security) and the means (the pipeline, the retention). The obligations are yours.
• If you delegate reporting to a hosted DMARC provider, by pointing rua at their ingestion mailbox, that provider processes the report data on your behalf and at your direction. In most arrangements they are your processor, and you remain the controller. That relationship needs an Article 28 data-processing agreement (DPA) in place, specifying the scope, duration, security measures and sub-processors.

This matters when you choose a provider. A credible hosted DMARC service should offer a DPA, tell you where reports are stored, name its sub-processors and let you set retention. If a provider cannot answer where your report data lives or how long it keeps it, that is a procurement red flag, not a detail. Our own done-for-you DMARC service is built on this footing: aggregate-first collection, a defined retention window and EU/UK-appropriate handling, precisely so the compliance question has a clean answer.

Lawful basis: legitimate interests, done properly

Processing personal data under the GDPR needs a lawful basis from Article 6. For DMARC reporting, the basis that fits is almost always legitimate interests (Article 6(1)(f)). You have a clear, legitimate interest in protecting your domain from spoofing and phishing, in reaching enforcement without breaking legitimate mail, and in securing email for your own users and recipients. The processing is necessary to that interest (you cannot reach p=reject safely without reading the reports), and the impact on data subjects is minimal for aggregate data because it contains no content and only occasionally an identifying IP.

To rely on legitimate interests properly, do the three-part test and write it down as a short legitimate interests assessment (LIA):

1. Purpose: is there a legitimate interest? Yes: email-authentication security and anti-spoofing.
2. Necessity: is the processing necessary to achieve it? Yes: aggregate reports are the only practical data source for safe enforcement.
3. Balancing: does your interest override the rights of the data subjects? For aggregate data, yes, comfortably, given the absence of content and the minimal, often non-identifying, nature of the IP data. For forensic data, the balance tips the other way, which is another reason to avoid ruf.

That short assessment, recorded once, is what demonstrates accountability if anyone asks. It is not onerous, and it converts "we collect DMARC reports" from an unexamined habit into a documented, defensible processing activity.

Retention: keep less, for less time

The GDPR's storage-limitation principle says you keep personal data no longer than necessary for the purpose. DMARC reports age out of usefulness quickly, which makes retention easy to get right if you are deliberate about it.

• The operational value of an aggregate report is in the weeks-to-months window. You use recent reports to find unauthenticated senders, fix alignment and watch the aligned percentage climb. Older reports are useful for trend lines and seasonal sources, but the raw, IP-level detail loses value fast.
• A common and defensible pattern is to retain the granular, IP-level report data for a bounded period (for example, the rolling window your provider exposes for analysis) and keep only aggregated, non-identifying statistics beyond that: counts of aligned versus unaligned volume per sender, with no source IPs, for longer-term trend reporting.
• If you ever do receive a forensic report, retain it for the shortest time needed to investigate the specific failure, then delete it. Do not let a forensic mailbox become an indefinite archive of third-party message copies.

Set a retention period, write it down, and make sure your tooling or provider enforces it automatically. "We keep raw reports for 13 months then reduce to aggregate statistics" is a clean, explainable policy. "We keep everything forever in a mailbox nobody looks at" is the failure mode the storage-limitation principle exists to prevent.

International transfers: where do the reports go?

DMARC reports arrive from mailbox providers all over the world: a report about your domain might be generated by a receiver in the United States, the EU or anywhere else, and sent to wherever your rua mailbox lives. That raises the Chapter V question of international transfers, but with two clarifications that keep it proportionate.

• The receiver generating the report is not your transfer concern. A US mailbox provider sending you a report is acting on its own account; it is not your processor. Your transfer obligations attach to where you (and your processor) store and process the data once received.
• The transfer that matters is to your provider's infrastructure. If you use a hosted DMARC service, ask where it stores report data. If that storage is outside the UK/EEA, you need an appropriate transfer mechanism (an adequacy decision, the UK International Data Transfer Agreement, or EU Standard Contractual Clauses) in the DPA, plus a transfer risk assessment where required.

For most organisations the pragmatic answer is to choose a provider that stores report data in the UK or EEA, or under a documented transfer mechanism, so the question is answered at procurement rather than left dangling. Because aggregate reports carry no content and only sometimes an identifying IP, the residual risk is low, but the obligation to have a mechanism in place is still real where data leaves the UK/EEA.

A concrete compliant configuration

Putting the data-protection reasoning into an actual DMARC record, the compliant default for almost every domain is: collect aggregate reports, skip forensic reports, point reporting at a dedicated mailbox or a provider with a DPA.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; ri=86400"

Note what is deliberately absent: there is no ruf tag. You are requesting the statistical aggregate stream and nothing else. The fo=1 is harmless here because, with no ruf destination, no failure reports are generated; you can leave it in for the day you might add limited forensic collection under controlled conditions, or drop it for clarity.

If, after a documented assessment, you have a genuine reason to collect forensic reports (some security teams want them transiently during active incident response), do it deliberately and defensibly:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; fo=1; ri=86400"

If you publish ruf, the data-protection controls are not optional:

• Treat the forensic mailbox as containing sensitive data. Restrict access to named individuals, log access, and never feed it into a general inbox or shared tooling.
• Set a short, enforced retention and delete reports once the specific investigation is done.
• Record in your LIA why the additional processing of third-party message content is justified, because the balancing test is much harder to pass for forensic data than for aggregate data.
• Expect to receive very little anyway, and never build a dependency on it.

Before you publish anything, confirm what is actually live with the DMARC checker; it splits out your rua and ruf URIs so you can see exactly what data you are inviting. If you are building the record from scratch, the DMARC record generator writes the tags in the correct order, and you can choose to leave ruf out from the start.

Delegated reporting and external destination consent

There is a neat detail of the DMARC standard that doubles as a privacy safeguard, and it is worth understanding in a GDPR context. If your rua or ruf mailbox is on a different organisational domain from the domain being reported on (which is exactly the case when you delegate to a hosted provider), receivers must perform an external destination verification before sending any reports there. They look up a TXT record at a specially named host under the destination domain:

example.com._report._dmarc.provider.example.  IN  TXT  "v=DMARC1"

That record is the destination domain consenting, in DNS, to receive reports on behalf of example.com. The mechanism exists to stop anyone from naming an innocent third party as the dumping ground for someone else's report traffic. From a data-protection angle it is a small structural guarantee that report data only flows to destinations that have explicitly agreed to receive it, which is the kind of purpose-limitation control that aligns nicely with the GDPR's data-flow expectations. If you delegate reporting and reports never arrive, a missing consent record is a common cause; a reputable provider publishes it for you.

Data-subject requests and accountability in practice

Two practical GDPR obligations deserve a direct answer in the DMARC context.

Subject access and erasure. If you collect only aggregate reports, a data-subject request is straightforward to handle: the only potentially personal field is the source IP, your retention window is short, and you can describe the processing clearly. If you collect forensic reports, you may be holding personal data about people you cannot identify or contact, which makes any request involving that data difficult to fulfil. This asymmetry is, once more, a strong argument for the aggregate-only default.

Records of processing and the privacy notice. Add DMARC reporting to your Article 30 record of processing activities as a discrete activity: purpose (email-authentication security), categories of data (source IP addresses from aggregate reports; if applicable, message metadata and content from forensic reports), lawful basis (legitimate interests), retention period, and recipients (your hosted provider, if any). A line in your privacy notice acknowledging that you process technical email-authentication data for security purposes covers the disclosure side. None of this is heavy; it is the same accountability paperwork you already do for other security telemetry, scoped to a well-bounded dataset.

The practical takeaway

DMARC reporting and the GDPR are entirely compatible once you separate the two report types. Aggregate reports carry no message content and only an occasional identifying IP address; collect them freely under legitimate interests, give them a documented retention period, secure the mailbox, and pin down where a hosted provider stores them. They are the data that gets you to p=reject, and the compliance cost of holding them is low. Forensic reports are the genuine hazard: they contain recipients, subjects and bodies belonging to people you have no relationship with, which is exactly why the major providers stopped sending them and exactly why most domains should leave the ruf tag off the record entirely. Default to aggregate-only, write a one-page legitimate interests assessment, set a retention period your tooling enforces, and document where the data lives.

Check what your current record actually requests, including any stray ruf destination, with the free DMARC checker, and read the wider context in our compliance guide. If you would rather not stand up a report pipeline and a retention policy yourself, our done-for-you DMARC service collects aggregate reports under a clear data-processing agreement, retains them for a defined window, and takes your domain from p=none to p=reject with no email outage, so the security outcome and the data-protection paperwork are both handled.