What a DMARC report actually contains

Publish a DMARC record with a reporting address and, within a day or two, XML files start arriving. They come from the receivers of your mail — Google, Microsoft, Seznam, corporate gateways — and each one is that receiver's sworn statement about every message it saw claiming your name. Nobody is expected to read them by hand; but knowing what they contain is what turns DMARC from a record you published into an instrument you can fly by.

Who sends them, and how often

Aggregate reports (the `rua` address in your record) arrive roughly daily per reporting receiver, each covering a 24-hour window. There is a second kind — forensic reports, `ruf`, meant to carry individual failed messages — but most large receivers stopped sending them years ago for privacy reasons; a DMARC setup that waits for forensic reports is waiting for mail that will not come. Everything that follows is about aggregates.

What a row says

Inside the XML, each row groups messages by sending IP address and outcome. For every source the receiver tells you: how many messages it saw, what its SPF and DKIM evaluations concluded, whether either of them aligned with your From domain, and what the receiver actually did — delivered, quarantined, or rejected — under your published policy. Read enough rows and a picture assembles: these are the systems sending as this domain, this is how much of it authenticates, and this is what receivers are doing with the rest.

Two subtleties trip up first-time readers. A row passing "SPF" in the raw sense can still fail DMARC — alignment is what counts, and the report records both. And an unfamiliar IP with passing DKIM is usually not an attacker but a forwarder: your own message, relayed onward with your signature intact. The one genuinely alarming shape is volume from a source that never aligns on either check — that is mail using your name that none of your systems produced.

Why the reporting address is the consequential part

The reports are the only feedback loop DMARC has. Every decision that matters — which senders still need DKIM, whether tightening the policy would hit something real, whether a spoofing run is underway — is answered by reading them. A record whose rua points at a mailbox nobody reads has the loop cut: the domain collects evidence daily and nobody sees it. If you take one thing from this page: the rua address should feed something that reads the XML and tells a human only when a decision is needed.

That is Sojka's core loop — reports arrive at an address it monitors, get decoded into per-sender verdicts in plain language, and a push reaches your phone when something changes. If you just want to see what one report says, paste it into the free report reader; it never stores the content.

Check your domain free — it reads your public DNS and grades what is there.