What this symptom usually tells you
DKIM keys are stored below selector._domainkey, so the domain name alone is insufficient to locate the key reliably. Providers choose selectors and can rotate them. A failed query for a guessed selector therefore cannot prove that the domain has no DKIM.
Evidence that narrows the cause
Use the live diagnostic to test the exact hostname involved. For this problem, the highest-value evidence is below. Treat each result as one piece of the business-email DNS and mail authentication diagnosis rather than as a standalone health score.
- Check provider admin console — Verify check provider admin console from the public Internet and compare it with the value the responsible provider says should be live.
- Inspect DKIM-Signature s= value — Use the selector configured by the sender or found in a DKIM-Signature header. Selector guessing is only a convenience and an empty guessed result is not proof that DKIM is absent.
- Query selector._domainkey — Verify query selector._domainkey from the public Internet and compare it with the value the responsible provider says should be live.
Record the current state before editing
Before changing business-email DNS and mail authentication settings, save the exact public values for check provider admin console, inspect DKIM-Signature s= value, query selector._domainkey and note which hostname or mail path is failing. This creates a rollback point and prevents a later resolver cache, provider dashboard or unrelated working record from being mistaken for the original cause. Change one evidence-backed setting at a time, then compare the same signals again.
Safest repair path
Get the selector from the mail provider’s admin console or from the s= tag in a DKIM-Signature header of a real message. Query that exact selector, then publish or correct the provider-supplied TXT/CNAME key at the authoritative DNS service.
How to confirm this specific repair
The exact selector should resolve publicly to the key/provider target and a newly sent message should show a DKIM pass in Authentication-Results. If the provider rotates selectors, validate the selector actually used by current mail rather than only an older published key.
A common wrong turn
Do not create a generic selector such as default simply because an automatic checker tried it. The selector must match the signer’s configuration; publishing an unused key does not make outgoing messages DKIM-authenticated.
When to escalate with evidence
If these public checks match the provider's current documented configuration but the service still fails, give support the exact hostname, the observed business-email DNS and mail authentication result, a timestamp, and the failing network or message path. That separates a provider-side incident from a DNS change that has not actually become authoritative.
Technical references
These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.