DMARC monitoring: turning zipped XML chaos into something useful

So, you added rua=mailto:[email protected] to your DNS record. You expected clear reports on who is sending email as you.

Instead, your inbox is now being flooded with attachments named google.com!yourdomain.com!1712345600.zip containing unreadable XML files.

This is the “XML firehose.” And without a plan, it is useless.

1. What you actually receive (the RUA report)

DMARC aggregate reports (RUA) are not real-time alerts. They are daily summaries sent by receivers (like Google, Yahoo, Microsoft) telling you:

• “Yesterday, we saw 5,000 emails claiming to be from you.”
• “4,950 came from your SendGrid IP (SPF pass, DKIM pass).”
• “50 came from a suspicious IP in Middle East (SPF fail, DKIM fail).”

The problem? It’s all wrapped in XML tags that are impossible for humans to parse quickly.

2. Triage: what to ignore vs. what to panic about

When you use a tool (like DMARCTrust or open-source parsers) to visualize this data, you need a triage workflow.

Don’t panic

Forwarding artifacts are common. If you see weird failures from university domains or ISPs, it’s likely the forwarding issue we discussed previously.

SPF failures with DKIM passes are also normal for services like Gmail or Office 365. As long as DKIM aligns, DMARC passes. You are safe.

Do panic (investigate)

A new high-volume sender deserves immediate attention. If 10,000 emails suddenly appear from an IP identifying as “Mailgun” when you don’t use Mailgun, you’re looking at either spoofing or (most likely) Shadow IT.

SPF PermError means your DNS record might be broken. If you see “PermError” or “TempError”, check for too many lookups in your SPF record using our SPF generator.

DKIM pass with alignment fail is the “Shadow IT” killer. Someone is sending validly signed email, but using their domain (d=mailchimp.com), not yours.

3. The “external report” gotcha

A common mistake: You own mybrand.com, but you want reports sent to [email protected].

You set rua=mailto:[email protected].

Result: No reports arrive.

Why? To prevent spam, myholdingco.com must explicitly say “Yes, I agree to receive reports for mybrand.com.” You need to publish a special DNS record at the destination domain:

mybrand.com._report._dmarc.myholdingco.com TXT "v=DMARC1"

Without this “external domain verification,” major receivers will silently drop the reports.

4. RUF (forensic reports): the ghost feature

You might have seen the ruf= tag. This requests “forensic” (or failure) reports, which are actual copies of the failed emails.

Reality check: Don’t hold your breath. Due to privacy concerns (PII in email bodies), most major providers (Google, Yahoo, Microsoft) simply do not send RUF reports anymore.

Focus 99% of your energy on RUA (aggregate) reports.

5. DIY vs. SaaS

Can you do this yourself? Absolutely. Tools like parsedmarc (Python) are excellent. They can read from an IMAP inbox, parse the XML, and dump it into Elasticsearch or Grafana. You can even use our DMARC report decoder to manually inspect individual reports.

But be warned: the maintenance burden is real. Handling gzipped attachments, zips, corrupted XML, and non-standard reports from small ISPs is a constant battle. That’s why services like ours exist: to abstract away the parsing pain so you can focus on the security decisions. You might want to use us for a few months and see if it’s worth enduring the pain of doing all the IT admin stuff yourself.

FAQ: quick answers

What is an RUA report?

RUA (Reporting URI for Aggregate data) is a (almost) daily XML summary sent by email providers detailing all traffic claiming to be from your domain.

Why are some receivers missing?

Not everyone sends DMARC reports. Google, Yahoo, Microsoft, and Comcast do. Many smaller ISPs do not.

Why is SPF failing only in reports?

This often happens with forwarding. The IP address reported is the forwarder’s IP, which isn’t in your SPF record. If DKIM passes, DMARC still passes.