Email DNS Check

DMARC Aggregate Reports Explained

DMARC aggregate reports (rua) are XML documents sent by receiving servers to the address you specify in your DMARC record. They summarise authentication results: how many messages passed or failed SPF, DKIM, and alignment. Understanding the report structure and fields helps you use the data to fix senders, tune policy, and roll out enforcement safely.

One-Minute Fix

Ensure your DMARC record has a valid rua=mailto: address. Reports arrive as compressed XML. Use a parser or dashboard to interpret them, and focus on failed results to identify misconfigured senders before tightening policy.

Report structure overview
Plain text
feedback
  report_metadata (reporter, date range)
  policy_published (domain, p=, sp=)
  record (source_ip, count, disposition, dkim/spf results)

Each record describes a source IP, how many messages, and whether they passed or failed SPF and DKIM. Use this to find senders that need alignment fixes.

Re-check

Wrong vs correct setup

Ignoring report data

Ignoring report data
Plain text
Moving to p=reject without reviewing rua reports

If you never review aggregate reports, you do not know which senders are failing. Tightening policy blindly can block legitimate traffic from undiscovered systems.

Using reports for rollout

Using reports for rollout
Plain text
1. Collect reports on p=none
  2. Identify failing sources
  3. Fix SPF/DKIM for those senders
  4. Move to pct=10, then 100

Reports tell you which IPs and domains fail. Fix them first, then increase enforcement. This reduces the risk of blocking real mail.

Why aggregate reports matter

Reports are the only way to see authentication results across receivers. Without them, you are guessing which senders pass or fail. They are essential for safe DMARC rollout and ongoing monitoring.

Why missing or unused reports cause problems

  • No rua means no visibility into authentication failures.
  • Ignoring reports leads to blind policy changes.
  • Invalid mailto address means reports never arrive.
  • Moving to reject without report data risks blocking legitimate mail.

How reports support deliverability

Reports help you fix alignment before enforcement bites. When you know which senders fail, you can correct SPF and DKIM, then tighten policy with confidence. That improves both security and deliverability.

Common report issues

  • rua was omitted from the DMARC record.
  • The mailto address was invalid or unreachable.
  • Reports were sent but filtered as spam.
  • No parser or process to review report data.

What we checked

We verify that the DMARC record includes a valid rua tag. We do not parse or store report content; we only confirm the reporting configuration.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

How often are aggregate reports sent?

Receivers decide. Most send daily. The report_metadata includes the date range. Reports may be batched or delayed.

What format are the reports?

XML, often gzip-compressed. Many tools parse them. Look for record elements with policy_evaluated (disposition, dkim, spf results).

Do all receivers send reports?

No. Only receivers that support DMARC reporting will send. Major providers like Gmail and Microsoft do; some smaller ones do not.

Next steps

  • Add rua=mailto: to your DMARC record.
  • Ensure the mailbox can receive compressed XML.
  • Use a parser or dashboard to interpret reports.
  • Identify failing sources and fix SPF/DKIM.
  • Use report data to guide policy rollout.
  • Review the full troubleshooting guidance in the DMARC Hub.
  • Explore sender authorization issues in the SPF Hub.
  • Check signing and selector issues in the DKIM Hub.

Related fixes

Explore more issues