What is a DMARC aggregate report?

A daily XML file that a receiving mail provider sends to the address in your rua tag. It lists every source IP that sent mail as your domain and whether SPF, DKIM and DMARC passed.

What is the difference between rua and ruf?

rua requests aggregate summaries. ruf requests failure (forensic) reports about individual failed messages. Most large providers send rua and few send ruf, partly for privacy.

Why am I not getting DMARC reports?

Check the record is at _dmarc.yourdomain with a valid rua=mailto: address, that you allowed a day or two, and that a report address on another domain has the external authorization record.

Do I need a tool to read the reports?

You can read one by hand, but real domains receive many files a day. A free or paid DMARC report processor turns them into tables by source and result.

How to Read a DMARC Report: Aggregate and Forensic

Check your DMARC record

See whether a domain publishes a DMARC policy and a reporting address:

Turn reports on

Add a rua tag with a mailbox that can receive attachments to the DMARC TXT record at _dmarc.yourdomain:

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

Reports start arriving within a day or two, one per sending provider per day. Use a dedicated mailbox, because they come in volume. The policy part (p=) is explained in what is DMARC.

If the report address is on a different domain from the one being reported, that other domain must publish a TXT record at example.com._report._dmarc.otherdomain.com with the value v=DMARC1. Without it, providers won't send you the reports.

Aggregate and forensic reports

	Aggregate (rua)	Forensic (ruf)
Contents	Daily counts per source IP and result	A copy or summary of individual failed messages
Who sends them	Nearly all large providers	Few, because of privacy concerns
Format	XML, usually zipped or gzipped	Email, usually in a standard failure format
Use	Find all senders and failures	Investigate a specific failure

Anatomy of an aggregate report

<feedback>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <date_range><begin>1730937600</begin><end>1731023999</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain><p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.25</source_ip>
      <count>412</count>
      <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
  </record>
</feedback>

report_metadata: who sent the report and the period, in Unix time.
policy_published: the policy the receiver found for your domain.
row: one source IP, how many messages (count), and what was done (disposition).
dkim and spf inside policy_evaluated: whether each passed and aligned with the From domain. DMARC passes if either does.
header_from: the visible From domain the mail used.

What to look for

Group by source IP. Identify each one: your own server, a mail service you use, or something unknown. The reverse DNS lookup and IP WHOIS name most of them.
Known senders that fail. A service you use that shows dkim and spf both failing needs to be set up to sign or send as your domain. Fix it before moving to quarantine or reject.
Unknown senders with high counts. Probably spoofing, or a forgotten service. Spoofing is what a stricter policy will block.
Passes by forwarding. Forwarded mail often breaks SPF but keeps DKIM, so a DKIM pass with an SPF fail is usually fine.

When one of your own services fails, why DKIM or DMARC fails lists the causes and fixes.

Handling the volume

A small domain gets a handful of files a day. A busy one can get hundreds, which is unreadable by hand. A DMARC report processor, free or paid, collects the files and shows them as tables by source and result. Pick one that stores nothing you don't want shared, since reports contain your senders' IP addresses.

More background in SPF, DKIM and DMARC explained.

How to read a DMARC report