DEV Community

Cover image for How to Read a DMARC Report (RUA) — A Practical Walkthrough
Denys Button
Denys Button

Posted on

How to Read a DMARC Report (RUA) — A Practical Walkthrough

#dns #email #security #tutorial

What a DMARC aggregate report actually shows, how to start collecting one, and why you should not jump straight to p=reject. Step by step.

How to Read a DMARC Report Without Guessing

You set up a DMARC record, added a rua= tag, and now you're staring at either nothing (no reports arriving yet) or an inbox full of XML attachments that look like a server log dumped from orbit. Neither state tells you what to do next. Here's how to actually get useful data out of DMARC and read it correctly.

What a DMARC aggregate (RUA) report actually is

DMARC has two report types: aggregate (RUA) and forensic (RUF). RUA is what you want first — it's a daily XML digest, sent by every major receiving mailbox provider that supports DMARC (Google, Microsoft, Yahoo, etc.), summarizing every message they saw claiming to be from your domain: how many, from which sending IPs, and whether SPF and DKIM passed and aligned for each one.

It is not a list of individual emails or recipient addresses — it's aggregated by source IP and result, once a day per reporting provider. RUF (forensic) reports individual failing messages but almost no major provider sends them anymore due to privacy constraints, so don't build a workflow around expecting RUF data.

Step 1: Start collecting reports

Your _dmarc TXT record needs a rua= tag pointing to an address that can receive the reports:

_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1"
Enter fullscreen mode Exit fullscreen mode

Two things matter here before you go further:

  • Start at p=none. This tells receivers "report to me, but don't do anything differently with delivery." It's monitor-only mode. You need data before you can safely change enforcement — more on this below.
  • Don't point rua= at a personal inbox. Raw XML is unreadable at any real volume. Use a free parser like dmarcian's DMARC XML parser (they offer a free tier for basic aggregate report parsing) or a similar tool that ingests the raw reports and renders them as a dashboard.

If you're new to this, sign up for a free DMARC report parsing tool, get their provided rua= address (many act as an intermediary and forward/parse automatically), and use that in your record instead of a raw mailbox.

Step 2: Give it time

Reports arrive roughly once every 24 hours per reporting provider, and you need enough volume and enough days to see a real pattern — a few days at minimum, ideally 1–2 weeks before drawing conclusions. A single day's report from a low-volume domain can be misleading.

Step 3: Read alignment, not just pass/fail

This is where most people misread the report. DMARC doesn't just ask "did SPF pass" and "did DKIM pass" — it asks whether the domain that passed matches the visible From domain, a concept called alignment.

  • SPF alignment (aspf) — does the domain in the Return-Path (envelope from) match the visible From domain? Under relaxed alignment (default), a subdomain match counts; under strict, it must match exactly.
  • DKIM alignment (adkim) — does the d= domain in the DKIM signature match the visible From domain? Same relaxed/strict distinction.
  • DMARC passes if either SPF or DKIM passes and is aligned. A message can have SPF technically pass while failing DMARC, if the SPF-passing domain doesn't align with the From header.

In the parsed report, look at each row's source IP alongside its dkim and spf result columns and their alignment flags. Group by source IP first — this is usually the fastest way to spot the real issue.

Step 4: Identify every source IP, then sort them

For every unique sending IP in the report, ask: do I recognize this?

  • Known senders failing alignment — your ESP, CRM, or transactional provider is sending on your behalf but SPF/DKIM isn't aligned to your domain. This is a configuration fix, not a threat.
  • Unknown senders passing SPF but not DKIM (or vice versa) — could be a legitimate forwarder, could be a spoofing attempt. Cross-reference against your actual vendor list.
  • Unknown senders failing everything — likely spoofing attempts being reported to you as evidence DMARC is doing its job, even at p=none.

Step 5: Why you must not jump straight to p=reject

Once you see failures, the instinct is to lock it down immediately — flip to p=reject and stop the bad traffic. Don't, until every legitimate source in your reports is passing and aligned.

p=reject tells every receiving provider to drop, outright, any message claiming your From domain that fails DMARC. If a legitimate but misconfigured sender — a support tool, a CRM, an internal system, an old marketing platform — is still in your sending mix and not yet aligned, p=reject will silently kill their mail with zero warning. You won't find out until someone asks why their emails never arrived.

The correct progression:

  1. p=none — monitor only, collect reports, identify every legitimate sending source.
  2. Fix SPF/DKIM alignment for each legitimate source (usually via custom DKIM selectors and adjusting SPF includes).
  3. p=quarantine at a low percentage (pct=) — start enforcing softly, on a fraction of traffic, watch for unexpected impact.
  4. Increase pct= and move to p=reject only once reports show 100% of legitimate traffic passing and aligned, consistently, over multiple weeks.

Skipping straight to step 4 is the single most common way DMARC rollouts break legitimate mail flows.

Quick checklist

  1. rua= set, pointed at a parser, not a raw inbox.
  2. Start at p=none.
  3. Collect at least 1–2 weeks of reports before acting.
  4. Group failures by source IP; identify every unrecognized sender.
  5. Fix alignment for legitimate sources before tightening policy.
  6. Move p=none → p=quarantine (with low pct=) → p=reject, only as reports confirm it's safe.

Reading DMARC reports correctly is one piece of a larger authentication check — SPF, DKIM, and DMARC all interact, and a mistake in one shows up as noise in the others. The Cold Email Deliverability Kit (https://remixdenis.gumroad.com/l/kit) walks through all three in a 20-minute diagnostic pass. For the full policy rollout strategy and alignment troubleshooting, see Deliverability Diagnostics: What Actually Gets Email to the Inbox (https://remixdenis.gumroad.com/l/mclaie).

Top comments (1)

Collapse
 
md_pabel_fe07e07449db7326 profile image
MD Pabel •

Good step-by-step guide. Starting with p=none gives you time to find real senders before blocking valid mail.