A single domain's DMARC archive shows 39 reports from 7 organizations over 18 days, and the usual habit of summing every report's counts overstates the mail because 27 day-and-source pairs got described twice.
Most people who open a DMARC aggregate report treat every row as a separate, additive fact, so they add up the counts across all the reports they received and call that their mail volume for the period. That habit is the mistake this guide settles. The archive examined here covers one domain over 18 days, from 2026-08-19 to 2026-09-10, with 39 reports filed by 7 different organizations, and it shows exactly where summing goes wrong and exactly which authentication mechanism is actually holding the domain together.
Across 164 records in the archive, SPF returned pass in 155 of them. Read alone, that number suggests SPF is working almost everywhere. But DMARC does not grant credit for SPF passing in the abstract, it grants credit only when the domain SPF checked is aligned with the domain in the message’s From header. In 133 of those 155 passing records, the domain that passed SPF was the sender’s envelope domain, not the domain under review, so alignment failed and DMARC counted spf=pass for exactly 0 of those 133 records. A report that only quotes the raw pass rate is quoting a number that has almost nothing to do with what DMARC actually protects.
The same 164-record archive shows dkim=pass in 67 records and spf=pass, aligned, in 22. That means DKIM aligned about three times as often as SPF on the identical mail stream. The more concrete number sits underneath that ratio: in 45 records, DKIM alone rescued the message from failing DMARC, with SPF unaligned in every one of those cases, and the archive contains 0 records of the reverse pattern, where SPF alone saved a message that DKIM missed. For a domain owner deciding where to spend limited attention, that is not a subtle signal. DKIM signing is the mechanism actually keeping this domain out of failure, and SPF alignment is close to decorative on this mail stream.
The domain’s published policy stayed unchanged for the entire period: p=none adkim=r aspf=r. Under p=none, nothing gets quarantined and nothing gets rejected, so every record in every one of the 39 reports is answering the question “did this message authenticate,” never the question “did this message get delivered, quarantined, or blocked.” Anyone reading these reports as a measure of blocked spoofing attempts is reading them wrong, because the policy in force during this window never blocked anything. The reports describe what would happen under a stricter policy, not what did happen to the mail itself.
Over the 18 days measured, 7 different organizations filed 39 reports about this one domain, and their coverage was uneven: some reporters covered as little as 1 day of the 18, others covered as many as 12. That spread matters because a missing report from one reporter on a given day usually means that reporter did not file for that day, not that no mail was sent. Treating an absence as proof of zero mail volume, when it might just be one provider’s incomplete reporting habit, produces a false read on the domain’s actual traffic.
| Measurement | Value |
|---|---|
| Records with SPF raw pass | 155 of 164 |
| Records with SPF aligned pass | 22 of 164 |
| Records with SPF pass but wrong domain | 133 of 155 |
| Records with DKIM aligned pass | 67 of 164 |
| Records saved by DKIM alone | 45 |
| Records saved by SPF alone | 0 |
| Reporters over 18 days | 7 organizations, 39 reports |
| Reporter coverage range | 1 to 12 days |
| Duplicate day-and-source records | 27 |
The part that breaks a simple sum is this: 27 times in the archive, the same day and the same source IP address were described by two different reporting organizations. Add up every report’s counts without deduplicating and that mail gets counted twice for those 27 pairs. The fix is to aggregate by the pair of day and source, not by summing raw report totals, and to be careful about counting reporters at all, since 2 of the 7 organizations in this archive turned out to be the same mailbox operator filing under two different org_name values. Counting distinct reporters by org_name alone would overstate how many actual providers are watching this domain’s mail.
These counts rest on tracking of one domain’s own DMARC aggregate report archive across 18 days, from 2026-08-19 through 2026-09-10, covering 164 individual records inside 39 reports, measured on September 12, 2026. A domain owner reading a stack of DMARC reports should deduplicate by day and source address before trusting any total, and should treat SPF’s raw pass rate as background noise until it is checked against alignment, since DKIM alone is what keeps this particular domain’s mail authenticated.
In the archive checked here, SPF returned pass in 155 of 164 records, which looks reassuring on its own. But DMARC does not care whether SPF passed in general, it cares whether the domain that passed SPF matches the domain in the From header, and that alignment failed in 133 of those 155 cases. So the report shows spf=pass at the protocol level while DMARC still counts it as 0 aligned passes for those records, because the sending domain and the From domain were different.
On this domain's 164 records, DKIM aligned in 67 cases and SPF aligned in only 22, so DKIM carried roughly three times the load. More tellingly, 45 records were rescued by DKIM alone with SPF unaligned, and 0 records showed the opposite pattern of SPF alone rescuing a message. That is a direct answer: fix and monitor DKIM signing first, because it is doing nearly all the work here.
No, because under p=none nothing gets quarantined or rejected in the first place. The published policy across the entire measured period stayed at p=none adkim=r aspf=r, so every record in the archive is a record of authentication results, not a record of delivery outcomes. A report under p=none can only tell you whether a message would have passed, never whether it was blocked, because nothing was blocked.
Not safely. Across 39 reports from those 7 organizations over 18 days, 27 records describe the same day and the same source IP twice, filed by two separate reporters, so a plain sum double-counts that mail. Two of the 7 organizations are also the same mailbox operator listed under two different org_name values, so counting distinct reporters by org_name overstates how many providers actually see this domain's mail.
Not necessarily. Coverage among the 7 reporters in this archive ranged from as little as 1 day up to 12 days out of the 18-day window, so a gap in one reporter's timeline usually means that reporter did not file for that day, not that mail volume was zero. The only safe way to check for a real gap is to look at whether any of the 7 reporters covered that date, not whether one particular reporter did.