A DMARC report lands in an inbox as an XML attachment nobody wants to open, yet inside that file is a record of every server on the internet that sent email pretending to be your domain. Understanding what a DMARC report reveals matters for two reasons: it exposes phishing attempts using your brand before customers report them, and it tells you whether your own marketing tools are configured correctly enough to land in inboxes instead of spam folders.
Most domain owners publish a DMARC record once, during an initial security setup, and never look at the reports again. That’s the gap this article closes – not just what DMARC is, but what the aggregate and forensic reports actually contain, how to read them without specialized software, and what patterns should trigger a response from a brand or security team.
What a DMARC report actually contains
DMARC (Domain-based Message Authentication, Reporting and Conformance) generates two types of reports once a policy is published in DNS.
Aggregate reports (RUA) arrive daily from major mailbox providers – Google, Microsoft, Yahoo – as compressed XML files. Each one summarizes every message that claimed to be from your domain during a 24-hour window: the sending IP, the volume of messages, whether SPF and DKIM passed or failed, and what the receiving server did with the message (delivered, quarantined, or rejected).
Forensic reports (RUF) are rarer because most providers stopped sending them after 2018 privacy concerns, but when available they include a redacted copy of individual failing messages, which is far more useful for investigating a specific phishing campaign.
A typical mid-sized company sending 50,000 emails a month through a legitimate ESP like SendGrid or Mailchimp will see that volume show up as “pass” entries from known IP ranges. Anything outside that – a block of messages from an unfamiliar IP range in, say, a hosting provider in Vietnam, claiming to be from your domain and failing SPF – is either a misconfigured internal tool or someone spoofing your brand.
Reading the XML without a dedicated parser
Aggregate reports are technically readable in a text editor, but nobody does that at scale. Free parsers like dmarcian’s report analyzer or Postmark’s DMARC digest tool convert the raw XML into a table showing source IP, volume, and pass/fail rate. Google Workspace admins can also route DMARC reports into a dedicated Postmaster Tools dashboard for a rolling view.
The fields that matter most in every report:
Source IP – where the message actually originated. SPF result and DKIM result – whether each authentication mechanism passed independently. Disposition – what the receiving mailbox server did with messages that failed (none, quarantine, or reject). Header From – the domain the recipient saw, which is the one attackers are trying to impersonate.
A message can fail SPF but still pass DMARC if DKIM passes and is aligned, which surprises people who expect both checks to matter equally. DMARC only requires one of the two to pass and align with the visible “From” domain – that’s the mechanism, not a bug.
The myth that DMARC blocks phishing on its own
A common misconception is that publishing a DMARC record with a p=reject policy stops phishing against your customers. It doesn’t – it stops attackers from spoofing your exact domain in the “From” field of an email that passes through DMARC-checking mail servers. It does nothing about lookalike domains such as repvigiI.com (with a capital I instead of lowercase l) or repvigil-support.net, which is a separate problem covered by typosquatting monitoring, not DMARC. A brand can have a flawless p=reject policy and still get hit by a lookalike-domain phishing campaign the same week, and reports will show nothing because the attacker never touched the real domain’s authentication records.
What patterns in the reports should worry a marketing or security team
An experienced deliverability lead doesn’t read every report line by line – they watch for shifts in the pass rate over a rolling seven-day window. A sudden spike of failing volume from a new IP range usually means one of three things: a new marketing tool was connected without updating the SPF record, an employee is using a personal Gmail alias to send on behalf of the company, or someone is actively spoofing the domain for a phishing run.
The rollout sequence matters more than people expect. Moving straight to p=reject without first running p=none for at least 30 days is the single most common mistake – it can silently block legitimate transactional email (password resets, invoices) sent through a forgotten subdomain or a legacy CRM integration nobody remembered was still active. The safer sequence is p=none for a month while reviewing reports, then p=quarantine for another two to four weeks, then p=reject once every legitimate sending source is accounted for in SPF and DKIM.
Another mistake: treating the “rua” reporting address as a mailbox that gets checked manually. At any real volume, that inbox fills with dozens of daily zipped XML files within a week and gets ignored. Routing rua reports into a monitoring dashboard or an automated parser, rather than a shared inbox, is what actually keeps the data usable. This is one of the areas where automated reputation monitoring tools add value beyond DNS setup alone, since they can flag anomalies in authentication failure rates the same way they flag a spike in negative reviews.
Setting up SPF and DKIM correctly in the first place removes most of the noise DMARC reports would otherwise surface – see SPF, DKIM, DMARC Explained for the underlying mechanics of how the three standards interact.
Frequently asked questions
How often should DMARC aggregate reports be reviewed?
Weekly is enough for most businesses under 100,000 monthly emails; anything above that volume, or any business that has recently been targeted by phishing, should review daily during the first 90 days of a new policy rollout.
Do DMARC reports show who opened a phishing email?
No. Reports only show what happened at the receiving mail server (accepted, quarantined, rejected) before the message reaches an inbox – they contain no data about whether a human opened or clicked anything inside it.
Can DMARC reports come from every domain that receives my email?
Only from providers that support DMARC reporting, which covers the large majority of consumer and business mailbox providers, but plenty of smaller regional providers, especially outside North America and Europe, don’t send reports at all, so gaps in coverage don’t necessarily mean zero spoofing activity.
Treat DMARC reports the same way a SOC analyst treats a SIEM alert feed – not as a one-time setup task, but as a recurring signal that needs a review cadence and an owner. The technical lift to publish a DMARC record takes an afternoon; the value only shows up when someone is actually reading what the domain reports back over the following months, and connecting that to broader email authentication practices across every sending source the brand uses.