You published a DMARC record last month. Now Gmail, Microsoft and half a dozen other mail providers have started emailing you a small zip file, once a day, from addresses like noreply-dmarc-support@google.com. You open one, find a wall of XML, and close it again. Nobody told you what to do with these.
You do not need a dashboard, a subscription or a consultant to read them. They are plain text, built from the same handful of repeating blocks every time. Once you know what those blocks mean, reading one takes about ten minutes, and reading the next one takes about two.
Why you are getting these at all
The rua= tag in a DMARC record is an instruction to every mail provider that receives mail claiming to be from your domain: send a daily summary of everything you saw. That is the entire mechanism behind DMARC monitoring mode, and it is the reason the record is worth publishing even before you ask anyone to reject or quarantine anything.
Before you tell mail providers to act on failures, you need to see what is actually sending mail as you, because it is almost always more than the person who set up SPF originally accounted for. A domain that has existed for five years has usually accumulated senders nobody remembers signing up for: an old newsletter tool, a scanner that emails documents from the front desk, a CRM trial that never got cancelled, a staff member's personal automation script.
If you skip the monitoring step and jump straight to an enforcing policy, you find out about all of that by breaking it. Real mail starts bouncing or landing in spam with no warning, and by the time someone notices, it has usually been happening for days. Reading the reports first is how you find those senders on your own terms, while nothing is actually being blocked.
Opening the file
The attachment is a .zip or .gz file containing a single XML document, sometimes named something like google.com!yourdomain.com!1754611200!1754697600.xml.gz. That long filename is not random. It tells you who sent the report, which domain it covers, and the exact time window, given as two Unix timestamps, the report describes.
Double-clicking the file on a Mac or Windows machine extracts it using tools already built into the operating system, no download required. Open the resulting .xml file in any plain text editor, or drag it straight into a browser tab, which will usually format it with collapsible sections automatically. Either way works. You are not going to edit this file, only read it, so any tool that displays text is sufficient.
The shape of the file
Strip away the formatting and every DMARC aggregate report has the same three parts.
The report metadata at the top tells you who sent it, your domain, and the date range covered, almost always a single day. This part is worth a glance the first few times and then never again.
The published policy section repeats back the DMARC record it found for your domain when it ran the check: your policy (none, quarantine or reject), and the percentage of mail it applies to. This is a copy of what you published, not new information, but it is a useful sanity check that the provider is reading the record you think you published.
Then comes the part that actually matters: one record block for every distinct sending source seen during that window. A domain with a handful of legitimate senders might have five or six of these blocks a day. A domain with a lot of forwarded mail or old, forgotten integrations can easily have thirty.
The four fields inside each record
You only need to recognise four things inside each block, and they appear in roughly this shape:
<record>
<row>
<source_ip>198.51.100.44</source_ip>
<count>212</count>
<policy_evaluated>
<disposition>none</disposition>
<spf>fail</spf>
<dkim>pass</dkim>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>mail.invoicingtool.com</domain>
<result>pass</result>
</spf>
<dkim>
<domain>invoicingtool.com</domain>
<result>pass</result>
</dkim>
</auth_results>
</record>source_ip is the server that sent the mail. Sometimes this is instantly recognisable as your mail host. Often it is not, and you will need to look it up or match it against a list of services you use.
count is how many messages came from that IP during the window. This is the first thing worth sorting by. A source sending two hundred messages a day deserves attention today. A source sending three messages once a month can wait.
The SPF and DKIM results, shown twice, once under policy_evaluated for DMARC's own verdict and once under auth_results for the raw technical detail. The field that decides whether DMARC considers the message authenticated is policy_evaluated. A message can show pass under auth_results and still fail DMARC, because DMARC additionally checks that the authenticated domain lines up with the visible From address, a check called alignment. The example above shows exactly this: SPF passed for mail.invoicingtool.com, a completely legitimate result for that server, but it fails DMARC's evaluation because mail.invoicingtool.com does not align with yourdomain.com. DKIM passed and aligned, so the message survives on DKIM alone, which is exactly what DMARC is designed to allow: pass on either mechanism, not both.
disposition is what actually happened to the message: none, quarantine, or reject. While your policy is still p=none, this will read none for everything, regardless of whether SPF or DKIM passed. That is expected. Nothing is being blocked yet, by design.
A worked example
Say a report shows three blocks. One from an IP you recognise as your mail host, two hundred messages, both SPF and DKIM pass and align. One from an IP tied to your invoicing platform, forty messages, SPF fails on alignment but DKIM passes and aligns, similar to the example above. One from an unfamiliar IP address, six messages, both SPF and DKIM fail.
The first block needs nothing. The second is fine as it stands, since it passes DMARC through DKIM, but you can tidy it up by adding the invoicing platform to your SPF record too, so it is not depending on a single mechanism. The third is the one worth ten minutes of investigation: look up who owns that IP address, check whether it matches anything your business actually uses, and if it does not, note it and watch whether it keeps appearing.
That is the entire workflow. Almost every report you read will reduce to some version of these three categories: fine, fixable, and worth watching.
It is worth seeing what the third category looks like in the raw file, because it is the one people worry about most and recognise least. A block worth escalating tends to read something like this: source_ip an address you cannot connect to any service you use, count a number that jumps around day to day rather than staying steady, disposition still none because you have not enforced anything yet, and both spf and dkim reading fail under policy_evaluated, with no alignment on either in auth_results. Compare that against the invoicing platform example above, which failed one check but passed and aligned on the other. A block that fails everything, from a source with no plausible connection to your business, is the pattern that is actually worth spending time on. A block that fails one check but passes the other, from a source you can name, almost never is.
What a fail line usually means
The instinct is to read a fail as an attack in progress. Most of the time it is not. It is a tool you forgot you were using, or a forwarding arrangement doing exactly what forwarding does.
The senders that show up unexpectedly, again and again, in reports I have looked at for clients are the same handful: a CRM or invoicing platform sending receipts, a helpdesk tool sending ticket replies, a scanner or multifunction printer emailing scans "from" a staff address, an old newsletter service nobody has logged into in a year, and a member of staff who forwards their work mail to a personal Gmail account. All of these are legitimate. None of them were included when SPF was first set up, because whoever set it up did not, and could not, know every system in the business that sends mail on its behalf.
Forwarding deserves a specific mention because it produces a failure pattern that looks alarming and is not. When a message is forwarded, the forwarding server resends it, which means it is no longer coming from your original sending server, so SPF fails. DKIM, because it signs the message content rather than the sending path, usually survives forwarding intact. A message that fails SPF but passes DKIM, particularly from a source you can identify as a personal mailbox or a small third-party forwarding service, is very often this and nothing more.
Genuine forgery looks different from either of these patterns. It tends to come from an IP address with no obvious connection to any tool or person your business uses, sending a volume that does not match your normal traffic, sometimes from a country your business has no presence in, and it fails both SPF and DKIM with no alignment on either. That combination, unfamiliar source, both checks failing, no plausible business reason, is what is actually worth escalating.
Turning what you read into a fix
Once you can see who is actually sending as your domain, the fix is mechanical.
Legitimate sources that are failing SPF need to be added to your SPF record's include: list, provided you have room under the ten lookup limit, which is worth checking separately since it is easy to exceed without noticing. Sources that support their own DKIM signing, most invoicing and marketing platforms do, should have that turned on in their settings rather than relying on SPF alone, since DKIM survives forwarding and SPF does not.
Sources you do not recognise and cannot account for after a genuine attempt are worth a note and continued watching rather than immediate alarm. If the same unfamiliar source keeps appearing with a meaningful volume over several days, that is when it is worth raising with whoever manages your domain's security, or asking for a second opinion on what it is.
The enforcement timeline
Do the fixing above for two to three weeks before you touch the policy itself. This is the part people rush, and rushing it is what causes real mail to get blocked.
Start at p=none; pct=100, which is very likely already your setting if you have a record at all, and simply watch. In week one, expect surprises. Most domains discover at least two or three senders they had forgotten about. Add those, or turn on DKIM for them, and keep watching.
Once a few consecutive days pass with nothing new and unexplained appearing, move to p=quarantine; pct=25, applying the policy to a quarter of failing mail rather than all of it. This limits the damage if something was missed. If nothing goes wrong over several more days, increase the percentage in steps, then move the policy itself to p=reject once quarantine has run clean at 100% for a stretch. Each step gives you another window to catch a problem before it is blocked outright rather than after, and skipping straight from none to reject is the single most common way this goes wrong for small businesses.
Questions that come up
Do I need to read every report, every day? No. Skim daily for the first two weeks while you are still finding senders, then check weekly once things settle. Most providers' reports are close to identical day to day once your senders are accounted for.
Why do I only get reports from some providers and not others? Gmail and Microsoft are reliably consistent. Many smaller providers send reports rarely, in bulk, or not at all. This is normal and not a sign your DMARC record is broken.
Can I get these summarised automatically instead of reading XML by hand? Yes, paid DMARC monitoring services exist and are worth it once a domain has enough volume and enough senders that manual reading becomes tedious, typically once you are past a dozen distinct sources a day. For a smaller domain, reading the raw files by hand for a few weeks is genuinely faster than setting one up.
What if I am not getting any reports at all? If nothing has arrived after a week, the more likely explanation is that the DMARC record itself is not set up correctly, rather than that you have nothing to report. A malformed rua= tag is a common and easy mistake to make by hand.
The scale of the problem
68.7% of domains worldwide currently have no effective DMARC protection, meaning no record, an invalid one, or one sitting at p=none indefinitely (source: DmarcDkim, monitoring 1,276,088 domains, July 2026). Most of that group either never turned monitoring on, or turned it on and never read what came back. The mechanism exists on the majority of domains that have any DMARC record at all. Reading it is the part that turns it into actual protection.
Keeping a simple log instead of re-reading everything
You do not need software to track this either. A plain spreadsheet with five columns does the job: source IP, what you believe it is, first date seen, SPF result, DKIM result. Add a row the first time a new source shows up, and update the date each time you see it again rather than adding a new row.
This turns ten minutes of reading a day into something closer to thirty seconds most days, because you are only looking for rows that do not already exist. It also gives you a written record of when a source first appeared and how long it has been behaving consistently, which is exactly what you need to decide with confidence that it is safe to move your policy forward a step. If a client or accountant ever asks why a particular sender is trusted, you have the answer already written down instead of having to dig back through old reports to reconstruct it.
Checking where your own domain stands
If the reports have not started arriving, or you are not sure your DMARC record is even set up correctly, you can check the current state of your domain's SPF, DKIM and DMARC records with the free checker on the front page of this site. It reads what is published right now, scores it, and tells you in plain English whether the rua= tag is present and correctly formatted, which is usually where this goes wrong in the first place.