DMARC aggregate reports, and how to actually read one

The rua= tag tells receivers where to send DMARC aggregate reports: daily XML summaries of every message they saw claiming to be from your domain, grouped by source IP, with SPF and DKIM pass/fail and — the important part — whether each aligned with the visible From domain. They are the only practical way to inventory who sends as you before you turn on enforcement.

Updated July 14, 2026 · DMARC

What a report actually contains

One XML document per receiver per day. Stripped of ceremony, each record says: we saw N messages from this IP claiming to be from your domain; SPF said X; DKIM said Y; here is whether they aligned; here is what we did about it.

<record>
  <row>
    <source_ip>203.0.113.7</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>      <!-- ← alignment result, not signature validity -->
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
</record>
The trap in that XML. The <dkim> and <spf> elements inside <policy_evaluated> are alignment results, not raw authentication results. A message can have a perfectly valid DKIM signature and still show dkim: fail here because the signing domain was the ESP's, not yours. There is a separate <auth_results> block with the raw outcome. Reading the wrong one sends people on long hunts for a broken signature that is not broken.

The three things to look for

  1. Sources you do not recognise. Either a forgotten internal system or someone spoofing you. Resolve every one before you enforce.
  2. Sources that pass but do not align. Overwhelmingly this is an ESP signing with its own domain. The fix is to configure DKIM signing on your domain in their dashboard — nearly every ESP supports it and it is usually one CNAME.
  3. Forwarding. Mailing lists and .edu forwarders will break SPF by design; the message arrives from a relay that your record does not authorise. Aligned DKIM survives this. It is the reason DKIM matters more than SPF for DMARC.

On ruf

Forensic reports sound more useful than they are. They can contain message content, so on privacy grounds most large receivers — Gmail included — simply do not send them. If you configure ruf and receive almost nothing, that is the system working as intended, not a misconfiguration. Do not build a detection process that assumes they will arrive.

Confirm your reporting address is actually published

We report the rua/ruf addresses currently published, if any.

Frequently asked

What is the difference between rua and ruf in DMARC?

rua receives aggregate reports: daily XML summaries with no message content, sent by essentially every major receiver. ruf receives forensic reports: per-message failure samples that can contain message content, which is why most large receivers — including Gmail — do not send them at all, on privacy grounds. Build your process on rua. Treat any ruf you receive as a bonus.

Why does my DMARC report show SPF passing but DMARC failing?

Alignment. SPF is evaluated against the envelope-from (Return-Path) domain, which for most ESPs is the ESP's own bounce domain, not yours. SPF passes — for them. But it does not align with the visible From: domain, so it contributes nothing to DMARC. This is the single most common confusion in DMARC deployment, and the fix is usually to get the ESP to sign with aligned DKIM.

Do I need a DMARC report analyzer?

Not to start. The XML is verbose but readable, and for a small domain you can scan it directly. Once you have more than a handful of senders, or reports arriving from dozens of receivers daily, the aggregation is genuinely worth automating — that is what commercial DMARC platforms sell, and for a large estate it is a fair trade.

Related

Automate this → — free tier, public pricing, API key emailed in about thirty seconds. No call with anyone.