Spoiler alert: DMARC reporting is a bit of a mess
If you want the TL;DR: Yes, DMARC reports are awkward to read. Yes, they arrive in quirky formats. And yes, if you are managing a domain with any kind of volume, a reporting tool like PowerMail will save hours by collecting, decoding, and visualising the data for you.
If you prefer to understand what is going on behind the curtain, or you opened one of those strange XML attachments and thought, “what am I looking at?”, this guide is for you.
DMARC the policy is tidy. DMARC the reporting is gritty. We will cover how reports are triggered, what is inside them, why files look different, and how to read them by hand without deploying software (although why anyone would be crazy enough to is beyond me).
Then we will give you a pragmatic shortcut if you would rather not live in XML.
Nerd Alert: If you really want to know…
1) How DMARC reporting actually works
DMARC lives in DNS. You publish a TXT record at “_dmarc.yourdomain.tld” that declares your policy and where to send feedback. The rua tag is what requests aggregate reports, and ruf requests failure reports. Example:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; adkim=s; aspf=s
Mailbox providers that support reporting read your DMARC record, and if you have rua=, they will typically send one aggregate XML report per day summarising the previous day’s traffic that used your domain in the visible From header. These are not per-message. They are grouped counts with authentication outcomes, per source.
Two important realities:
- Participation varies by provider. Many large providers send aggregate reports, including Google, Yahoo, Apple iCloud and Microsoft 365. Frequency and coverage can vary. Treat it as best-effort rather than guaranteed. In my experience, you see DMARC records for about 80% of what you actually send.
- Failure reports are optional and very rare. Even if you publish ruf=, most providers do not send these because of (apparently) privacy and abuse concerns. When they are sent, they use the ARF or AFRF formats, which can include message samples or headers.
External destination authorisation
If your rua or ruf points to a different domain, that external destination must authorise receiving reports for you. This is done by publishing a TXT record at _report._dmarc.destinationdomain.tld that references your domain. Without it, many receivers will not send your data to that address.
2) What arrives in your inbox and why it looks odd
You will receive emails to the rua address with attachments such as .xml.gz or .zip. These are common types of file compression and inside is a single XML file that follows the DMARC aggregate schema defined in the specification. The filename usually contains the reporter’s domain and the UTC date range the report covers.
Typical attachment patterns you will see:
- google.com!yourdomain.com!1728777600!1728864000.xml.gz
- yahoo.com!yourdomain.com!2025-10-10T00-00-00Z.zip
If you see only .xml, that is fine too. Some smaller systems skip compression.
3) Inside the XML: what each section means
Every aggregate report has the same three big blocks:
- Metadata
Reporter organisation, contact, and the date range of the report. - Policy
The DMARC policy you published and the policy the receiver actually applied. - Records
Repeating entries that group similar traffic. Each record includes the source IP, the number of messages, SPF and DKIM outcomes, and whether those were aligned with your From domain.
A minimal record looks like this:
<record>
<row>
<source_ip>203.0.113.45</source_ip>
<count>127</count>
<policy_evaluated disposition="none" dkim="pass" spf="fail"/>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>
<dkim domain="mailer.yourESP.com" result="pass" selector="s1"/>
<spf domain="mailer.yourESP.com" result="pass"/>
</auth_results>
</record>
Two key ideas you will use a lot:
- Alignment is the magic word. Passing SPF or DKIM is not enough. The result must be aligned with the domain in your visible From header. Alignment is controlled by adkim and aspf tags in your DMARC record, which can be relaxed r or strict s.
- Counts, not messages. Aggregate XML gives totals per bucket, for example 127 similar messages from one IP with the same auth results. There is no per-message body.
4) Why the files do not all match each other
The schema is standard, but implementations are not identical. You will see:
- Optional fields present in some reports and missing in others
- Slightly different namespace declarations
- Odd characters and encoding mistakes
- Compression differences and naming conventions
All of that is normal in the wild. The RFC defines the structure, but providers differ in how closely they follow it. Be prepared for malformed attachments and the occasional time format that looks like it fell out of a different century.
5) Read a report by hand without a tool
If you are determined to do it manually, here is the reliable workflow.
Step 1. Decompress the attachment
Use your OS archive utility or a tool such as 7-Zip to open .gz or .zip. You should end up with a .xml file.
Step 2. Open the XML with a real editor
VS Code, Sublime Text, or an online XML viewer will make this much less painful.
Step 3. Find the <record> entries
Skim the <row> for <source_ip>, <count>, and <policy_evaluated>. Then read the <auth_results> block to see which identifiers passed.
Step 4. Decide if it is expected or suspicious
- Does the IP belong to your ESP, CRM, or ticketing tool
- Did SPF or DKIM pass and align with your From domain
- If you see fails from unknown IPs, that is likely spoofing
Step 5. Look for patterns across reports
You are searching for repeated fails from the same IPs, sudden drops in pass rates, or new senders that need SPF or DKIM configuration.
This works, but it is slow and error-prone, especially once you have more than a week of reports to reconcile.
6) Aggregate versus failure reports, and why RUF is a headache
- Aggregate reports are the XML summaries described above, usually daily, grouped counts, and they are the backbone of DMARC visibility.
- Failure reports attempt to send near real-time samples of individual messages that failed DMARC. They are controlled by ruf= and fo= tags, and use the Abuse Reporting Format family of specs. In practice many providers either redact heavily or do not send them due to privacy and abuse concerns, so expect patchy coverage.
Quick tag refresher you will see in the wild:
- rua= where to send aggregate XML
- ruf= where to send failure reports
- fo= failure reporting options such as 0, 1, d, s
- adkim= and aspf= alignment strictness
- p= and sp= policy for your domain and subdomains
- pct= rollout percentage for policy application
7) Common surprises that cause confusion
- External destination not authorised. If you point rua to another domain and they have not published the _report._dmarc authorisation, many receivers will drop the reports.
- Microsoft 365 confusion. You will find advice from years ago saying Microsoft does not send aggregate reports. Today you are likely to receive them in many environments, although details can vary region by region. Treat Microsoft as a sender of aggregate reports, but do not assume 100 percent coverage.
- Not all traffic is represented. DMARC is passive. You only see what participating receivers choose to report based on what they received. There will be gaps.
8) The practical shortcut
You can absolutely live in XML, map IPs, and chase down alignment problems by hand. Or you can let software do the boring parts.
A capable DMARC reporting tool will:
- Collect reports from all providers into one mailbox
- Parse even the ugly ones, deduplicate, and normalise fields
- Show aligned versus unaligned traffic over time
- Pinpoint senders and selectors that need attention
- Alert you when pass rates dip or new sources appear
That is why most teams deploy a reporting tool once volume grows beyond a handful of domains. You still need to understand the fundamentals, but you do not need to be a full-time XML librarian to stay safe.
Final thoughts
DMARC reporting gives you eyes on the traffic that uses your brand in the visible From field. The aggregate XML is not pretty, but it is invaluable. Learn the basics, validate adkim and aspf, authorise any external destinations, and spot check a few reports by hand to build intuition. If your inbox is filling with .xml.gz attachments and you are not acting on them, you are flying blind. A reporting tool like Powermail makes the data usable, but the understanding you just earned will help you fix issues fast and speak confidently with your vendors and IT team.
Need help?
Still scratching your head and feel you’d benefit from some time an email deliverability expert? Book your 30-minute discovery call with Ben Fielding today.
