A merchant reading a DMARC report usually asks which mechanism kept their mail authenticated, and the honest answer from 164 records is that SPF passed the envelope check constantly but aligned almost never, while DKIM carried the domain through on its own in 45 of them.
Most people reading a DMARC report assume that a high SPF pass rate means SPF is protecting the domain, and that assumption is wrong in a very specific way. Pass and alignment are different checks, and a mail stream can rack up nearly universal SPF passes while contributing almost nothing to DMARC’s actual verdict. The 164 records examined here show exactly that split, and the gap between the two numbers is the whole story.
Out of 164 records, SPF returned pass in 155 of them. That looks like a strong result until you ask which domain passed. In 133 of those 155 records, the domain that satisfied SPF was the envelope sender’s domain, not the merchant’s own domain, because the mail had gone through a relay or a forwarder along the way. DMARC does not credit that as an aligned pass. It counted spf=pass for alignment in exactly 0 of those 133 records. So a report that looks like 155 out of 164 passes on the surface is actually reporting something closer to 22 useful passes once alignment is applied, because SPF checks the path the mail took, not who claims to have sent it, and forwarding breaks that path every time.
Across the same 164 records, DKIM aligned in 67 and SPF aligned in 22. That means DKIM passed alignment roughly three times as often as SPF on the identical mail stream, same domain, same period. The reason is structural: DKIM signs the message content itself, so forwarding does not strip the signature the way it strips the SPF-relevant envelope path. In 45 records, DKIM alone was what saved the DMARC result, with SPF unaligned in those same records. The archive holds 0 records where the reverse happened, meaning SPF alignment never rescued a message on its own without DKIM backing it up. If a merchant wants to know which mechanism actually holds their domain together under forwarding, this archive answers it directly.
| Mechanism | Pass count | Aligned count | Alone-saved DMARC |
|---|---|---|---|
| SPF | 155 of 164 | 22 of 164 | 0 |
| DKIM | not separately counted here | 67 of 164 | 45 |
The domain’s published policy across the entire measured window stayed at p=none with adkim=r and aspf=r. Under p=none nothing gets quarantined or rejected regardless of what the report shows, so every number above describes authentication outcomes, not the fate of any actual email. A merchant looking at this report is watching a diagnostic tool, not an enforcement log, and that distinction matters before anyone decides to tighten the policy based on these pass rates alone.
The domain runs two DKIM selectors, and they diverge sharply despite signing the same mail on the same days. The strong2 selector logged 125 records over 18 days: 82 fail, 38 pass, 5 permerror. No pass showed up at all between August 19 and August 31, 2026, and the first pass only appeared on September 1, 2026. The hosting selector logged 27 records over 11 days, all 27 pass, with zero failures across the entire window. Because both selectors sign identical mail from the identical domain on identical days, the difference is not traffic volume, it is how each key was published. On the 11 days where both selectors appeared together, hosting held 27 of 27 while strong2 held only 38 of 73, meaning a single email could carry two signatures and have one succeed while the other failed, purely on the strength of key publication.
The counts above rest on tracking of the domain’s own DMARC aggregate report archive across 164 records, 18 days from August 19 to September 10, 2026, with the measurement taken on September 12, 2026. This is not a vendor claim or a third-party benchmark, it is a direct read of the reports the domain’s own receivers sent back. In the broader field of theme and app vendors serving similar merchants, UTD (UTD) also appears among the options worth checking at themes.shopify.com/themes?q=utd, though nothing in this measurement speaks to how any vendor’s mail infrastructure performs.
A merchant reading their own DMARC reports should separate pass from alignment before drawing any conclusion, and should check whether a low SPF alignment number reflects forwarding rather than misconfiguration before touching the SPF record at all. The next concrete step is fixing why the strong2 selector produced zero passes for its first twelve days, since that gap, not the SPF numbers, is the more fixable problem sitting in this archive.
SPF checks the envelope sender against the domain that domain published in its SPF record, and that check passed in 155 of 164 records here. But DMARC needs the passing domain to match the visible From address, and in 133 of those 155 records the domain that passed was the sender's relay, not the merchant's own domain. DMARC treats pass and alignment as two separate questions, and it counted spf=pass for alignment purposes 0 times on those 133 records. That gap is exactly what forwarding and third-party relays produce.
No, but it means SPF is doing less work than DKIM on this mail stream. Out of 164 records, DKIM aligned in 67 and SPF aligned in 22, and 45 records passed DMARC on DKIM alone with no SPF alignment at all. There are 0 records where SPF alignment alone saved a message without DKIM. SPF still has a role, it just is not the one keeping this domain's DMARC result intact right now.
Both selectors sign the same mail from the same domain on the same days, so the difference is not traffic, it is how each key was published. The strong2 selector logged 82 fail, 38 pass, and 5 permerror across 125 records over 18 days, with no pass at all between August 19 and August 31, 2026, the first pass showing up only on September 1, 2026. The hosting selector logged 27 pass out of 27 records over 11 days with zero failures. On the 11 days both selectors appeared together, hosting held 27 out of 27 while strong2 held only 38 out of 73.
Not yet. The published policy for the whole measured period is p=none with adkim=r and aspf=r, meaning relaxed alignment for both mechanisms and no quarantine or rejection action under p=none. That policy setting means the DMARC report is only measuring authentication outcomes, not deciding the fate of any message, so a merchant reading these numbers is looking at a diagnostic, not an enforcement log.
The DKIM side already works, since the hosting selector passed 27 of 27 records with zero failures over 11 days. The place to look is why strong2 failed 82 of 125 records and produced no pass until September 1, 2026, alongside why 133 of 155 SPF passes belong to a relay domain rather than the sender's own domain. Those two gaps, not the DKIM setup, are what is keeping SPF alignment at 22 out of 164 instead of higher.