The DMARC record went in a month ago. The rua address pointed at a real mailbox, and that mailbox now holds forty compressed files. Each one contains a page of XML. Nobody has opened the second one.
That is the state we find most small companies in, and it is not laziness. The reporting works. The reading never starts, because the format was written for machines. Say a twelve person accounting firm: invoices leave from the accounting package, campaigns from a marketing tool, and everyday mail from Google Workspace. The reports know about all three senders. The team does not.
You do not have to learn the XML to get the answer out. This is the short path we run on a client domain: what the file actually holds, how to turn one into a readable list in about a minute, the three verdicts that come out of that list, and what each one costs if you leave it alone.
What is actually inside the file
An aggregate report is a count, not a copy. The receiver groups every message it saw claiming your domain by sending IP address and by authentication outcome, then sends you the totals for the period. No subject lines, no recipients, no message bodies.
The format has its own specification. RFC 9990, published in May 2026 on the standards track, covers aggregate reporting; together with RFC 9989 and RFC 9991 it replaced RFC 7489, which had been the reference since 2015. Under RFC 9990 each record carries a row element with the connecting source_ip, a count of messages, and a policy_evaluated block holding the disposition and the DKIM and SPF results, alongside identifiers and auth_results.
Reports arrive because your published record asked for them:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Google Workspace Admin Help puts the cadence plainly: reports are usually sent once a day, by email, to the addresses in the record, and every mail server that receives mail from your domain sends one. That is why the mailbox fills. A domain with real volume collects reports from providers it has never heard of. Point rua at a group, not at a person who might leave.
If you want the XML decoded element by element, we wrote that separately: how to read a DMARC aggregate report. For the decision you are trying to make today, you can skip it.
Turn one report into a readable list
Take the newest attachment from the receiver you send the most mail to. It will be an .xml, .xml.gz or .zip file. Upload or paste it, and read the list that comes back instead of the markup.
Our DMARC report analyzer is free and needs no signup. It decompresses and parses the file in your browser, in memory, and shows the policy you actually published, the total volume in the report, your DMARC pass rate, every sending source ranked by volume, and, the part that matters most, which legitimate looking senders are not aligned and would be quarantined or rejected the moment you enforce.
The three columns that decide everything
Whatever tool you use, you are reading three things per row.
- Source. The IP address that connected, and usually a recognisable owner behind it: your mail provider, a marketing platform, a web host, something you cannot place.
- SPF alignment. Not just whether SPF passed, but whether the domain it passed for lines up with the domain in your From header.
- DKIM alignment. The same question asked of the signature on the message.
The gap between passed and aligned is where most people lose an afternoon. RFC 9989 defines two modes: relaxed alignment means the two domains share an organizational domain, strict means they are identical. The adkim and aspf tags both default to relaxed, so unless you set them you get the forgiving version and it is still not automatic.
DMARC passes when at least one of SPF or DKIM passes and is aligned. Google's sender guidelines make the same point for bulk mail into Gmail: set up both SPF and DKIM, but only one of them has to align for the message to meet the requirement. A row showing SPF pass with no alignment is a failing row.
The three verdicts, and what each one costs
Aligned and passing
Your own provider, usually the largest block of volume. Nothing to do. Note the volume so you know what normal looks like next month.
Legitimate, but not aligned
This is the work, and it is almost always the same cast: the invoicing system, the CRM, the helpdesk, the newsletter tool, the online store, the office printer that emails scans. They send as your domain with their own authentication, which passes for their domain and not for yours.
The fix is per sender and lives in the vendor dashboard, not in a single DNS edit. Most platforms offer a custom return path or a set of DKIM CNAME records to publish; some are better handled on a dedicated subdomain so their reputation stays separate from your everyday mail. Each one you leave unaligned is a category of mail that stops arriving the day you enforce. That is the real cost of not reading the reports.
Unauthenticated and nothing to do with you
Scattered IPs, small counts, no authentication that lines up with anything you own. Some of it is spoofing, some is stale noise from lists and scrapers. You cannot fix this in DNS, because there is nothing of yours to fix. Enforcement is what stops it, which is the point of the whole exercise.
The rows that will fool you once
Forwarding is the usual false alarm. When a message goes through an alias or a mailing list, the forwarding server connects from its own IP, so SPF breaks, while the DKIM signature often survives intact. The row looks alarming and is a forwarder doing its job. If DKIM still aligns, DMARC still passes.
One report is one receiver's view of one day, not your traffic. A hundred percent pass rate on a quiet Sunday tells you nothing. And low count rows from unfamiliar IP addresses are worth a look but rarely worth a panic; volume is the signal.
From one file to a sender inventory
The deliverable from this exercise is not a clean report. It is a list you can act on, and it takes a week or two of reports rather than one.
- Collect reports for at least a week so quiet days and monthly billing runs both show up.
- Write down every source with volume, and mark whether SPF aligns, DKIM aligns, or neither does.
- Sort into three buckets: keep as is, fix alignment, and not ours.
- Give every sender in the fix bucket an owner and a due date. Someone has to log into that vendor dashboard.
That list is the thing we build first on every deliverability engagement, because you cannot safely tighten a policy you have not inventoried.
When to move the policy
Stay at p=none until every legitimate sender in the inventory aligns on SPF or DKIM. Then move to quarantine, watch a full week of reports, and only then reject. We walk through the ordering and the percentage rollout in moving DMARC from p=none to p=reject.
Worth knowing if you send in volume: since 1 February 2024, senders of more than 5,000 messages a day to Gmail accounts must have SPF, DKIM and a DMARC record in place, and must keep the spam rate reported in Postmaster Tools below 0.3%. The DMARC policy itself may stay at none to meet that bar, so reading your reports is not about passing an audit. It is about knowing what breaks before you decide to tighten.
How Guanacos Tech helps
We do this on client domains most weeks: collect a fortnight of reports, build the sender inventory, align the senders worth keeping, and move the policy in stages while watching what changes. If you have a mailbox of XML you have not opened, or you have read them and want a second pair of eyes before you enforce, that is what our email deliverability consulting for small business covers. A short call is enough to tell you whether your inventory is clean or whether something would break on the day you turn enforcement on.