Add one tag to your DMARC record — rua=mailto:dmarc@yourdomain.com — and something remarkable happens: Google, Microsoft, Yahoo and hundreds of other receivers start sending you a daily accounting of every email that claimed to be your domain. Who sent it, from which IP, and whether it passed authentication.

It’s the only free, global surveillance feed you’ll ever be offered about your own brand. Then you open one, and it’s a gzipped XML file named something like google.com!yourdomain.com!1717286400!1717372800.xml.gz, and most people close it forever.

Don’t. Here’s how to actually read the thing.

What arrives, and when

Each big receiver sends roughly one aggregate report per day covering the previous 24 hours. No report from a provider usually just means no mail claiming to be you hit their servers that day. The reports go to whatever address your rua tag names — if you haven’t set one, do that first with the DMARC Record Generator; reports are the entire value of the p=none phase.

(There’s a second tag, ruf=, for per-message forensic reports. Most receivers stopped sending those for privacy reasons. Don’t wait up.)

The four fields that matter

Strip away the XML ceremony and every report is a table. Each row says:

source_ip — the server that sent mail as your domain.
count — how many messages from that IP in the window.
SPF and DKIM results — pass or fail, with alignment: did the passing domain actually match your From domain?
disposition — what the receiver did about it (none, quarantine, reject).

That’s it. Every DMARC product you’ll ever see is a prettier rendering of those four columns. For one-off reading, drop the .xml or .gz file into our free DMARC Report Viewer — it runs in your browser, nothing gets uploaded, and you get the table instead of the angle brackets.

How to interpret what you see

Rows that pass both SPF and DKIM, high counts — your real infrastructure: Workspace, your campaign tool, your transactional sender. Boring is good.

Rows that pass one and fail the other — usually fine (DMARC needs one aligned pass), but worth understanding. SPF failing on otherwise legitimate mail is classically forwarding — the forwarder’s IP isn’t in your SPF, while DKIM survives the trip.

Rows from IPs you recognize that fail both — the expensive ones. This is your own tool sending unaligned mail: typically a provider signing with its own domain instead of yours. Fix is custom-domain DKIM (here’s how that works).

Rows from IPs you’ve never seen, failing everything — spoofers trying your domain on for size. At p=none they’re being delivered; this is the data that justifies climbing to quarantine and reject. To identify a mystery IP, check its reverse DNS and owner — our DNS Lookup does both.

A note on volume: a handful of failing messages from random IPs is background radiation — every domain on the internet gets impersonated a little. What you’re looking for is patterns: a consistent source, real volume, or your own providers failing.

The 20-minute weekly routine

Open the week’s reports in the viewer.
New source IPs? Identify each one: yours, or noise, or threat.
Any legitimate source below ~98% pass? Fix its SPF include or DKIM.
Note the spoof volume. When your real sources all pass and you’ve watched a full cycle of rare senders, tighten the policy a rung.

That routine is genuinely enough for a small domain. It also gets old around week six — parsing XML attachments is a job for software, which is exactly what Norbelys DMARC monitoring is: every report ingested automatically, sources named, failures flagged when they start, not when you remember to look.

Either way: turn the reports on today. The feed only tells you about the days after you ask.