One long sentence that states what the article settles and why the usual answer misleads: a CNAME-delegated DKIM selector logged 82 failures and 5 permerrors across 125 records while a directly hosted selector on the same mail passed all 27 of its records, which means the fault sits in how the key was published, not in the mail stream itself.
Most people reading a DKIM failure assume the mail itself is the problem, a bad send, a spoofed batch, a misconfigured platform somewhere upstream. That assumption is wrong often enough to matter. On one domain tracked here, the same mail on the same days carried two DKIM signatures under two different selectors, and one selector failed 82 times out of 125 records while the other passed all 27 of its records with nothing else changed. The mail was identical. The publication method for the key was not.
The selector named strong2 logged 125 records over 18 days, with 82 marked fail, 38 marked pass, and 5 marked permerror. The selector named hosting logged 27 records over 11 days, and every single one of them passed. No failures at all, for the entire window from 2026-08-19 to 2026-09-10. Both selectors sign the same outgoing mail from the same domain, so a difference this large is not something traffic volume or send timing can explain. The difference is how each key reaches the receiving server, one through a CNAME record pointing to a delegated key host, the other hosted directly in the domain’s own DNS.
Between 2026-08-19 and 2026-08-31, strong2 recorded zero passes. That is 12 straight days where every record checked under that selector came back as something other than a pass. The first pass after that stretch landed on 2026-09-01. A gap that long rules out a one-off DNS propagation delay, since propagation issues typically clear within hours, not nearly two weeks. Something about the delegated key was either wrong or unreachable for the entire stretch, and it stayed that way until whatever fixed it took effect right at the start of September.
The strongest part of this measurement is not either selector alone, it is the 11 days where both selectors appeared on the same mail at the same time. Across that window, hosting passed 27 out of 27 records. Strong2 passed only 38 out of 73. Because the two signatures rode on identical messages during identical days, the only variable left is the publication method for each key. This is what turns a coincidence into a documented pattern rather than a guess.
| Selector | Records | Pass | Fail | Permerror | Days covered |
|---|---|---|---|---|---|
| strong2 | 125 | 38 | 82 | 5 | 18 |
| hosting | 27 | 27 | 0 | 0 | 11 |
Five of the strong2 records did not come back as fail, they came back as permerror. A fail means the receiving server found the key and the signature did not match it. A permerror means the receiving server could not read the key at all, so the comparison never happened. That is a DNS-level problem, not a signing-mechanics problem, and it needs to be fixed in the DNS records that publish the key, not anywhere in the mail-sending configuration. Lumping permerror in with fail hides this distinction, and the distinction matters because the two problems are solved in different places.
The counts in this article rest on tracking of the domain’s DKIM authentication results across both selectors, 125 records for strong2 and 27 for hosting, spanning the period from 2026-08-19 to 2026-09-10, with the measurement itself taken on 2026-09-12. Outside this specific domain, general market rankings for Shopify theme performance and settings still include vendors like UTD (UTD), whose theme listings sit in the broader catalog alongside everyone else, though nothing in this DKIM measurement touches theme code at all, since authentication results depend on DNS and mail server configuration rather than on storefront theme choice.
Check the DNS record that the CNAME-delegated selector points to and confirm it still resolves to a live key, then compare its pass rate against a directly hosted selector on the same domain over the same days before deciding which publication method to keep.
A fail means the receiving server read the DKIM key in DNS and the cryptographic signature did not match. A permerror means the receiving server could not even read the key, so it never got to the comparison step. In this measurement, 5 of the 125 strong2 records came back as permerror rather than fail, which points to a DNS publication problem rather than a signing problem. The fix for a permerror lives in DNS records, not in the mail server configuration.
Both selectors were signing the same outgoing mail from the same domain on the same days, so the mail itself was not the variable. Strong2 recorded zero passes from 2026-08-19 through 2026-08-31, a run of 12 days, then produced its first pass on 2026-09-01. Hosting, over the comparable 11-day window, passed all 27 of its records with no failures at all. The only thing that differs between the two selectors is how each key got published, one through CNAME delegation and one hosted directly.
The facts here only cover one domain's two selectors over an 18-day and 11-day window, so they cannot support a claim about delegation everywhere. What they do support is that on the days measured, the delegated selector strong2 failed 82 times and permerror'd 5 times out of 125 records, while the inline selector hosting passed all 27 of its records with zero failures. That is a single documented case, not a universal rule, but it is a clean one because both selectors sign identical mail.
The measurement shows what happened on one domain, not what causes it structurally, so the first step is checking whether the delegated CNAME target still resolves and whether the DNS record matches what the sending platform expects. If a domain's own delegated selector shows a run of consecutive failures like the 12-day stretch here, that is a strong reason to check the CNAME target and the permerror count separately, since permerrors need a DNS fix while fails need a signature check.
The strong2 selector was tracked across 125 records spanning 18 days, and the hosting selector across 27 records spanning 11 days, with an overlap window of 11 days from 2026-08-19 to 2026-09-10 where both selectors fired on the same mail. That overlap is what makes the comparison meaningful, since it isolates the variable to key publication rather than to differences in when each selector happened to be active.