DMARC monitoring: “Zipped XML firehose” → actionable monitoring (without vendor fluff)
Monitoring pain is mostly workflow pain: DMARC aggregate reports are XML (often compressed), arrive on imperfect schedules, and are hard to triage. We explain how to turn the XML firehose into actionable security insights.
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: If you see weird failures from university domains or ISPs, it's likely the forwarding issue we discussed previously.
- SPF Fail, DKIM Pass: This is common for services like Gmail or Office 365. As long as DKIM aligns, DMARC passes. You are safe.
Do Panic (Investigate):
- New High-Volume Sender: Suddenly 10,000 emails from an IP identifying as "Mailgun" when you don't use Mailgun? Spoofing, or, most likely, Shadow IT!
- SPF PermError: If you see "PermError" or "TempError", your DNS record might be broken (often too many lookups).
- DKIM Pass, Alignment Fail: This 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—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 fantastic. They can read from an IMAP inbox, parse the XML, and dump it into Elasticsearch or Grafana.
But be warned: The maintenance burden is real. Handling gzipped attachments, zips, corrupted XML, and "weird" 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 worthy to endure 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.
