How to read DMARC RUA reports Find the cause behind a failed result

RUA reports describe what receiving servers observed

rua is the DMARC record tag that specifies where aggregate reports should be sent. In everyday use, people call the DMARC aggregate reports delivered there “RUA reports.”

Gaon sends from example.com and publishes rua=mailto:dmarc-reports@example.com in its DMARC record. Receiving services that provide reports collect the authentication results they observe and send a summary to that address. Even if Gaon uses Google Workspace for employee mail, the reports come from the services receiving its messages. The DMARC rua tag ↗

Reports commonly arrive as compressed XML attachments. XML is a structured format that labels each value with a field name. Analysis services turn those files into readable tables and charts. If you receive the files directly, a dedicated reporting mailbox is easier to manage than an employee's personal inbox. Google on receiving and analyzing reports ↗

First identify the reporter and the reporting period

You do not need to memorize every XML tag. Start with the organization and dates in report_metadata, then read the policy in policy_published. Here is a shortened, fictional opening to Gaon's report; it is not a complete XML document.

<report_metadata>
  <org_name>Receiver Example</org_name>
  <email>reports@receiver.example.org</email>
  <report_id>20260918-example.com-01</report_id>
  <date_range>
    <begin>1789689600</begin>
    <end>1789776000</end>
  </date_range>
</report_metadata>
<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <adkim>r</adkim>
  <aspf>r</aspf>
</policy_published>

org_name identifies the organization that produced the report, not Gaon's newsletter provider. Keep report_id with the file; it helps you recognize a duplicate later.

The large begin and end numbers count seconds since January 1, 1970, at 00:00 UTC. This example runs from September 18, 2026, at 00:00 UTC to September 19 at 00:00 UTC. In Korea, that is 9 a.m. on the 18th to 9 a.m. on the 19th. If the attachment arrives on the morning of the 20th, it still does not describe mail sent on the 20th.

policy_published records the policy the receiver observed. Here it shows monitoring with p=none and relaxed alignment, r. If DNS has since changed, compare the reporting period with your change time before treating the old value as an error. A receiver may split reports when policy changes during a period or report the last policy it observed. Policy changes within a reporting period ↗

Next, read each record as a group of messages

One record may represent many messages sharing a source IP and authentication results. The same IP can appear in several records when the From domain or results differ. Add the count values; counting XML rows will not give you the message total.

source_ip identifies the system that connected to the reporting receiver. For forwarded mail, it may differ from the original sending server. Identifying the IP's infrastructure provider is a useful clue, but it does not finish the investigation. Source IP and message counts ↗

Why 150 newsletters pass SPF and DKIM but fail DMARC

Gaon compares the reported sources with its sender inventory. It recognizes 800 employee messages and 150 newsletters from Marketing. The remaining 50 messages are still unclassified.

Focus on the 150 failed newsletters. This fictional XML record belongs to the reporting period above and includes the fields needed for diagnosis.

<record>
  <row>
    <source_ip>198.51.100.20</source_ip>
    <count>150</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
    <envelope_from>mailer.example.net</envelope_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example.net</domain>
      <selector>news1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>mailer.example.net</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Pass and fail in the same record may seem contradictory. They answer different questions. auth_results describes the underlying SPF and DKIM checks. policy_evaluated includes whether those authenticated domains align with From for DMARC. Microsoft on reading aggregate reports ↗

envelope_from is the domain in the MAIL FROM address used between servers. Here it differs from the visible From address. Readers see news@example.com, while all authentication belongs to mailer.example.net. These are separate organizational domains, so even relaxed alignment does not connect them. DMARC needs at least one method that both passes and aligns with the company From domain.

Correct the signing domain before adding an IP address

Adding the newsletter IP to the company's SPF record would not solve this example. The receiver checks SPF for the service's domain, not example.com. First confirm authorization against Marketing's campaign logs, then configure the provider's company-domain authentication or custom DKIM feature.

Suppose Gaon publishes the TXT or CNAME records issued by its provider, completes verification, and enables signing. The intended result is a valid DKIM signature with d=example.com. Use the provider's issued values, not the sample selector or another customer's DNS records. If the provider cannot sign for your domain, check whether it supports an aligned MAIL FROM or requires a different sending From domain.

A completed setup screen is only part of the evidence. Send a fresh newsletter through the real campaign route to an external test mailbox and inspect the Authentication-Results recorded by its receiving service. The expected result looks like this:

Authentication-Results: receiver.example.org;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

SPF still uses the service domain, but the company DKIM signature now makes DMARC pass. In the next reporting period, look for policy_evaluated/dkim becoming pass for that newsletter route. If the same IP appears in both old failures and new passes, compare the change time: a report arriving tomorrow may include messages sent before today's fix.

The next campaign does not need to contain exactly 150 messages. Compare the authentication domains and results for the same route. Also check a real campaign, so one successful test does not stand in for all production sending.

Investigate the 50 unknown messages without guessing

An unfamiliar IP resolves to a well-known cloud provider. That does not establish it as a legitimate company sender. Shared infrastructure can put mail from unrelated customers under the same provider name.

Ask the departments and agencies that use the From domain. A support tool, website notification, or occasional invoice service may be missing from the inventory. Compare service logs, test-message originals from the same period, and actual account or contract records. That distinguishes “an IP owned by a familiar provider” from “mail sent by our account.”

The unknown messages could have been forwarded. Automatic forwarding changes the connecting IP and can affect SPF; changes to the content can also break DKIM. Read any reported override reasons and obtain original headers where possible. RUA contains no message body, so it cannot reconstruct what these messages said or establish an attacker's intent.

Disposition does not identify the mailbox folder

The newsletter record shows disposition=none despite failing DMARC. In this example, the published policy was p=none, so no DMARC quarantine or rejection was applied. That does not mean authentication succeeded or that the messages reached the inbox. The receiver's other filtering still operates.

RFC 9990, published in 2026, defines a pass disposition for mail that passes DMARC under an applicable enforcement policy such as quarantine or reject. Older report formats may show none for passing messages as well. Calculate authentication outcomes from the SPF and DKIM results in policy_evaluated, rather than disposition alone. If handling differs from policy, look for an override explanation under reason. Disposition values in the current report format ↗

Gaon's immediate jobs are to fix the newsletter failures among its 950 recognized messages and finish classifying the remaining 50. Keeping those tasks separate prevents a failure of legitimate mail from being presented as successful attack blocking.

If reports are missing, check the route from sending to reporting

When no attachment arrives, repeatedly refreshing the reporting inbox will not reveal much. Establish which domain was used and where the messages went. Reporting depends on outbound traffic, public DNS, destination authorization, and a working reporting mailbox.

1. Confirm the actual From domain and external delivery

   Check that messages used the domain you intend to monitor and reached external receivers. Internal-only traffic or destinations that do not report may produce no aggregate reports.

2. Read rua in public DNS

   Compare the published record with the value in your DNS dashboard. Check for a missing mailto:, address typos, duplicate DMARC records, and a separate subdomain policy.

3. Check authorization for an external reporting service

   If the reporting destination has a different organizational domain, the receiving side needs DNS authorization. Check the service's domain registration and setup instructions.

4. Check the mailbox and attachment handling

   Confirm the address can receive mail. Review external-sender restrictions, storage limits, compressed-file filtering, and spam folders. Distinguish arrival at an analysis service from a delay in its dashboard.

5. Allow the reporting period and delivery to complete

   Reports commonly cover a day, but receivers do not all send at the same time. Record the first sending time and DNS change time, and account for aggregation and delivery delays.

You can inspect a published record with the command below, replacing the domain. The response is an example of an initial monitoring setup. If you already use p=reject, adding reporting does not require lowering it to none; inspect or add rua in the existing record.

dig +short TXT _dmarc.example.com

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

An external reporting destination must authorize receipt

If reports for example.com go to aggregate@reports.example.net, the authorization record below belongs in the reporting recipient's DNS. Publishing that name in the company's example.com zone is not the same thing.

Name: example.com._report._dmarc.reports.example.net
Type: TXT
Value: v=DMARC1;

This prevents someone from naming an unrelated address and flooding it with reports. A provider may already handle authorization or use an arrangement covering multiple customers. Follow its onboarding instructions instead of guessing the required record. Verifying external reporting destinations ↗

No reports does not prove that no spoofing is occurring, or that DMARC itself is broken. Check the authentication result of a new message separately from the report-delivery route.

Give each finding an owner and a record of what changed

Gaon's first review can end with three assignments: retain employee mail as a working baseline; have Marketing correct newsletter DKIM and verify it; have IT investigate unknown sources with the relevant departments and forwarding administrators. For each, retain the reporting period, From domain, service, issue, change time, and follow-up date. The next reviewer should not have to start the investigation again.

Before combining reports, check for duplicates. Do not assume report_id is globally unique across reporting organizations. Compare the reporter, policy domain, period, and original file. Receiving the same file twice should not double the count, and partially overlapping periods need care before addition. Handling duplicate reports ↗

During an initial rollout and after configuration changes, review new sources and legitimate authentication failures daily. Once stable, continue checking for changes on a regular schedule. Revisit infrequent processes after they run, such as month-end billing. A high pass rate on an ordinary day can hide an important sender that has not sent anything yet.

Raw reports reveal company domains and sending infrastructure. Limit access to the people who need them, decide how long to retain both raw and analyzed data, and understand what an external analysis service processes. The absence of message bodies does not make the files suitable for unrestricted sharing. Information in aggregate reports ↗

A useful RUA review turns a vague authentication concern into an assigned change to a specific sending service. When legitimate sources are accounted for and corrections are verified, you have evidence for a stronger DMARC policy. Repeat the review whenever a new service begins sending with your domain.