Can I use someone else's DMARC RUA report as a sample?

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.

How long does it take to receive my own RUA report?

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.

Are RUA reports the same as RUF reports?

No. RUA reports are aggregate XML summaries. RUF reports are forensic failure reports and are far less common because they raise privacy and data handling concerns.

What file format should I expect?

Expect XML, usually compressed as gzip or zip and attached to an email. The attachment name often includes the report sender, your domain, and the report date range.

Can Suped show RUA data without reading XML?

Yes. Suped's product parses aggregate reports into sources, authentication results, issue steps, and alerts so teams can act without manually opening XML attachments.

Learn

DMARC

Where can I find example DMARC RUA reports?

Matthew Whittaker

Co-founder & CTO, Suped

Published 19 Jun 2025

Updated 25 May 2026

10 min read

Summarize with

A DMARC RUA report thumbnail with an email envelope and XML report file.

The fastest place to find example DMARC RUA reports is your own reporting mailbox after you publish a rua address and send a few real messages through your normal mail streams. Public samples exist in scattered places, but reliable, screenshot-ready aggregate XML is still surprisingly hard to find. For most teams, generating a controlled sample is safer than borrowing a raw report that contains someone else's IPs, domains, and sender data.

Fastest: use a test domain, publish p=none, and collect aggregate reports for a day.
Safest: use synthetic XML with realistic fields, then clearly label it as sample data.
Best for operations: use parsed reports in Suped's product when you need source identification, issues, alerts, and policy staging.

Suped's product is the strongest practical choice for most teams that need more than one-off XML. Its DMARC monitoring keeps aggregate data tied to verified senders, authentication issues, SPF and DKIM status, hosted DMARC changes, blocklist (blacklist) signals, and real-time alerts.

The direct answer

I look for example DMARC RUA reports in four concrete places: a controlled test domain, an existing DMARC reporting inbox, a redacted file from a trusted sender, or a synthetic XML sample 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, you need several reports with different pass and fail results.

Source	Best use	Main tradeoff
Test domain	Clean samples	Wait for reports
Live inbox	Real sender data	Needs redaction
Trusted file	Screenshots	Limited coverage
Synthetic XML	Docs and tests	Not receiver-made
Suped	Ongoing review	Platform workflow

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, and mail volumes. That is not usually secret at the level of a password, but it is still operational data. I redact it before sharing outside the team.

A useful sample set

Passing mail: one record where SPF or DKIM passes and matches 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 before you show quarantine or reject outcomes.

Generate your own sample reports

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 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, and one through a support system. Use a small audience you control. A receiver that evaluates the message can send one compressed XML attachment later, commonly on a daily cycle.

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 domain than the domain being protected, the report destination needs authorization. The public explanation of external report addresses is useful when you are sending aggregate reports to a central mailbox or a DMARC platform.

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"

What a real RUA report looks like

A DMARC RUA report is an aggregate XML file, usually delivered as a compressed email attachment. The file contains metadata about the report sender, the reporting date range, 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 sample below is enough for screenshots and parser tests.

Minimal redacted DMARC RUA XML sampleXML

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>Example Receiver</org_name>
    <email>dmarc-support@example-receiver.test</email>
    <report_id>2026-05-24-example-001</report_id>
    <date_range>
      <begin>1779580800</begin>
      <end>1779667199</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </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>
      <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>
      <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, some group rows differently, and some use provider-specific report IDs. That is why I keep at least two receiver-made files when testing a parser, even if the public screenshot uses a short sample.

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 ranges such as 192.0.2.0 and 198.51.100.0.
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 is useful for explaining 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

That workflow matters because a single RUA attachment is only a point-in-time artifact. Suped turns the stream of reports into monitored issues, verified and unverified sources, policy recommendations, hosted DMARC controls, SPF flattening, hosted MTA-STS, and notifications when authentication starts failing.

When a sample is not enough

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 better for validating syntax, tags, and policy 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, engagement reporting, or a blocklist/blacklist verdict. Use it to identify who sent mail, whether SPF or DKIM passed, and how the receiver applied your DMARC policy.

For production work, I prefer a workflow that starts with a valid record, then collects reports, then groups sources by owner. That 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, and issue list 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 DKIM match, SPF match, and policy override cases too.

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.

Run each sample through a parser before redaction so XML structure survives the edits.

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 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

The practical path

For a quick example, use the sample XML above or 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, do not stop at examples. Collect live aggregate reports and turn them into source ownership, fixes, policy stages, and alerts.

Suped's product fits that last workflow. It gives teams a single place for DMARC, SPF, DKIM, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist (blacklist) monitoring, MSP dashboards, and clear issue steps without handing raw XML around the company.