Reading DMARC reports

Publish a DMARC record with a rua address and the world's mailbox providers start mailing you intelligence reports: daily summaries of every server that sent mail claiming to be your domain, with message counts and authentication results. This is the only instrument in deliverability that shows you traffic you did not send. Spoofers and forgotten tools alike appear in it, judged from the receiver's side. Professionals treat these reports as radar, and the radar is free.

What lands in the rua mailbox

The DMARC lesson covered the policy side; the reporting side is one tag. Add rua=mailto:dmarc@example.com to your DMARC record and participating receivers (Google and Microsoft among them) begin sending compressed XML files to that address, roughly one per receiver per day. Each file covers a reporting window, usually 24 hours, of that receiver's view of your domain: every source IP that sent mail with your domain in the From, how many messages, and how each batch fared.

The volume surprises people. A modest sending domain can collect a dozen reports a day from different receivers. Give the reports their own mailbox or alias; you do not want them in your inbox.

The anatomy of one record

Each file opens with two housekeeping sections. report_metadata names the reporting organization and the exact time window. policy_published shows your DMARC policy as the receiver saw it during that window, which is quietly useful: if you tightened your policy on Monday and Thursday's reports still show the old one, a receiver was working from a cached record, and that is your TTL at work rather than a mystery.

Then come the records, the actual radar returns. One looks like this (documentation domains, illustrative numbers):

<record>
  <row>
    <source_ip>192.0.2.55</source_ip>
    <count>1842</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>mail1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Read it from the top. source_ip and count: this IP sent 1,842 messages as example.com in the window. policy_evaluated holds the aligned verdicts, meaning the results DMARC actually used, plus disposition: what the receiver did with any failures under your policy (none, quarantine or reject). auth_results holds the raw outcomes, with the domains and selector involved.

Now the detail that teaches you to read these properly. auth_results says SPF passed, yet policy_evaluated says SPF failed. Both are true. SPF genuinely passed, for bounce.example.net, but that domain does not align with the From domain example.com, so for DMARC purposes the SPF result is a fail. DKIM passed with d=example.com, which does align, so DMARC passed overall. Raw pass, aligned fail: once you can spot that pattern, you can read any report.

Read one by hand, once

Do this exercise a single time. Take a report from Google, unzip it, open the XML in an editor, and walk each record: whose IP is this, what passed, what aligned. It takes twenty minutes and permanently demystifies the format. You will also discover why nobody does it twice.

The problem is scale, not difficulty. Dozens of files a day, each with many records, and the key field is an IP address, which means nothing to a human without a lookup. Nobody hand-reads their radar.

Why everyone uses a processor

A report processor is a service that receives your rua stream, resolves the IPs into named sending services, aggregates everything, and shows trends: these sources send as your domain, this share aligns, this source started failing on Tuesday. Free and paid ones exist in quantity; dmarc.org keeps a list of them. Setup is one DNS edit: the processor gives you an address for the rua tag (a record can list more than one address, so you can keep a copy yourself).

If you run mail for anyone, including just your own company, this is not optional tooling. It is the difference between owning radar and owning a mailbox full of gzip files.

One wrinkle worth knowing about, because it explains most "I set this up and nothing arrived" cases. When your rua address lives on a different domain than the one being reported on (which it does, the moment a processor hosts it), the standard requires the receiving domain to publish a small DNS record authorizing itself to accept your reports. Receivers check for it before sending. Processors publish that record on their side automatically, so you rarely see any of this, but if reports never show up after setup, this verification and a typo in the rua address are the two usual suspects. Give it a day or two as well; reporting runs on a daily rhythm, and the first files lag the DNS change.

The weekly workflow

Fifteen minutes a week covers it.

• Inventory the sources. Every source with meaningful volume should have a name you recognize: your ESP, your helpdesk, the billing system, Google Workspace. This list is your real sending footprint, which is often longer than the one in your head.
• Chase unknowns. An unrecognized source with real volume is either a tool someone connected without telling you or someone forging your domain. The response differs wildly, so identify first: the processor's IP attribution usually settles it in a minute.
• Watch alignment failures on known sources. Your own newsletter drifting toward unaligned is decay in progress: a signing domain changed, a record broke, a migration happened. This is exactly the failure that produces "we changed nothing and placement sank" weeks later.
• Tighten policy only when the picture is clean. Moving to p=quarantine or p=reject while a legitimate source still fails alignment means quarantining your own mail. The reports are how you know you are ready.

Forensic reports are mostly dead

DMARC defines a second report type: forensic (or failure) reports, requested with the ruf tag, which were meant to deliver per-message samples of failing mail, potentially including content. Privacy concerns killed them in practice. Redacting personal data from message samples is hard, privacy law made the risk concrete, and the biggest receivers simply do not send them. Set ruf if you like; expect near silence. Everything actionable lives in the aggregates.

Forwarders: the ghosts on your radar

Some failures in your reports are nobody's fault. When a recipient auto-forwards their mailbox, the forwarding server re-sends your message from its own IP. That IP is not in your SPF record, so SPF fails. DKIM usually survives forwarding intact, since the signature travels inside the message, but mailing lists that add subject tags or footers break it too. The result in your reports: small counts of failing mail from university servers, hosting companies and odd ISPs you have never heard of.

A pattern we see when people first collect reports is alarm over exactly this: a trickle of failures from some campus mail server, investigated as an attack, which turns out to be one subscriber forwarding their old address to a new one. It is normal background noise. Volume is the tell; a forwarder is a handful of messages, a spoofing campaign is not. ARC exists to help receivers see through forwarding, but your reports will still show the SPF breakage.

When the radar does show something wrong, you need a repair sequence, not a guess; deliverability triage, in the diagnosis part of the course, is that runbook. Next here: the second shelf of authentication standards, weighted honestly.

Terms from this lesson

• aggregate report (rua) - the daily XML summary a receiver sends to your rua address, listing every source IP that sent mail as your domain, with counts and authentication outcomes.
• forensic report (ruf) - a per-message failure report defined by DMARC but rarely sent today, for privacy reasons.
• disposition - the report field recording what the receiver actually did with failing mail under your policy: none, quarantine or reject.
• policy_evaluated - the report section holding the aligned verdicts DMARC used, as opposed to the raw results in auth_results.
• report processor - a service that ingests aggregate reports, resolves IPs into named sending services and shows trends over time.
• forwarder - a server that passes a received message on to another mailbox. Forwarding changes the sending IP, which breaks SPF, and shows up in reports as small unexplained failures.

Check yourself

1. A report shows auth_results spf=pass but policy_evaluated spf=fail. What happened?

The receiver made an error and the row should be ignoredSPF passed for a domain that does not align with the From domainThe message was sent twice with different results

2. Why does almost nobody read rua reports by hand?

The XML is encrypted by the receiversHand-reading is forbidden by the DMARC standardThe volume of files and IP-keyed records makes a processor the only practical way to see the picture

3. Your reports show a small, steady trickle of SPF failures from a university mail server. Most likely explanation?

A subscriber is auto-forwarding your mail, and the forwarding server is not in your SPF recordThe university is spoofing your domainYour SPF record has a syntax error

4. Why do forensic (ruf) reports barely exist in practice?

Privacy concerns: per-message samples risk exposing personal data, so major receivers do not send themThey were removed from the DMARC standardThey cost receivers money to generate