How to read a DMARC report (no XML degree required)

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:

1. source_ip — the server that sent mail as your domain.
2. count — how many messages from that IP in the window.
3. SPF and DKIM results — pass or fail, with alignment: did the passing domain actually match your From domain?
4. 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.

A report, decoded line by line

Strip the XML down to its rows and a real (simplified) day looks something like this:

source_ip	count	spf	dkim	disposition
209.85.220.41	1,204	pass	pass	none
40.92.4.19	3	fail	pass	none
185.220.101.7	47	fail	fail	none

Row one is Google Workspace sending your real mail — high volume, both checks pass, nothing to do. Row two is small and mixed: SPF fails but DKIM passes, which is the signature of a message that got forwarded through a third party (the forwarder’s IP isn’t in your SPF record, but the DKIM signature travels with the message body and still validates). Also nothing to do — this is normal mail behaving normally on a path DMARC was designed to tolerate. Row three is the one that earns attention: an IP you’ve never associated with your domain, failing both checks, at real volume. At p=none that mail was still delivered to whoever it was addressed to, and this row is exactly the evidence you’d cite to justify moving your policy up a rung.

Notice what the count column is doing across all three rows: it’s not telling you anything is “bad” or “good” on its own — three failing messages from an unrecognized IP could be background noise, but 47 at once, in one day, from one source, is a pattern worth naming and watching over the next few reports before you conclude it’s a real spoofing attempt rather than a one-off scan.

Why alignment trips people up

The part that confuses most people reading their first report isn’t pass/fail — it’s that SPF and DKIM can each pass on their own domain while still failing DMARC, because DMARC additionally checks alignment: does the domain that passed actually match the domain in your visible From: address? A marketing platform can authenticate a message with its own valid SPF and DKIM, both technically “passing,” and still fail DMARC if it never bothered to align those checks to your sending domain instead of its own. That’s the single most common reason a report shows a tool you do recognize failing DMARC even though nothing about the message looked suspicious — it’s not spoofing, it’s a vendor that signed with the wrong domain. The fix is the same either way: get that tool sending through your domain’s own SPF include and a custom DKIM selector, not its shared default.

The 20-minute weekly routine

1. Open the week’s reports in the viewer.
2. New source IPs? Identify each one: yours, or noise, or threat.
3. Any legitimate source below ~98% pass? Fix its SPF include or DKIM.
4. 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.

Frequently asked questions

Why didn’t I get a report from a provider I expected mail to reach? Most likely, nothing claiming to be your domain hit that provider’s servers that day — no news is the normal outcome, not a broken pipe. It’s also worth double-checking your rua tag resolved correctly and that the mailbox receiving reports isn’t quietly bouncing or filtering them; a gzipped XML attachment from an unfamiliar sender is exactly the kind of thing an overzealous spam filter flags.

Can I get a report about one specific email instead of a daily aggregate? That’s what the ruf= (forensic) tag was built for, but most major receivers stopped sending per-message forensic reports years ago for privacy reasons — the sample would include real recipient addresses and message fragments. In practice, aggregate reports are what you actually get, and they’re enough: a single suspicious message rarely matters as much as the pattern it’s part of.

My domain doesn’t send any email at all — should I still set up rua? Yes, arguably more urgently. A domain that never sends mail is an attractive spoofing target precisely because nobody’s watching it, and the setup cost is one DNS record. The reports will simply confirm that any mail claiming to be you is illegitimate, which makes the case for moving straight to a strict policy an easy one.

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