Why I stopped trying to read my DMARC reports manually

Raw DMARC reports are not designed to be read by humans. They are gzipped XML files, one per reporting organization per domain per day, and the only reasonable response to 900 of them sitting unread in a Gmail folder is to stop pretending you will ever open them. What you actually need is something that reads them for you and only interrupts you when alignment drops or an unknown sender appears. Everything else is noise.

I have a Gmail filter. Any email matching subject:(Report Domain:) skips the inbox, gets labeled "DMARC," and stays there, unread. Last week I checked: 900 messages. The oldest is from eighteen months ago.

How it starts

When you first set up DMARC, you feel responsible. You add a rua= address and make a mental note to "monitor it properly." You open the first report. It's a .xml.gz attachment. You download it, gunzip it, and stare at XML for several hundred lines.

If you're motivated, you paste it into a formatter. You squint at blocks labeled policy_evaluated and try to remember what alignment_mode: relaxed means. The document is technically readable, but not quickly. Not at scale.

Then two more reports arrive the next day. Then ten more. Google, Yahoo, Microsoft, Comcast, Apple, mail.ru: they all send reports. Separately. For each domain. Your side projects have side DMARC reports.

The folder fills up. You tell yourself you'll process it next week.

You don't.

The problem was worse than I thought

I managed to avoid consequences for about six months. In that time, two things happened that I only discovered weeks later.

The first: One of my domains started showing up in phishing emails. I never would have noticed, except a real user emailed me asking, "Did you send this?" I got curious. I dug into those 900 unread emails and found six weeks of reports showing the same pattern: hundreds of messages from IPs I didn't recognize, zero alignment, consistently dispositioned none because I'd never tightened my policy. Someone had been spoofing my domain the entire time. My customers saw the spoofed emails. I saw nothing.

The second: I was migrating a domain and misconfigured a DNS record, breaking DKIM for six weeks. During that time, my transactional emails (password resets, order confirmations) silently degraded in deliverability. Gmail put them in spam. My users missed them. I had no idea until a customer asked why they never got their password reset link. The evidence was sitting in the reports: alignment had dropped to 0% for that particular domain. But I wasn't reading reports. So I didn't know.

Both problems were detectable within 24 hours of happening. I didn't detect them for weeks because reading 900 XML files is not a reasonable use of time.

The aha moment

What bothered me most wasn't the spoofing or the broken DKIM; those are fixable. What bothered me was that I'd had the signal all along. DMARC reports were arriving, containing the evidence, but in a format that guaranteed I wouldn't see them.

The problem wasn't my discipline. The problem was that the interface was wrong.

Raw DMARC reports are optimized for mail system operators running a small number of high-volume domains, who have infrastructure to process them automatically. They're not optimized for a developer with eight side projects, none of which send more than a few hundred emails a month, none of which I check in on frequently.

For my use case, the signal-to-noise ratio was approximately zero. 90% of the reports were "everything is fine, Google sent you XML twice this week." The 10% that mattered (alignment dropped, unknown sender appeared, something broke) was buried in the same format.

What I realized I actually needed

I don't need a Grafana dashboard. I don't need 365 days of raw report data. I don't need to become an email authentication expert. What I need is:

• Tell me when my alignment rate drops. Not every fluctuation; when it drops materially. Below 95%, below 90%, below some threshold I set.
• Tell me when an unknown sender appears. Someone sends meaningful volume from my domain, and I don't recognize them.
• Otherwise, silence. Assume things are fine. A weekly summary is nice. An alert for real problems is essential.

That's the entire product I was missing. Not more visibility: less, but smarter.

The 900 unread emails weren't a personal failure. They were a tool design problem. The right interface for this information is not "one gzipped XML file per reporting organization per domain per day." It's a digest that says "everything is fine" when it is, and "something changed, look here" when it isn't.

Because by the time a customer tells you their password reset went to spam, you've already lost emails. DMARC reports could have warned you days earlier. But only if someone reads them. And nobody reads 900 XML files.