What information is contained in DMARC RUA and RUF reports?
Published 12 Jun 2025
Updated 5 Oct 2026
12 min read
Summarize with
Updated on 5 Oct 2026: We clarified how to read DMARC authentication results, RUF failure triggers and the current report formats.
RUA means Reporting URI for Aggregate data. 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 DMARC alignment, and which domain appeared in the RFC5322.From field. It does not include the email body, attachments, subject line, or the full recipient address.
RUF means Reporting URI for Failure data. A RUF report is a per-message failure report, so it can include headers, authentication results, source details, and sometimes the entire failed message. RUF needs controls for sensitive data. It is also optional because most mailbox providers do not send it at meaningful scale. Receivers can group repeated failures using an Incidents field, so RUF is not a complete message-by-message log.
RUA is aggregate authentication data, while RUF is message-level 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 has a lower message-privacy risk, but RUF needs the same care as other sensitive mail evidence.
Current standards for RUA and RUF reports
The current standards split DMARC across three documents. RFC 9989 defines the core protocol, RFC 9990 defines aggregate reporting, and RFC 9991 defines message-specific failure reporting. Together they obsolete RFC 7489. Existing DMARC1 records remain recognizable, but some old tags and report assumptions have changed.
- Historic tags: The pct sampling tag, ri reporting-interval tag, and rf failure-format tag are now historic. Do not add them to new records.
- Aggregate reports: RFC 9990 defines the dmarc-2.0 XML namespace and policy discovery details, and requires a DKIM selector when a signature is reported. Receivers using older schemas can omit newer fields.
- Failure reports: RFC 9991 retains message-specific reports and the required Identity-Alignment field, and requires report generators to rate-limit outgoing reports.
- Report cadence: Receivers should send aggregate reports at least once every 24 hours, but the receiver still controls whether it reports and how often.
Do not use an old pct value to stage enforcement. Under RFC 9989, pct has no active role. Stage policy by monitoring legitimate sources, correcting authentication, and changing the p value when the evidence supports it.
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 usually compressed with GZIP as an .xml.gz attachment and normally arrives daily or more often, though exact timing depends on the receiver. It groups observations rather than giving you one row per email.
A parsed RUA report has report metadata, the published DMARC policy, identifiers used for policy evaluation, and records for each observed sending pattern. For a deeper sample, compare this explanation with example RUA reports.
|
|
|
|---|---|---|
Scope | Aggregate | Message-level |
Format | XML, usually GZIP-compressed | AFRF in a MIME message |
Original content | Not included | Can appear |
Recipient | Domain only, if supplied | Full address can appear |
Normal use | Monitoring | Investigation |
Availability | Common | Rare |
RUA vs RUF report contents and formats
- Metadata: The reporting organization, contact address, report ID, UTC reporting period expressed as Unix timestamps, optional errors, and optional generator details.
- Policy: The policy domain and p value, plus optional discovery method, sp, np, fo, SPF and DKIM alignment modes, and testing fields.
- Source: The IP address that connected to the receiver and the number of messages in the matching result group. For forwarded mail, this can be a relay rather than the original sending server.
- Evaluation: The DMARC disposition (none, pass, quarantine, or reject), DMARC alignment results for SPF and DKIM, and any policy override reason.
- Authentication results: SPF and DKIM domains, DKIM selectors, verification outcomes, and optional human-readable result details.
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>
The count covers messages received during the reporting period, including messages later blocked by another filter. It is not a delivered-message total. Coverage includes only participating receivers, so the totals are not a complete count of all mail sent.
How to read authentication results and DMARC alignment
A raw SPF or DKIM pass does not guarantee a DMARC pass. In auth_results, results describe authentication alone. In policy_evaluated, SPF and DKIM results also include alignment with the visible From domain. RFC 9990 defines this distinction.
DMARC passes when at least one authentication method passes with a matching domain. Relaxed alignment permits a shared organizational domain; strict alignment requires an exact domain match, as defined in RFC 9989.
|
|
|
|
|---|---|---|---|
SPF | sender.example.net | pass | fail |
DKIM | example.com | pass | pass |
Illustrative results when the visible From domain is example.com.
This message passes DMARC through DKIM. A none disposition does not prove inbox delivery; it can reflect monitoring or a local policy override. RFC 9990 also allows pass for successful DMARC under an enforcing policy.
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, including sending IPs, volumes, authenticated domains, and receiving domains. If one campaign used a dedicated IP during a narrow time window, the aggregate row can still reveal activity to someone who already has context.
RFC 9990 permits optional envelope_to and envelope_from domains in the identifiers section. These fields remain domain-level and do 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: Current reports can label the SPF identity as mfrom. DMARC evaluates the MAIL FROM identity; with a null reverse-path, SPF derives that identity using the HELO domain.
- Filenames: RFC 9990 report filenames identify the policy domain, reporting receiver and reporting-period timestamps. The policy domain can differ from a message's RFC5322.From domain.
DMARC RUA report fields: source IP, message count and authentication results, excluding the email 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. A receiver normally generates the report soon after detecting a failure, but the exact contents and rate limits depend on the receiver's policy.
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: A report can describe one failed message or group similar failures using Incidents.
- 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, arrival time, message identifiers, original headers, or the entire message. DMARC failure reports use Authentication Failure Reporting Format (AFRF), an ARF-based MIME message with machine-readable fields and an original-message or headers part. RFC 9991 defines Identity-Alignment to show which authentication methods failed to produce an aligned identity. RUF can expose personally identifiable information (PII), and receivers control redaction. RUF addresses should have restricted access, short retention, documented handling rules, and secure transport.
Example RUF feedback fields (excerpt)text
Feedback-Type: auth-failure User-Agent: receiver.example Version: 1 Original-Mail-From: bounce@sender.example.net Authentication-Results: mx.example; dmarc=fail header.from=example.com Reported-Domain: example.com Source-IP: 203.0.113.10 Auth-Failure: dmarc Identity-Alignment: dkim, spf Delivery-Result: reject Incidents: 1
In this example, SPF authenticates sender.example.net, which does not match the visible From domain example.com. DKIM fails, so neither method supplies a DMARC pass and Identity-Alignment lists both methods.
How fo controls failure reports
The fo tag requests failure-report triggers; it does not change enforcement and is ignored without ruf. The options are defined in RFC 9989.
|
|
|---|---|
fo=0 (default) | Neither SPF nor DKIM produces a matching pass. |
fo=1 | Either method lacks a matching pass, even if the other passes DMARC. |
fo=d | A DKIM signature fails verification, regardless of domain matching. |
fo=s | SPF verification fails, regardless of domain matching. |
Failure-report requests remain subject to receiver support and policy.
Combine options with colons, such as fo=1:d, but never combine 0 and 1. Receiver policy and rate limits determine what arrives. Check RUA/RUF requirements for reporting-address rules.
Privacy risks in RUA and RUF reports
RUA exposes mail flow metadata; RUF can expose individual message contents. RUA is usually appropriate for security and deliverability teams, but it still describes real mail flow. RUF is a different class because it can contain individual message evidence. Its limited availability does not reduce the need to handle it carefully when it arrives.
Privacy exposure by report type
Illustrative privacy categories for DMARC reporting data, rather than a measured risk score.
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 or the full message.
A lack of email content does not mean a lack of sensitivity. RUA can still disclose vendors, sending services, unauthorized infrastructure, and traffic patterns. That justifies access controls, but the data cannot 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, and then raise policy in stages. Suped's product is built around that workflow. It parses aggregate reports, groups sending sources, flags authentication problems, and provides steps to fix SPF, DKIM, and DMARC issues.
Use Suped's DMARC monitoring to review aggregate authentication results before changing policy. For this workflow, the useful result is a decision: approve a source, fix a selector, remove a sender, or move the policy forward.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
Do not build a DMARC program around RUF. Collect RUA, watch for unknown sources, validate the DNS record, and keep failure evidence as an optional investigative feed 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, confirm that reports are arriving, that any external reporting destination is authorized, and that the policy matches the rollout stage.
- Collect: Send RUA to a mailbox or platform that can parse XML, deduplicate reports by report ID, and preserve daily history.
- Group: Sort by source IP, sending service, RFC5322.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 DMARC.
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. Publish the TXT value at _dmarc.example.com; reporting is available with p=none.
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
When a rua or ruf address uses a different organizational domain, that destination must authorize the relationship in DNS. For reports sent to agg@destination.example on behalf of example.com, the destination publishes a TXT record at example.com._report._dmarc.destination.example with the value v=DMARC1. Without authorization, conforming receivers ignore the external URI.
External report authorization TXT valuedns
example.com._report._dmarc.destination.example IN TXT "v=DMARC1;"
If you want Suped's product to manage policy staging without repeated DNS edits, Hosted DMARC keeps the record easier to change. If you are drafting a record, the DMARC record generator gives you a TXT value for the policy and reporting addresses you choose.
A sound default is to publish RUA first, confirm report flow, identify legitimate senders, and 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 defined 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 identity, and DKIM selector together to identify the real sending path.
Keep RUF retention short because the report can hold headers or the entire failed message.
Check external destination authorization when expected RUA or RUF reports do not arrive.
Marketer view
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 view
Marketer from Email Geeks says RUF reports are more identifying when they arrive, but receiving them is uncommon.
2024-02-05 - Email Geeks
Practical recommendation
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, use it only as a controlled supplement. A DMARC program should rely on RUA, working authentication, staged policy enforcement, and clear alerting.
Frequently asked questions
RUA means Reporting URI for Aggregate data. RUF means Reporting URI for Failure data. The tags specify where receivers should send each report type.
No. Normal RUA reports do not show the full recipient address or mailbox local part. Some reports can show the recipient domain or receiver context.
No. RUA reports do not include the message body, attachments, subject line, or full original headers. They contain aggregate authentication data.
Yes. RUF reports can include per-message failure data, headers, or the entire failed message when a receiver sends them without heavy redaction.
Add RUF only when you have a controlled mailbox, a defined security use case, and retention rules. Most teams get their day-to-day value from RUA.
Check the rua or ruf syntax, destination mailbox, receiver support, and external destination authorization. Aggregate reports normally arrive daily rather than immediately, and RUF support is limited. A receiver must ignore an external report URI when the destination domain has not authorized it in DNS. No RUF reports does not prove that all messages passed DMARC.
