How to read a DMARC report

A DMARC aggregate report is a map of every system that sent mail using your domain during a reporting window. The XML looks hostile, but the question behind it is simple: who sent, how much, and did the visible From domain align with SPF or DKIM?

This guide assumes you already published SPF, DKIM, and DMARC and added an aggregate-report address with rua=. If those pieces are new, start with SPF, DKIM, and DMARC explained. Here, we will read the report instead of rebuilding the records.

Start with one aggregate record

A report contains metadata about the receiver and your published policy, followed by one or more records. A simplified record may look like this:

<record>
  <row>
    <source_ip>192.0.2.24</source_ip>
    <count>842</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</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>bounce.vendor.test</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

In plain English: one source IP sent 842 messages with example.com in the visible From header. DKIM passed and aligned with that domain. SPF passed for the vendor's bounce domain, but that domain did not align with the visible From domain, so DMARC reports SPF as a fail. The messages still passed DMARC through DKIM.

Read the report in this order

1. Reporting organization and date range

In report_metadata, find the organization that produced the report, its report ID, and the start and end timestamps. Reports from Google, Yahoo, Microsoft, and other receivers cover only the mail they observed. They are samples from different parts of your traffic, not one universal delivery log.

Check the date range before comparing volumes. One file may cover a full day while another covers a shorter period.

2. Your published policy

The policy_published section shows the DMARC record the receiver found: the domain, policy, subdomain policy, percentage, and alignment modes. If this does not match what you think is live, check DNS before investigating individual senders.

A report generated while you use p=none is still useful. It shows what would pass or fail before you ask receivers to quarantine or reject failures.

3. Source IP and volume

source_ip is the server that connected to the receiver. count is how many messages in that report shared the same result. Read them together.

• One failure from an unfamiliar IP may be spoofing or background noise.
• Thousands of failures from a vendor you recognize are probably a configuration problem.
• A sudden new source with meaningful volume deserves investigation, even if it passes.

Do not spend the morning reverse-looking-up every single IP. Start with the largest counts and the systems you expect to send: product email, billing, support, CRM, marketing, and employee mail.

4. The visible From domain

header_from is the domain people see in the From address. DMARC protects this domain. It is the reference point for alignment.

If a message says From: [email protected], SPF or DKIM must authenticate with a domain aligned to example.com. A technical pass for an unrelated provider domain is not enough.

5. Policy-evaluated results

The dkim and spf values inside policy_evaluated tell you whether those mechanisms passed the DMARC test, including alignment. DMARC passes when at least one aligned mechanism passes.

• dkim=pass, spf=fail: usually fine. Aligned DKIM carried the message.
• dkim=fail, spf=pass: also a DMARC pass, but DKIM still deserves attention.
• Both pass: healthy, although one mechanism may break during forwarding.
• Both fail: the message did not pass DMARC.

disposition reports the DMARC handling recorded for the row: none, quarantine, or reject. It is not a delivery receipt. A receiver can apply local policy, and a message can still be filtered for reasons unrelated to DMARC.

6. Raw authentication results

The entries under auth_results show the domains and selectors that actually passed or failed SPF and DKIM. This is where you diagnose alignment.

The most common confusing row is raw SPF pass but policy-evaluated SPF fail. That means the sending IP was authorized for the envelope domain, but the envelope domain did not align with header_from. Configure the provider to use a custom return-path domain under your domain, or rely on aligned DKIM.

For DKIM, compare the signing domain with header_from and note the selector. A provider may sign correctly with its own domain while still failing DMARC alignment. Enable custom-domain DKIM for that sender.

Forwarders and mailing lists are different

Forwarding commonly breaks SPF because the forwarding server is not listed in the original sender's SPF record. DKIM often survives because the signature travels with the message. If aligned DKIM passes, the forwarded message still passes DMARC. That is normal; do not try to add every forwarding IP to SPF.

Mailing lists are harder. A list may change the subject, footer, or body, breaking DKIM, while also forwarding from its own infrastructure and breaking aligned SPF. Some receivers record an override reason in policy_evaluated. Treat that as context, not permission to ignore every failure.

A small, stable stream associated with a known forwarder or list can be monitored. A high-volume failing source that belongs to your CRM, billing system, or product should be fixed.

What to fix and what to monitor

Fix these first:

• A sender you recognize where both aligned SPF and DKIM fail.
• A provider that authenticates only with its own domain instead of yours.
• A large source IP you cannot account for.
• A selector that suddenly changes from pass to fail.
• Legitimate traffic affected by a quarantine or reject policy.

Monitor rather than panic when you see:

• Low-volume failures from unknown IPs that are probably spoofing attempts.
• SPF failure on forwarded mail where aligned DKIM passes.
• Known mailing-list traffic with a documented receiver override.
• Minor daily volume differences between reporting organizations.

A practical review routine

1. Confirm the report's date range and your published policy.
2. Sort records by message count.
3. Label every high-volume source as expected, unexpected, or unknown.
4. For expected senders, inspect auth_results and fix alignment.
5. For unknown senders, look for spoofing patterns before changing DNS.
6. Watch at least several reporting cycles after a change.
7. Tighten from p=none only when legitimate high-volume senders consistently pass.

RUA is the report you are reading

rua requests aggregate reports: summarized counts grouped by source and authentication result. ruf refers to failure or forensic reporting, which is different, may include message-level information, and is not sent by every receiver. For routine domain monitoring, aggregate rua data is the useful foundation.

Turn XML into an operating habit

A DMARC report is not a pass/fail certificate for your whole domain. It is an inventory that changes as teams add tools, vendors rotate infrastructure, and attackers try your From address. The useful outcome is not reading every XML file. It is noticing when a legitimate sender loses alignment or an unknown sender gains volume.

Use ArawaMail's free DMARC checker and generator to inspect the record before and after a change. Then create a free ArawaMail workspace to monitor the domain as an ongoing system instead of collecting unread XML attachments in a folder.