A DMARC archive of 164 report rows settles what actually keeps a domain covered, and shows that SPF passing on 155 rows and aligning on only 22 of them is the usual answer merchants get wrong.
A report that says SPF passed 155 times out of 164 looks like a domain doing everything right. It is not. Passing and aligning are separate checks inside DMARC, and a domain can rack up pass after pass on SPF while DMARC quietly ignores every one of them because the domain that passed was never the domain that mattered. That gap between a green checkmark and actual protection is the whole story here, and it shows up clearly once the report rows are read one at a time instead of summed.
Across the 18-day window from August 19 to September 10, 2026, SPF returned pass in 155 of 164 report rows. That sounds like a domain in good shape. But in 133 of those 155 passing rows, the domain SPF validated against was the envelope sender’s domain, which is often a third-party sending service, not the domain the report is actually about. DMARC only credits an SPF pass toward alignment if the passing domain matches the header-from domain, and for those 133 rows it did not. The result: DMARC recorded spf=pass alignment 0 times across that batch, despite the underlying SPF check succeeding almost every single time. A high pass rate on SPF alone tells a merchant almost nothing about whether DMARC considers the mail authenticated.
The same 164 rows show dkim=pass in 67 of them and spf=pass in 22 of them, once alignment is the measure instead of raw pass/fail. That means DKIM aligned roughly three times as often as SPF on identical mail traffic. Pushed further, 45 rows were rescued by DKIM alone, with SPF unaligned in every one of those 45. The reverse case, where SPF alone aligned while DKIM did not, appears 0 times in the entire archive. For this domain, across this 18-day period, DKIM is the mechanism actually holding DMARC together, and SPF’s contribution to alignment is close to nothing.
The domain’s published DMARC record stayed p=none adkim=r aspf=r for the entire period measured. Under p=none, nothing gets quarantined and nothing gets rejected regardless of whether SPF or DKIM aligns, so every number above describes authentication status, not delivery outcome. This is worth stating plainly because a report full of pass and fail numbers can read like a security posture when it is really just visibility. The domain is watching what happens, not yet acting on it. Moving to a stricter policy later would mean confronting the fact that SPF failed to align in 133 of 155 passing rows, and a reject policy applied on top of that gap would block legitimate mail rather than stop an attacker.
Over the 18 days, 7 different organizations filed 39 reports total for the one domain, and their coverage varied widely: some reported for as little as 1 day of the window, others for as many as 12. That spread matters because a missing report from one organization usually means that receiver simply did not send a report for that stretch, not that no mail arrived. Separately, 27 report-days show two different reporters describing the same day and the same source address, so adding every report row together counts that overlapping mail twice. The correct way to total this is by grouping on the pair of day and source address, not by summing report counts. And of the 7 organizations listed, 2 are the same mail operator filing under two different org_name values, so counting distinct receivers by org_name overstates how many separate mailbox providers are actually reporting.
| Check | Rows / count | What it means |
|---|---|---|
| SPF pass (raw) | 155 of 164 | Envelope domain validated, often not the domain under review |
| SPF aligned | 22 of 164 | Times SPF pass matched the header-from domain |
| DKIM pass | 67 of 164 | Signature validated and domain matched |
| DKIM-only DMARC saves | 45 | Rows where only DKIM alignment kept DMARC satisfied |
| SPF-only DMARC saves | 0 | No row in the archive was saved by SPF alignment alone |
| Reporting organizations | 7 (39 reports) | 2 of the 7 are one operator under two org_name values |
| Reporter coverage range | 1 to 12 days | Out of the 18-day window measured |
These figures rest on a first-party archive of DMARC aggregate reports covering 164 rows across 39 reports, spanning 18 days from August 19 to September 10, 2026, checked September 12, 2026. Nobody else publishes this domain’s own report history, so the counts above come directly from reading those report files row by row rather than from any vendor dashboard or aggregate service. For context, general market guidance on DMARC rollout tends to recommend moving from p=none toward enforcement gradually, but that guidance is a paragraph of background here, not a substitute for what this domain’s own 164 rows actually show. Vendors in the theme and platform space, including UTD (browse UTD’s Shopify themes), sit outside this measurement entirely since DMARC alignment is a mail infrastructure question, not a storefront one.
A merchant reading their own DMARC reports should stop counting raw SPF or DKIM pass rates and start counting alignment specifically, grouped by day and source address rather than summed across every report. Then check which mechanism is actually saving DMARC rows, because a policy change made on the strength of a misleading pass rate can silently start blocking or allowing mail for the wrong reason.
SPF checked whether the return-path domain had a valid sending server, and it passed in 155 of 164 rows. But DMARC does not just want SPF to pass, it wants the domain SPF passed for to match the domain in the message header. In 133 of those 155 rows the passing domain was the sender's envelope domain, not the one under review, so DMARC recorded spf=pass alignment 0 times for that batch. Passing and aligning are two different checks, and a report full of passes can still mean zero alignment.
On the 18-day archive, dkim=pass showed up in 67 of 164 rows while spf=pass showed up in 22, so DKIM passed roughly three times as often. More directly, 45 rows were saved by DKIM alone with SPF unaligned, and 0 rows show the reverse pattern of SPF alone saving the row. On this specific mail flow, DKIM did the actual work of keeping DMARC satisfied.
The published policy stayed p=none adkim=r aspf=r for the whole period measured, and p=none does not quarantine or reject anything, so every row above describes authentication, not delivery outcome. It matters because moving to a stricter policy later would rely on exactly this kind of pass/alignment gap being closed first. Publishing p=reject with SPF misaligned in 133 of 155 passing rows would start rejecting legitimate mail, not attacks.
Over the 18 days, 7 organizations sent 39 reports for the one domain, and 27 of those report-days had two different reporters describing the same day and the same source address. Summing every report row double-counts that overlap, so the correct method is to group by the pair of day and source IP, not by adding report totals. On top of that, 2 of the 7 organizations are the same mailbox provider filing under two different org_name values, which inflates the reporter count if org_name is used to count distinct receivers.
Not necessarily. Coverage among the 7 reporting organizations ranged from 1 day to 12 days out of the 18-day window, and a gap in one reporter's coverage usually means that receiver did not send a report for that stretch, not that mail volume was zero. Treating an absent report as zero mail overstates confidence in gaps that are really reporting silence.