DMARC reports are usually less sensitive than people fear, but not so harmless that they should be thrown into an ordinary shared mailbox and kept forever.
That is the practical middle ground.
Aggregate rua reports are mostly domain-level telemetry. They tell you which sources claimed to send mail for your domain, how SPF and DKIM evaluated, what policy was seen, and how receivers handled the traffic. Failure ruf reports are a different class of data entirely: they can include message-level details, and that is where privacy and compliance questions get much sharper.
If a team wants the short version, it is this:
rua is usually operational telemetry, not message content collectionruf can contain much more sensitive material and deserves tighter handlingIn RFC 7489, DMARC defines two reporting channels:
rua for aggregate reportsruf for failure reportsThose two tags are often discussed together, but from a privacy and compliance perspective they should be treated as different risk categories, not as two flavors of the same thing.
Aggregate reports are XML summaries. They are about traffic patterns over a reporting period. Failure reports are incident-style reports about specific messages or authentication failures.
That single difference explains most of the confusion admins run into.
rua aggregate reportThe current IETF aggregate-reporting draft, which documents the format modern receivers use, describes aggregate reports as data about authentication results, policy evaluation, sending IPs, counts, identifiers, and related metadata. In plain terms, that usually means things like:
header_from domain and usually the envelope-from domainWhat you do not normally get in rua is the full original message, the message body, or a list of recipient addresses.
That is why rua is so useful operationally. It gives enough visibility to build sender inventory, detect spoofing, and track rollout without routinely shipping copies of email content around.
If the goal is understanding how to use that data in day-to-day DMARC work, DMARC reporting 101 and Building a sender inventory with DMARC reports before enforcement go deeper on the operational side.
ruf failure reportThis is where the privacy posture changes.
ruf reports can include message-level diagnostic data. RFC 6591, the ARF extension used for authentication-failure reporting, allows fields such as:
Authentication-ResultsOriginal-Mail-FromSource-IPReported-DomainThat is not abstract metadata anymore. That can be sensitive operational data, and sometimes sensitive personal data as well, depending on what the original message contained and how much redaction the receiver applied.
This is also why many receivers are conservative with ruf, or do not send it at all. The DMARC spec itself warns about privacy exposure, and RFC 6590 exists specifically because redaction became necessary once abuse and authentication reports started carrying information that could identify end users.
The most common misunderstanding goes in one of two bad directions:
Both are too simple.
For rua, the better answer is: usually no direct end-user content, but not automatically zero privacy relevance.
Why? Because aggregate reports still contain source IP addresses, domains, timestamps, and traffic patterns. In many organizations that is low-risk operational telemetry. In some legal or policy contexts, especially when IP addresses can be tied back to a natural person or a very small sender population, that data may still deserve treatment as personal or sensitive metadata.
So when someone says "RUA contains no PII," what they often really mean is:
That narrower claim is usually fair. The stronger claim, that aggregate reports are never privacy-relevant, is the one that causes trouble.
For ruf, the misconception runs the other direction. Some teams assume failure reports are just a more detailed rua. They are not. They can contain substantially more revealing information and should be governed that way.
RFC 7489 says DMARC feedback can expose sender and recipient identifiers, message content, and forwarding destinations, and that report generators need to consider their privacy policies before sending reports.
That warning is especially important for failure reporting, but it also tells you how to think about compliance more broadly: the right question is not "is this technically a DMARC report?" The right question is "what exact fields are leaving one administrative boundary and entering another?"
RFC 6590 adds another useful reality check. Redaction helps, but it does not guarantee perfect anonymization. Other unredacted fields can still allow correlation back to the original user or message. That matters when someone assumes redaction automatically makes retention or third-party sharing risk-free.
For most domain owners, this rough model is good enough:
ruaTreat rua as operational security telemetry.
Typical handling:
rufTreat ruf as potentially message-derived security evidence.
Typical handling:
This is not legal advice, and local rules vary, but as an engineering default it is a much healthier model than lumping both report types together.
DMARCPal focuses on aggregate rua reporting and intentionally does not process ruf, which keeps DMARC monitoring simpler and more privacy-preserving for the workflows most teams actually need.
Retention arguments often get framed as "keep everything forever because maybe it will be useful later." That is how monitoring mailboxes turn into unowned archives.
A safer approach is to separate raw evidence, normalized telemetry, and long-term trends.
Raw XML is most valuable while:
After that, many teams get more value from normalized summaries than from the original attachments.
Trend data such as source counts, aligned-pass rates, new-sender detection, and policy progress is often what teams actually need over time.
That means a sensible pattern is:
rua filesThis reduces storage of unnecessary raw material while preserving operational history.
ruf for the shortest period that still supports the use caseIf ruf is enabled for debugging or abuse investigation, define that purpose in advance.
Examples:
When that purpose ends, the default should be deletion, not indefinite archival.
Do not let a shared mailbox become the retention policy.
Use:
That last point gets missed constantly. Deleting reports from the mailbox but keeping them forever in backup snapshots is not much of a deletion story.
DMARC allows external reporting destinations, but operationally that means another organization may receive data about your traffic, your senders, and possibly failed-message details. If you rely on delegated reporting, DMARC external report destinations covers the DNS authorization mechanics, but the privacy review is separate and just as important.
The question is not only "is the destination authorized?" It is also:
ruf at all?The exact numbers depend on your environment, but this is a practical starting template:
rua attachments: retain for a limited operational windowrua aggregates and trends: retain longer if they support baselining and auditabilityruf reports: retain only for the shortest justified investigation windowWhat matters most is not the perfect number of days. What matters is that the retention period is intentional, documented, and tied to a use case.
A useful answer is:
rua reporting as controlled security telemetry.ruf separately because it can carry message-level details.That framing usually leads to a better outcome than treating all DMARC reporting as either harmless plumbing or forbidden sensitive content.
rua and ruf should not share the same privacy assumptions.
Aggregate rua reports are usually domain-level operational data and are the normal backbone of DMARC monitoring. Failure ruf reports can expose much more and deserve tighter controls, shorter retention, and more careful review.
The safest mature approach is simple:
rua for ongoing monitoringruf as an exception path, not the defaultThat gives you the visibility DMARC reporting is meant to provide without casually turning report mailboxes into a long-lived privacy problem.