DMARC reports: how to read aggregate (rua) reports and what to act on

A DMARC report is a daily summary, sent as a zipped XML file, from each mail provider that received mail using your domain. It lists every sending IP address, how many messages it sent, and whether they passed SPF and DKIM for your domain. You ask for these aggregate reports with the rua tag in your DMARC record, and reading them is how you find every service that sends as you before you move your policy to reject.

This guide is for whoever owns the domain's DMARC record and now has a mailbox full of attachments. You will know what each part of the report means, how to sort the rows, and what to do about each kind. If you have no DMARC record yet, start with the guide to what DMARC is and your first record; the SPF, DKIM and DMARC setup guide shows where reports fit in the rollout.

Quick answer

• Ask for reports with rua=mailto:[email protected] in the record at _dmarc.example.com.
• Each receiver sends one report per day, usually covering 24 hours, as a .zip or .xml.gz attachment.
• Each <record> is one sending IP address with a message count, the DMARC verdict for DKIM and SPF (policy_evaluated) and the raw checks behind it (auth_results).
• Sort the rows into three groups: your services passing, your services failing, and senders you do not recognise.
• Fix your failing services, usually by turning on DKIM for your domain in them, and only then tighten the policy.
• Use a report reader for anything beyond a handful of reports; the XML is not written for people.

rua and ruf: the two kinds of DMARC report

DMARC defines two kinds of report, each requested with its own tag:

This guide is about aggregate reports, the ones you will actually receive. They contain no message bodies, subjects or recipient addresses: only IP addresses, domains, counts and results. That also makes them safe to hand to a report service.

How to start receiving DMARC reports

Add a rua tag to your DMARC record:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Three things to get right:

• Use a dedicated mailbox. A busy domain receives dozens of reports a day. A shared inbox fills up; a mailbox or alias only for reports, or a report service's address, is easier.
• Several addresses are separated by commas: rua=mailto:[email protected],mailto:[email protected].
• An address on another domain needs permission. If rua points outside your domain, the receiving domain must publish a TXT record v=DMARC1 at example.com._report._dmarc.otherdomain.example, or receivers will not send. Report services set this up for you.

Reports start arriving within one or two days. A domain that sends very little mail may receive only a few, since receivers only report on days when they saw your domain.

The email and DNS health check shows whether your record asks for reports and where they go. It reads your DNS only; it does not collect or read the reports themselves.

What a DMARC aggregate report looks like

Unzip an attachment and you get one XML file. Shortened, a report from one receiver looks like this:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>1234567890123456789</report_id>
    <date_range>
      <begin>1758844800</begin>
      <end>1758931199</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.23</source_ip>
      <count>112</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>bounces.mailer.example.net</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

The parts, from top to bottom:

• report_metadata says who sent the report and which period it covers. The dates are Unix timestamps in seconds; the example covers one day in September 2026.
• policy_published is your DMARC record as the receiver read it. If it does not match what you think you published, the receiver saw an older or a different record.
• record appears once per sending IP address and result. A report can hold hundreds.

How to read DMARC reports, row by row

Each <record> answers four questions:

1. Who sent it? source_ip is the sending server. count is how many messages it sent with your domain in the From line (header_from) during the period.
2. Did DMARC pass? Look at policy_evaluated. dkim and spf there are the aligned results: pass means that check passed for your domain. DMARC passes when either one says pass.
3. What happened to the mail? disposition is what the receiver did: none (delivered normally), quarantine (spam folder) or reject. Under p=none it is always none.
4. Why? auth_results shows the raw SPF and DKIM checks with the domain each one used, and the DKIM selector.

The difference between the two blocks is the key to reading reports. In the example, auth_results shows SPF passing, but for bounces.mailer.example.net, so the aligned SPF result in policy_evaluated is fail. DKIM passed for example.com with selector s1, so DMARC passed. This is normal for a newsletter tool that uses its own bounce domain and signs with yours.

What to act on: the four patterns

Sort the rows into groups by what they show:

A few more patterns worth knowing:

• DKIM passes for the service's domain, not yours (auth_results shows sendgrid.net or onmicrosoft.com). The service signs, but not as you. Finish its custom-domain DKIM setup.
• Small counts that fail from IPs belonging to Google, Microsoft or other mailbox providers. Usually forwarding: someone forwarded your mail on, SPF broke, and DKIM survived or did not. You cannot fix other people's forwarders; DKIM on every message is the protection.
• Thousands of failing messages from IPs in unrelated networks. Someone is sending as your domain. That is what p=reject is for.

How to identify an unknown sending IP

Before calling an IP spoofing, find out who owns it:

1. Reverse DNS. dig +short -x 198.51.100.23 often returns a host name that names the service, such as mail-sor-f41.google.com or o1.email.example-mailer.net.
2. The network owner. An IP WHOIS or RDAP lookup names the organisation that holds the address block.
3. Ask around. Marketing, sales, finance and support often sign up for tools that send mail as the company without telling IT.

Report readers do the first two for you and group IPs by organisation, which turns hundreds of rows into a list of a dozen senders.

Using a report reader

Reading XML by hand works for your first few reports. After that, a report reader, also called a DMARC analyser, collects reports at its own address, unzips them, groups them by sender and shows trends. Many offer a free plan for low volumes, and there are open-source parsers you can run yourself.

Two things to consider before you choose one. The service sees your sending data: IP addresses and volumes, not message content. And your rua then points to its domain, so if you stop using it, change the record, or reports go on flowing to a service you no longer read.

What changed with RFC 9990

In May 2026 the IETF replaced RFC 7489 with three documents, and RFC 9990 now defines aggregate reports. Existing parsers keep working, but the format was tightened:

• The XML has a formal namespace and schema, and each report covers one DMARC policy domain.
• When DKIM results are reported, the selector is required, which makes key rotation easier to follow.
• New optional fields reflect the other changes in RFC 9989, such as the np policy for subdomains that do not exist and the t=y testing flag, plus how the receiver discovered your policy.
• The ri tag, which asked for a report interval, was removed. Receivers send daily reports.

When the reports say you are ready

Your domain is ready for the next policy step when, over two to four weeks of reports:

• every service you recognise shows DKIM pass in policy_evaluated, or at least aligned SPF;
• the only failing rows are forwarding and senders you have confirmed are not yours.

Then move from p=none to p=quarantine, and later to p=reject, as the DMARC policy guide describes. Keep rua in the record at every step: the reports are how you notice the next tool someone signs up for.

Questions people ask

How do I read DMARC reports?

Open the XML and look at each <record>: the sending IP, the message count, and whether DKIM and SPF passed in policy_evaluated. Group the rows into your services passing, your services failing and unknown senders. Fix the failing services, usually by turning on DKIM for your domain, and only then tighten the policy. A report reader turns the XML into a table.

What is a DMARC rua address?

It is the address in the rua tag of your DMARC record where receivers send aggregate reports, for example rua=mailto:[email protected]. Use a mailbox dedicated to reports or a report service's address. If the address is on a different domain from yours, that domain must publish a record allowing it, or receivers will not send reports there.

Why am I not receiving DMARC reports?

Usually because the rua tag is missing or mistyped, it points to another domain that has not authorised it, or the record itself is broken and receivers ignore it. Reports also only come from receivers that saw your mail that day, so a quiet domain gets few. Check the record with an email DNS checker and wait two days.

Do mailbox providers still send DMARC failure (ruf) reports?

Rarely. Failure reports can contain parts of individual messages, so most large receivers do not send them for privacy reasons. You can still add a ruf address; some smaller receivers use it. For almost every domain, the daily aggregate reports from the rua tag are all you need to find failing senders.

What does disposition none mean in a DMARC report?

It means the receiver delivered the messages normally and applied no DMARC action. Under p=none every row shows none, even the failing ones, because the policy only asks for monitoring. Under quarantine or reject, none means those messages passed, or a local rule such as a forwarding exception overrode your policy.

How often are DMARC aggregate reports sent?

Once a day from each receiver that saw mail from your domain, usually covering a 24-hour period in UTC. RFC 9989 removed the old ri tag that asked for a different interval, so there is nothing to set. Expect the first reports a day or two after publishing the record, from Google, Microsoft, Yahoo and others.