Where can I find example DMARC RUA reports?
Published 19 Jun 2025
Updated 4 Oct 2026
11 min read
Summarize with
Updated on 4 Oct 2026: We clarified where to find current and real-world RUA samples and added a practical reading of the sample XML.
The quickest ready-made DMARC RUA example is the sample XML in RFC 9990 Appendix B. To see how receivers report your own mail, publish a rua address and send messages through your normal mail streams. The older dmarc.org 0.1 XML schema describes legacy report data. For screenshots or parser tests, a synthetic sample is safer than sharing a raw report containing someone else's infrastructure and domain data.
- Fastest: inspect the RFC 9990 sample or the synthetic XML below.
- Best for your domain: publish p=none on a test domain and collect reports from participating receivers.
- Safest: use synthetic XML with realistic fields, then clearly label it as sample data.
- Best for parser testing: keep one RFC 9990 sample and at least one legacy receiver-made report.
- Best for operations: use parsed reports in Suped's product for source identification, issue tracking, policy staging, and alerts.
Suped's product is built for teams that need more than one-off XML. Its DMARC monitoring parses aggregate reports, maps sending sources, surfaces SPF and DKIM alignment failures, supports staged policy changes, and sends alerts when authentication changes.
Where to find example RUA reports
Useful example DMARC RUA reports come from RFC 9990 Appendix B, a controlled test domain, an existing DMARC reporting inbox, a redacted file from a trusted sender, or synthetic XML built to match the aggregate report schema. If the goal is a screenshot, a synthetic or redacted file works. If the goal is parser testing, use current and legacy reports with passing and failing results, plus policy override cases.
|
|
|
|---|---|---|
RFC 9990 Appendix B | Current schema | One simple row |
Test domain | Clean samples | Wait for receiver reports |
Live inbox | Real sender data | Needs redaction |
Trusted file | Screenshots | Permission and redaction |
Synthetic XML | Docs and tests | Not receiver-made |
Practical sources for DMARC RUA sample data.
The key caveat is privacy. A real RUA report can expose source IPs, envelope domains, header From domains, selector names, policy results, report IDs, and mail volumes. This is operational data, so redact it before sharing the report outside the team.
A useful sample set
- Passing mail: one record where SPF or DKIM passes and aligns with the header From domain.
- Failing mail: one record where both authentication methods fail DMARC evaluation.
- Mixed volume: one report with more than one record node so parser output looks realistic.
- Policy data: one report showing p=none and one showing an enforcement policy.
- Override data: one record with a reason element when the applied disposition differs from the published policy.
Collect sample reports from a test domain
The cleanest method is to create a low-volume test domain and publish a DMARC record with a working aggregate reporting mailbox. Start with monitoring mode, send a few messages through your usual systems, then wait for participating receivers to send aggregate XML. A record generator helps avoid syntax mistakes when you are setting this up quickly.
Simple DMARC record for receiving RUA reportsDNS
_dmarc.example.com. TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc-aggregate@example.com" )
After the record is live, send mail through each sender you want represented in the sample. For example, send one message through your main mailbox provider, one through a marketing platform, another through a support system, and one through a transactional relay. Use a small audience you control. A participating receiver can send an XML attachment later, commonly on a daily cycle. RFC 9990 recommends GZIP compression, but plain XML is also valid.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
If the reporting mailbox sits on a different organizational domain than the protected domain, the report destination needs authorization. The explanation of external report addresses provides a useful walkthrough, and the DNS pattern below remains valid under RFC 9990.
External RUA authorization exampleDNS
_dmarc.example.com. TXT ( "v=DMARC1; p=none; " "rua=mailto:reports@reports.example.net" ) example.com._report._dmarc.reports.example.net. TXT "v=DMARC1"
If no report arrives, confirm the rua mailbox accepts attachments, check the external authorization record when applicable, and send to a receiver that issues aggregate reports. An empty inbox does not prove that DMARC passed or failed.
What a DMARC RUA report looks like
A DMARC RUA report is an aggregate XML file, usually delivered as a GZIP-compressed email attachment. The file contains report metadata, the UTC reporting period, the published DMARC policy, and one or more traffic rows. The most useful fields are covered in more depth under RUA report contents, but the synthetic RFC 9990-format sample below is enough for screenshots and current-schema parser tests.
Synthetic RFC 9990 DMARC RUA XML sampleXML
<?xml version="1.0" encoding="UTF-8" ?> <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"> <version>1.0</version> <report_metadata> <org_name>Example Receiver</org_name> <email>dmarc-support@example-receiver.test</email> <report_id>2026-07-24-example-001</report_id> <date_range> <begin>1784851200</begin> <end>1784937599</end> </date_range> <generator>Example DMARC Aggregate Reporter 2.0</generator> </report_metadata> <policy_published> <domain>example.com</domain> <p>none</p> <sp>none</sp> <np>none</np> <adkim>r</adkim> <aspf>r</aspf> <testing>n</testing> <discovery_method>treewalk</discovery_method> </policy_published> <record> <row> <source_ip>192.0.2.10</source_ip> <count>14</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <envelope_from>mail.example.com</envelope_from> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>example.com</domain> <selector>selector1</selector> <result>pass</result> </dkim> <spf> <domain>mail.example.com</domain> <scope>mfrom</scope> <result>pass</result> </spf> </auth_results> </record> <record> <row> <source_ip>198.51.100.25</source_ip> <count>3</count> <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <envelope_from>example.net</envelope_from> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>example.net</domain> <selector>mail</selector> <result>fail</result> </dkim> <spf> <domain>example.net</domain> <scope>mfrom</scope> <result>fail</result> </spf> </auth_results> </record> </feedback>
Flowchart showing how a sent message becomes a DMARC RUA XML attachment and parser input.
Do not treat that XML as a full production fixture. Real reports differ by receiver. Some include optional fields or extensions, some group rows differently, and some use provider-specific report IDs. Keep reports from at least two receivers when testing a parser, even if the public screenshot uses a short sample.
How to read the sample RUA report
The two records cover one receiver's UTC reporting period. Each count is the number of messages grouped under that row's source IP and results, not the total mail your domain sent everywhere.
- Report scope: report_metadata names the receiver and reporting period; policy_published records the domain policy it observed.
- First row: 14 messages came from 192.0.2.10. Both DKIM and SPF passed DMARC alignment with example.com.
- Second row: 3 messages came from 198.51.100.25. Both DMARC alignment results failed.
- Two kinds of results: policy_evaluated gives DMARC-aligned results and disposition; auth_results lists the underlying DKIM and SPF checks.
Both rows show disposition as none because the published policy is p=none. That value does not tell you whether either message group reached an inbox. A raw SPF or DKIM pass also does not make DMARC pass unless its authenticated domain aligns with the header From domain.
Support current and legacy RUA formats
RFC 9990 now defines DMARC aggregate reporting, while RFC 9989 defines the core DMARC mechanism. RFC 9990 replaces the report format previously included in RFC 7489. A reporting inbox or sample archive can contain both formats during adoption, so parser fixtures should cover current and legacy XML.
|
|
|
|---|---|---|
XML namespace | urn:ietf:params:xml:ns:dmarc-2.0 | No dmarc-2.0 namespace |
Top-level version | Optional version 1.0 | Usually absent |
Policy fields | May include np and testing, plus discovery_method | May include the historic pct field |
Applied disposition | Can report pass | none, quarantine, or reject |
Extensions | Namespaced extension points | No defined extension points |
Key markers for current and legacy DMARC aggregate report samples.
Parser compatibility check
Detect the namespace before schema validation, require mandatory elements, allow optional elements, and preserve unknown namespaced extensions. Validate current samples against RFC 9990, not the older dmarc.org 0.1 XSD.
Use sample XML safely
Before sharing a real RUA report, redact the values that identify real infrastructure. Keep the shape of the XML intact. A broken sample teaches the wrong lesson, and a parser error caused by redaction wastes time.
Redact before sharing
- Domains: replace real organizational domains with reserved examples.
- IPs: use documentation networks such as 192.0.2.0/24 and 198.51.100.0/24.
- Mailboxes: remove private contact addresses from report metadata.
Keep the sample useful
- Structure: keep every XML element required by your parser.
- Results: include both pass and fail rows so dashboards have meaningful states.
- Dates: use a coherent begin and end range so charts render correctly.
If you only need a visual example, Suped's product can show the same aggregate evidence without asking people to read XML. The raw record drawer explains source IPs, authentication outcomes, sender identity, filtering, and CSV export in one place.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
A single RUA attachment is a point-in-time artifact. Suped's product turns the report stream into verified sending sources, grouped authentication issues, policy recommendations, and notifications when SPF or DKIM alignment starts failing.
Validate your live DMARC setup
A sample report answers "what does the file look like?" It does not prove that your current domain is configured correctly. For that, check the live DNS record and send real mail through each approved sender. A DMARC checker is useful for validating record syntax and policy tags before you wait for aggregate reports to arrive.
Do not over-read one report
A RUA report is authentication telemetry. It is not inbox placement testing or engagement reporting. Use it to identify who sent mail, whether SPF or DKIM passed DMARC alignment, and how the receiver applied your policy.
A production workflow starts with a valid record, collects reports, groups sources by owner, and reviews changes over time. This prevents the common mistake of treating every unknown IP as hostile. Some unknown sources are legitimate vendors that were never documented. Others are forwarding paths, old systems, or unauthorized senders that need policy enforcement.
How much confidence a sample gives you
Use sample files for structure, but use live reports for decisions.
Low
Structure only
One synthetic XML file
Medium
Parser check
One redacted receiver report
High
Policy work
Several live reports over time
If your real goal is to turn reports into readable output, sample files only get you started. A parsed view, sender mapping, issue list, and policy history make the report useful for remediation. The practical difference between raw XML and a working platform is explained in more detail in report analysis tools.
Views from the trenches
Best practices
Use a dedicated RUA mailbox so sample files stay separate from human mail and alerts.
Keep one passing sample and one failing sample so screenshots show both outcomes clearly.
Redact domains, IPs, selectors, and provider names before sharing XML outside your team.
Common pitfalls
Real RUA files often arrive compressed, so searching only for XML attachments misses samples.
Using one old report can hide alignment details and policy override cases during testing.
Publishing rua without a working mailbox creates reports that no one can inspect later.
Expert tips
Create a low-traffic test domain and send controlled messages through each approved sender.
Store raw XML next to parsed output so reviewers can confirm each dashboard result later.
Validate each sample after redaction so the XML structure and field values still parse.
Expert view
Expert from Email Geeks says public DMARC aggregate samples are harder to find than expected, so private redacted files often fill the gap.
2024-01-08 - Email Geeks
Marketer view
Marketer from Email Geeks says teams often need a screenshot-ready report faster than they need a full parser or live mailbox setup.
2024-01-08 - Email Geeks
Choose the right sample source
For a quick current-format example, use the synthetic RFC 9990-format XML above. To capture receiver behavior, generate a test-domain report with p=none. For a shareable real report, redact domains, IPs, mailboxes, selectors, and report IDs while preserving XML structure. For operational DMARC work, collect live aggregate reports and turn them into source ownership, fixes, policy stages, and alerts.
Suped's product fits that operational workflow by retaining report history, mapping sources to owners, surfacing SPF and DKIM alignment problems, and supporting staged DMARC policy changes without handing raw XML around the company.
Frequently asked questions
Yes, if it is redacted and you have permission to use it. Remove real domains, IPs, mailboxes, selectors, and report IDs before publishing or sharing it.
Many receivers send aggregate reports daily after they observe mail for your domain. Timing varies by receiver, and no report arrives when no participating receiver saw mail.
No. RUA reports are aggregate XML summaries. RUF reports are message-specific failure reports and are far less common because they can contain message data that requires stricter privacy handling.
Under RFC 9990, expect XML with an .xml filename or GZIP-compressed XML with an .xml.gz filename. Older receiver reports may still appear as .zip attachments, so a parser that handles archived samples should support both current and legacy delivery formats.
Yes. Suped's product parses aggregate reports into sending sources, authentication results, issue steps, and alerts so teams can act without manually opening XML attachments.
