Reading your DMARC reports
Somewhere in your infrastructure there is a mailbox filling with small gzipped XML files that nobody opens. Those files are the only systematic record of who sends email as your domain — your real infrastructure, your providers, your forwarders, and everyone pretending to be you. This is how to read them, and what to do with what they say.
What is actually in the file
An aggregate report has three blocks. The report metadata names the receiver who produced it, the reporting period (usually one UTC day) and a report ID — provenance, so you know whose view of your mail this is. The policy published block echoes your own DMARC record back at you: the domain, the alignment modes, the policy (p) and the percentage it was applied to. Receivers include it because it is the policy they enforced, and discrepancies between it and what you think you published are themselves a finding. Then come the records — one per source, per stream: a source IP, a message count, the disposition the receiver applied (none, quarantine, reject), the DMARC evaluation of SPF and DKIM alignment, the identifiers (the From domain, the envelope domains), and the raw authentication results underneath. Nothing else. No content, no recipients, no subjects — counts and verdicts, by design, so the files are safe to handle and useless for anything except the question they answer: who sent as us, and did it check out?
The vocabulary that trips everyone is the two-layer result. A record carries both authentication results — did SPF pass, did the DKIM signature verify — and alignment results, which are the ones DMARC grades: did the domain that passed match the domain in the visible From header? A marketing platform can pass SPF perfectly as itself (its bounce domain, its servers, all authorised) and still fail DMARC, because "itself" is not you. The report's policy_evaluated block is the alignment verdict, and it is the only verdict that decides disposition. When you open a report in the DMARC report analyser, the table is built from those evaluated results — pass means aligned, which is why a row can show a provider's authentication succeeding in the raw results and the row still failing. If the records themselves are the question — what does my SPF say, is a reporting address even published — that is the email deliverability check; the reports are what those records produce in the wild.
Reading a source table like an operator
Merged across receivers and days, the records become a census of your mail, and it sorts into four populations. First, your own infrastructure: your mail servers and your provider's, passing both alignments, carrying most of the volume. Any change here — a new IP, a sudden failure — is an incident or a migration you forgot to finish. Second, third-party senders you pay for: CRMs, support desks, invoicing and marketing platforms. This is where alignment failures concentrate, because each platform defaults to authenticating as itself. Each one is a configuration ticket: custom return-path for SPF alignment, DKIM signing with your domain for the stronger fix. Third, forwarders and mailing lists, recognisable by the signature of SPF alignment failing while DKIM passes — forwarding rewrites the envelope and breaks SPF, while a signature survives the trip. These pass DMARC on DKIM and need nothing from you. Fourth, sources you cannot name. Steady small volume is usually a forgotten internal system — a scanner, a cron job, an old application server still sending alerts as the corporate domain. Bursty volume failing both alignments, appearing in several receivers' reports at once, is what spoofing looks like from the receiving end. Both belong on a list with an owner; only the handling differs.
Volume is the prioritisation key. A failing stream of twelve messages a day is a hygiene fix; a failing stream of forty thousand is either your biggest legitimate sender misconfigured — which means real mail is one policy change away from the junk folder — or a campaign wearing your name. The disposition column tells you what receivers already did about it: while your policy is p=none the answer is "delivered it anyway, but wrote it down", which is precisely the deal monitoring mode offers. The reports are the evidence base that the companion problem — legitimate mail in the spam folder — is diagnosed from in why your email lands in spam: authentication failures are visible here weeks before a customer mentions a missing invoice.
From reading to enforcing: the only safe order
Aggregate reports exist to make one journey safe: p=none to quarantine to reject. Publish p=none with a reporting address and you are running surveillance — nothing is blocked, everything is counted. Read until every source is named: align the providers, accept the forwarders, identify the internal stragglers. When a full reporting cycle — give it two to four weeks, long enough to catch monthly senders like invoicing runs — shows failing volume consisting only of sources you are happy to see refused, move to quarantine, which sends failures to junk rather than the inbox, and keep reading: the reports now show disposition quarantine on the failing streams, confirming receivers honour it. Then reject, applied to 100 percent (pct has no reason to be anything else by now), and the unknown sources stop reaching inboxes at all. Skipping the reading phase is how DMARC projects break a company's email and get rolled back to p=none forever; the reports are not bureaucracy around the work, they are the work. Two warnings from the field: subdomain policy (sp) defaults to the main policy, so enforcement surprises subdomains you forgot sent mail — the reports cover them too, read those rows before climbing. And a report stream that suddenly stops is also information: a receiver that stops reporting, or a DNS change that dropped the rua address, blinds you quietly — silence in this mailbox should never last a week unnoticed.
Frequently asked questions
How often do aggregate reports arrive, and from whom?
Roughly daily per receiver, covering the previous day (UTC), from every large mailbox provider that saw mail claiming your From domain and honours DMARC reporting — Google, Microsoft, Yahoo, Apple and a long tail of regional providers and filtering services. Each sender produces its own file with its own report ID, so a week of mail means dozens of small XML files. That fragmentation is exactly why reports go unread without a tool that merges them by source.
Can aggregate reports tell me who is spoofing me right now?
They tell you about yesterday, in counts, per source IP — which is usually enough. A spoofing campaign shows up as a new source with volume, failing both alignments, often across several receivers' reports at once. What the reports never contain is content: no subjects, no bodies, no recipient lists. For live alerting on the records themselves rather than yesterday's traffic, monitoring the DNS records continuously is the complement, not the substitute.
My reports show a sender I authorised failing. Is DMARC broken?
Almost never. Authorised is not the same as aligned: the provider is authenticating as itself — its own bounce domain for SPF, its own signing domain for DKIM — while DMARC grades the alignment of those results with your From domain. The fixes are configuration, not protocol: a custom return-path subdomain for SPF alignment, or DKIM signing with your domain, both standard settings at every serious sending platform.