How to Read DMARC Reports

Learning how to read DMARC reports is the moment email authentication stops being a checkbox and becomes a feedback loop. Every day, mailbox providers send you machine-generated files listing every server that claimed to send mail as your domain and whether each message passed. Most senders never open them, because the files arrive as compressed XML that looks hostile to human eyes. This guide covers the two report types, what the raw XML actually contains, how to read source IPs and alignment results, and the three findings that should change what a cold email sender does next. It assumes your records already exist. If you have not published SPF, DKIM, and DMARC yet, start with our SPF, DKIM, and DMARC setup guide and come back once reports start arriving.

Reading these files is routine work for us. Our parent agency, Referral Program Pros, has run more than 4,000 outbound campaigns and booked over 7,000 meetings, and DMARC reports are part of how every sending domain behind those campaigns gets verified before and during a campaign. GTM Bud is built on the same playbook, backed by a guarantee of 5 percent positive replies on LinkedIn or 1.5 percent on email, or a full refund. You can only underwrite a number like that when you know your mail authenticates in production, not just in a DNS checker.

What is the difference between aggregate and forensic DMARC reports?

DMARC produces two report types, and only one of them deserves your attention. An aggregate report, requested with the rua tag, is an XML summary a receiving provider sends on a schedule, typically daily, listing every source IP that sent mail using your domain, the message count from each, and whether that mail passed SPF, DKIM, and alignment. A forensic report, requested with the ruf tag and also called a failure report, is a per-message notification generated the moment an individual email fails DMARC, carrying message-level detail that can include headers. Aggregate reports are the ones that matter: they arrive reliably, cover all traffic rather than only failures, and contain no message content. Forensic reports are sparse in practice because most receivers decline to send them for privacy reasons, and Google sends none at all, as PowerDMARC’s failure report documentation and other DMARC vendors note. Build your reading habit on aggregate reports and treat any forensic sample as a bonus clue.

Dimension	Aggregate report (RUA)	Forensic report (RUF)
Requested with	rua=mailto:[email protected]	ruf=mailto:[email protected]
Cadence	Daily by default, per the 86400-second interval in RFC 7489	Per failing message, as it happens
Contents	Source IPs, counts, SPF and DKIM results, alignment, disposition	Message-level failure detail, often headers
Message content	None	Can include headers and subject lines
Who sends them	Most major mailbox providers	Few receivers; Google does not send them
Role for senders	Primary reading, the basis for every policy decision	Occasional extra evidence when a receiver offers it

One related tag worth knowing: fo controls when failure reports fire. The default of 0 asks for a report only when every mechanism fails, while fo=1 requests one on any failure, per RFC 7489. Given how few receivers send forensic reports anyway, leaving this alone is fine.

Why do DMARC reports arrive as raw XML?

Because the format was designed for machines, and the delivery pipeline never grew a human-friendly layer. RFC 7489 specifies that aggregate reports are XML files, compressed with GZIP or sent as plain XML, attached to an ordinary email delivered to your rua address. Even the attachment filename is standardized: the receiver’s domain, your domain, and the covered time window as Unix timestamps, separated by exclamation marks. A day of Google traffic on your domain produces an attachment like this:

google.com!yourdomain.com!1789344000!1789430399.xml.gz

Every reporting provider sends its own file, so a domain whose mail reached Gmail, Outlook, and Yahoo inboxes yesterday wakes up to three separate compressed attachments today. That is the raw-XML reality: nobody is going to render this for you unless you make them.

You have two workable options. At cold email volume, with one sending tool and a handful of mailboxes, the reports are short and you can read them by hand in minutes once you know the structure, which the next section covers. Or you point the rua address at an analyzer that parses and charts everything: Valimail offers a free DMARC report analyzer that monitors continuously and labels sending services by name, per Valimail’s product page, and the free lookup tools at MXToolbox will parse an individual record or report file when you need a one-off check. Either way, read the next two sections first. A dashboard showing a headline pass percentage is useless until you know what a pass actually measures.

How to read the DMARC report XML: the three sections that matter

Open the attachment, unzip it, and you will find the same three-part structure in every report, because RFC 7489 defines the schema all receivers follow.

Section	Key fields	What it tells you
report_metadata	org_name, report_id, date_range	Which provider is reporting and the window covered
policy_published	domain, p, sp, adkim, aspf, pct	The DMARC policy the receiver saw in your DNS at check time
record	source_ip, count, policy_evaluated, auth_results	One block per sending source: who sent, how much, what passed

The record blocks are where the reading happens. Here is a single record, trimmed to the fields that matter:

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>147</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>yourdomain.com</domain>
      <result>pass</result>
      <selector>google</selector>
    </dkim>
    <spf>
      <domain>bounce.senderplatform.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Read it bottom-up. The auth_results section shows the raw checks: SPF passed, but for bounce.senderplatform.com, and DKIM passed for yourdomain.com. The policy_evaluated section shows the DMARC verdicts after alignment: SPF fail, DKIM pass. The message still passes DMARC overall because one aligned mechanism passed, and disposition shows what the receiver did with it, here nothing, because the policy was p=none.

Source IPs and alignment: reading pass and fail correctly

The single most important reading skill is the difference between auth_results and policy_evaluated. The first is the raw result of each check, along with the domain that check was evaluated against. The second is the aligned result, meaning the check only counts as a DMARC pass if the domain it passed for matches the visible From domain in identifiers. In the example above, SPF genuinely passed, just for the sending platform’s bounce domain rather than yours, so DMARC scored it as an SPF fail. A raw pass sitting next to an aligned fail is not a contradiction. It is the report telling you exactly which domain got credit for the check.

Whether “matches” means exactly equal or merely the same organizational domain is set by the adkim and aspf tags in your record, which default to relaxed mode per RFC 7489, so mail.yourdomain.com aligns with yourdomain.com unless you opt into strict mode.

The other half of the skill is mapping source_ip values to real senders. Run a reverse DNS lookup on each IP and compare against the services you actually use: your email provider, your sending tool, your CRM. A cold sending domain should map almost every IP to one known source within minutes. Whatever refuses to map goes in a separate mental bucket, which the diagnosis section below sorts out. To confirm what the reports tell you against a live message, the Show original check in Gmail from our email deliverability testing guide gives you the same pass and fail verdicts on a single send in real time.

The three things a cold email sender should look for

Aggregate reports contain more data than a cold sender needs. These three checks extract everything that matters, in order.

1. Your own sending volume passes with alignment. Find the records whose IPs map to your sending tool and provider. The counts should roughly match what you actually sent, and policy_evaluated should read DKIM pass on effectively all of it. If your own mail is failing here, stop everything else and fix it, because every message is being evaluated as potentially forged.
2. No legitimate mail shows a bad disposition. Scan the disposition field across records. At p=none it will read none everywhere, but once you tighten policy, any quarantine or reject on mail you actually sent means real prospects never saw it. Enforcement roadmaps from DMARC monitoring vendors such as DMARC Report recommend a consistent aligned pass rate above 95 percent across at least 30 days before moving from p=none to quarantine.
3. What the unmapped IPs are doing. Sources you cannot attribute are either harmless forwarding or someone abusing your domain, and the difference is readable in the results pattern, covered next.

That is the whole discipline: a few minutes per week per domain. Authentication decides whether your message gets evaluated at all; targeting and copy decide whether it earns a reply, which is the layer an AI cold email writer works on once the infrastructure columns all read pass.

When does a DMARC fail mean spoofing, and when is it your own tool?

A fail in a DMARC report has exactly four common signatures, and each one points to a different response. Forwarding breaks SPF because the forwarder’s server is not in your SPF record, but a DKIM signature travels with the message and survives, so forwarded mail shows an SPF fail beside a DKIM pass and still passes DMARC. A misconfigured sending tool shows the opposite profile: high counts from a known service failing alignment the same way on every message. Spoofing shows IPs that map to nothing you use, failing both mechanisms outright, because a spoofer cannot sign with your DKIM key or send from your authorized servers. That last pattern needs no fix on your side. It is the evidence that eventually justifies p=reject.

Pattern in the report	Likely cause	What to do
Known tool’s IPs, raw SPF pass for another domain, aligned SPF fail, DKIM pass	Platform bounce domain in the Return-Path	DMARC still passes; configure a custom return path for full alignment
Known tool’s IPs, DKIM signed by the tool’s own domain, both aligned checks fail	Tool still using its default DKIM domain	Enable the custom sending or DKIM domain option in the tool, then recheck
Scattered IPs with small counts, SPF fail, DKIM pass	Forwarding through gateways and mailing lists	Nothing; DKIM survives forwarding and DMARC passes
Unmappable IPs, SPF and DKIM both fail, often in bursts	Spoofing attempt using your domain	No fix exists on your side; move toward quarantine and then reject

The second row is the one that quietly costs cold senders money. A tool signing with its own default domain means every message you pay to send fails DMARC, and sustained failures feed the reputation systems receivers score you with, which is measurable in the dashboards covered in our guide to checking email domain reputation. The fix is usually a single setting, but only a report reader ever finds it, because the mail still gets delivered somewhere and nothing visibly errors.

Frequently asked questions about reading DMARC reports

How often are DMARC aggregate reports sent?

Daily by default. The ri tag in your DMARC record requests a reporting interval in seconds, and the default defined by RFC 7489 is 86400, which is 24 hours. Most receivers send one aggregate report per domain per day regardless of what you request, usually covering a midnight to midnight UTC window, and each reporting provider sends its own separate file.

Why am I not receiving any DMARC reports?

Work through four checks. Confirm your record contains a rua tag with a valid mailto address. If the report address is on a different domain than the one being reported on, RFC 7489 requires that domain to publish an external destination verification record before providers will send to it. Reports only come from providers that received your mail during the window, so a very low volume domain may have nothing to report yet. Finally, check the spam folder of the report mailbox itself.

Do DMARC reports contain personal data or message content?

Aggregate reports do not. They carry source IPs, counts, and authentication results, with no subject lines, recipient addresses, or body content, which is why forwarding them to a third party analyzer is safe. Forensic reports can include headers and subject lines, which is the privacy reason most receivers decline to send them and Google sends none at all.

Do I need a paid tool to read DMARC reports?

No. A cold sending domain usually has one legitimate sending source, so its reports are short enough to read by hand using the three sections above. If you want a dashboard, Valimail’s free report analyzer parses aggregate reports continuously and labels sending services by name, per Valimail’s product page. Paid monitoring starts to matter at fleet scale, such as an agency watching many client domains at once, a workflow we describe in our guide to cold email for agencies.

How long should you stay at p=none reading reports before tightening policy?

Two to four weeks minimum, longer if the domain sends through several third party tools. Vendor enforcement roadmaps such as DMARC Report’s recommend a consistent aligned pass rate above 95 percent across at least 30 days of reports before moving to quarantine. A cold sending domain with a single sending source and clean reports typically qualifies at the fast end of that range.

Read the reports weekly, then let sending be someone else’s job

Knowing how to read DMARC reports comes down to a short routine: open the aggregate XML or a dashboard rendering of it, confirm your own sending volume passes with alignment, confirm no legitimate mail is being quarantined or rejected, and sort unmapped IPs into forwarding or spoofing using the fail patterns above. Ignore forensic reports you mostly will not receive anyway. Ten minutes a week per domain keeps authentication a solved problem instead of a slow leak.

If you would rather not own that routine at all, GTM Bud runs cold email on managed, authenticated sending infrastructure where alignment is configured correctly from day one and monitored continuously, backed by the same guarantee our agency carries: 1.5 percent positive replies on email or a full refund, with a 7-day trial. Start with the cold email automation tool and let the XML land in someone else’s mailbox.