DMARC RUA reports contain aggregate authentication data, not the content of individual emails. A normal RUA report tells you which source IPs sent mail for a domain, how many messages were seen, what DMARC policy was evaluated, whether SPF and DKIM passed, and which domain appeared in the visible Header From field. It does not include the email body, attachments, subject line, or the full recipient address.
RUF reports are different. A RUF report is a per-message failure report, so it can include headers, authentication results, source details, and in some cases enough original message material to identify the recipient or expose part of the message. I treat RUF as sensitive data. I also treat it as optional because most mailbox providers do not send it at meaningful scale.
The short answer is simple: RUA is operational telemetry, while RUF is individual failure evidence. RUA is the report type most teams should rely on for daily DMARC work.
- RUA: Aggregated XML data about sending sources, message counts, policy results, SPF, DKIM, and authenticated domains.
- RUF: Message-level failure data that can contain headers and other identifying details when a receiver sends it.
- Privacy: RUA is usually low risk for message privacy, but RUF needs the same care as other sensitive mail evidence.
What RUA reports contain
A RUA report is an aggregate XML file sent by a receiving mailbox provider to the address in your DMARC record's rua tag. The file is often compressed and delivered daily, though exact timing depends on the receiver. It groups observations rather than giving you one row per delivered email.
When I parse RUA, I expect a few major parts: report metadata, your published DMARC policy, and records for each observed sending pattern. For a deeper sample, compare this explanation with example RUA reports.
|
|
|
|---|---|---|
Scope | Aggregate | Message-level |
Content | No body | Possible |
Recipient | No local part | Can appear |
Use | Monitoring | Investigation |
Volume | Common | Rare |
Common fields in DMARC report types
- Metadata: The reporting organization, report ID, and date range covered by the file.
- Policy: The published DMARC policy, subdomain policy, percentage, and strict or relaxed SPF and DKIM modes.
- Source: The IP address that connected to the receiver and the number of matching messages.
- Evaluation: The receiver's policy result, including none, quarantine, or reject disposition.
- Auth results: SPF and DKIM domains, selectors, results, and the SPF scope where the receiver provides it.
Example RUA record fragmentxml
<record> <row> <source_ip>203.0.113.10</source_ip> <count>248</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>example.com</domain> <selector>s1</selector> <result>pass</result> </dkim> <spf> <domain>mail.example.com</domain> <scope>mfrom</scope> <result>pass</result> </spf> </auth_results> </record>
What RUA reports leave out
The most important privacy point is that RUA reports do not contain the original email content. They do not include the body, attachments, full message headers, or recipient mailbox local parts such as jane in jane@example.net. They are built for trend analysis and authentication debugging, not message reconstruction.
That does not make RUA anonymous in every sense. A RUA report can still expose operational details: sending IPs, volumes, authenticated domains, and the receiving domain in some cases. If one campaign used a dedicated IP and ran during a narrow time window, the aggregate row can still be revealing to someone who already has context.
Some receivers include extra identifier fields that are still domain-level, not person-level. Microsoft RUA reports can include envelope_to and envelope_from domains in the identifiers section. That still does not expose the local part of the recipient address.
- Recipient domain: A receiver can reveal that mail reached a domain such as example.net without naming a mailbox.
- SPF scope: Some reports include whether SPF was evaluated against the mail-from or HELO identity.
- Filenames: Report filenames sometimes hint at the Header From domain and the receiver that produced the report.
Infographic showing that RUA reports include source and authentication data but no message body.
What RUF reports contain
RUF reports are forensic or failure reports. Instead of summarizing many messages, a RUF report describes a specific message that failed DMARC or matched the failure options requested in the fo tag. The exact contents vary because receivers make their own privacy choices.
RUA
- Granularity: Aggregated rows by source IP and authentication result.
- Content: No original body, attachments, subject, or full headers.
- Reliability: The normal data source for DMARC monitoring and policy staging.
RUF
- Granularity: One failure report can describe one failed message.
- Content: Headers and original message material can appear if not redacted.
- Reliability: Most receivers send little or none, so plan without depending on it.
A RUF report can include the failure type, source IP, authentication results, envelope sender, portions of the original headers, and redacted or unredacted message samples. That is why I do not treat RUF addresses as ordinary shared inboxes. They need restricted access, retention limits, and clear handling rules.
Example RUF-style failure fieldstext
Feedback-Type: auth-failure User-Agent: receiver.example Version: 1 Original-Mail-From: bounce@example.com Authentication-Results: mx.example; dkim=fail; spf=pass Reported-Domain: example.com Source-IP: 203.0.113.10 Failure-Reason: DKIM signature did not verify
If you are choosing between report tags, start with RUA and RUF tags, then confirm the operational details against RUA/RUF requirements.
Privacy risk and inference
The privacy risk sits on a scale. RUA is usually safe enough for normal security and deliverability teams, but it still describes real mail flow. RUF is a different class because it can contain individual message evidence. The fact that RUF is uncommon does not reduce the need to handle it carefully when it arrives.
Privacy exposure by report type
A practical way to rank common DMARC reporting data by exposure risk.
RUA content exposure
Low
No body, subject, attachment, or full message header.
RUA inference exposure
Medium
Source IPs, volumes, and receiver domains can reveal patterns.
RUF exposure
High
Per-message evidence can include headers and body parts.
A common mistake is assuming that a lack of email content means a lack of sensitivity. RUA can still disclose vendors, sending services, unauthorized infrastructure, and traffic patterns. That is enough to justify access controls, but not enough to reconstruct what a recipient read.
- Safe assumption: RUA does not identify the exact recipient mailbox in normal reports.
- Careful assumption: RUA can identify the recipient domain or receiver in some provider output.
- Strict assumption: RUF can identify people or message details, so store it like sensitive incident data.
How to use the data in practice
The practical workflow is to collect RUA reports, group sources, verify which senders are legitimate, fix authentication gaps, then raise policy in stages. Suped's product is built around that workflow: it parses aggregate reports, groups sending sources, flags authentication problems, and gives concrete steps to fix SPF, DKIM, and DMARC issues.
For most teams, Suped is the best practical DMARC platform because it combines DMARC monitoring, hosted SPF, hosted MTA-STS, real-time alerts, blocklist (blacklist) monitoring, and multi-tenant reporting for MSPs. The important part here is not simply receiving XML. It is turning the report into a decision: approve this source, fix that selector, remove that sender, or move the policy forward.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
I would not build a DMARC program around RUF. I would collect RUA, watch for unknown sources, validate the DNS record, and keep failure evidence as an optional investigative feed only where receivers send it.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After checking the published record with the DMARC checker, I look at whether reports are actually arriving, whether the reporting address is authorized, and whether the policy matches the rollout stage.
- Collect: Send RUA to a mailbox or platform that can parse XML and preserve daily history.
- Group: Sort by source IP, sending service, Header From domain, and authentication result.
- Fix: Repair SPF, DKIM, and selector issues before tightening the DMARC policy.
- Stage: Move through none, quarantine, and reject only after legitimate sources pass.
A safe DMARC record setup
A safe starting record usually asks for RUA reports only. Add RUF only when you have a clear investigative reason, a restricted destination, and a retention policy. The receiving side still decides whether it sends RUF.
RUA-only DMARC TXT valuedns
v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com
RUA plus RUF DMARC TXT valuedns
v=DMARC1; p=quarantine; rua=mailto:agg@example.com; ruf=mailto:ruf@example.com
If you want Suped to manage policy staging without repeated DNS edits, Hosted DMARC keeps the record easier to change. If you are still drafting a record, the DMARC record generator gives you a clean TXT value for the policy and reporting addresses you choose.
My default is to publish RUA first, confirm report flow, identify all legitimate senders, then tighten policy. RUF is a separate decision, not a requirement for strong DMARC.
- Use RUA: It is the main signal for rollout, source discovery, and ongoing monitoring.
- Restrict RUF: Send it only to a controlled destination if your team has a real use for it.
- Document access: Give RUA to operators and keep RUF closer to security or incident response.
Views from the trenches
Best practices
Treat aggregate reports as operational data, but still restrict access to mail flow history.
Start with RUA-only reporting, then add forensic reporting only for defined security use cases.
Check provider-specific RUA fields before promising that no recipient domain data exists.
Common pitfalls
Assuming RUA reports name the recipient mailbox often leads to wrong privacy reviews.
Depending on RUF reports for routine monitoring fails because most receivers do not send them.
Sending forensic reports to a shared mailbox creates avoidable exposure and review noise.
Expert tips
Use source IP, SPF scope, and DKIM selector together to identify the real sending path.
Keep RUF retention short because the report can hold headers and message fragments.
Watch for receiver-specific filename patterns because they can reveal extra routing context.
Marketer from Email Geeks says RUA reports do not include message contents, and they are not meant to reconstruct individual emails.
2024-02-05 - Email Geeks
Marketer from Email Geeks says RUF reports are more identifying when they arrive, but receiving them is uncommon.
2024-02-05 - Email Geeks
My practical take
RUA tells you what happened to authentication across groups of messages. It gives enough detail to find broken senders, unauthorized sources, bad SPF paths, missing DKIM signatures, and policy outcomes. It does not show what the email said or who exactly read it.
RUF is closer to incident evidence. It can contain individual failure information and, depending on redaction, private message details. Because receiver support is limited, I use it only as a controlled supplement. The DMARC program should stand on RUA, clean authentication, staged policy enforcement, and clear alerting.
Suped fits this job when you need the RUA stream turned into source inventory, policy guidance, alerts, and fix steps instead of raw XML. That is the practical difference between having reports and actually running DMARC well.
