Why does a DKIM checker say no record found?

A DKIM checker says no record found when DNS returns no usable key at the selector and signing domain it queried. The most common cause is an incorrect selector or domain. Other causes include publishing under the wrong DNS owner name, incomplete CNAME delegation, propagation delay, broken delegation or DNSSEC, and a provider that has not enabled signing. Take the selector and d= domain from a real DKIM-Signature header or the exact account setup screen, then query selector._domainkey.signing-domain.

Quick takeaways

• A DKIM lookup needs both the selector and signing domain.
• The visible From domain is not always the DKIM signing domain.
• DNS can be correct in a control panel but absent from authoritative servers.
• A published key does not prove that production messages are signed.
• Use account-generated values and a delivered header for final validation.

What does the failure mean?

RFC 6376 defines s= as the selector and d= as the signing domain. The receiver combines them to find the public key. If no usable key is returned, that signature cannot verify.

The error can also come from a manual checker that was given the wrong inputs. Start with the DKIM overview and use evidence from an actual message rather than guessing a selector such as default.

What usually causes it?

The selector or signing domain is wrong

The checker may use the visible From domain while the message is signed by a subdomain or provider. Selectors are arbitrary and can change during rotation.

The record is published under the wrong DNS name

Some DNS panels append the zone automatically. Entering a full name can create a duplicated suffix, or a CNAME can point to a misspelled provider target.

DNS is not publicly usable yet

The change may be cached, delegation may point elsewhere, authoritative servers may disagree, or DNSSEC validation can turn an apparent record into SERVFAIL.

The platform is not signing production mail

A provider can show setup values before the domain is verified or before signing is enabled. In that case, the message may contain no DKIM-Signature to test.

How do I diagnose the failure?

1. Obtain the exact selector and domain

Read s= and d= from the failing message. If the message is unsigned, use the values generated in the exact account and domain configuration.

2. Build the DNS owner name

Combine selector, _domainkey, and signing domain. Query the complete name for TXT and also check CNAME because many providers delegate selectors.

3. Follow delegation to the final answer

Resolve every CNAME target and confirm the final TXT key is available. Compare authoritative answers with public recursive resolvers.

4. Check message and account state

Confirm the provider marks the domain verified and that the actual sending stream adds a DKIM-Signature using the expected selector.

How do I fix it?

Correct the owner name, record type, target, or value using the provider's current account-generated instructions. Remove only conflicting records at the same selector after confirming they are obsolete. Repair delegation or DNSSEC when public resolvers cannot reach a consistent answer. DKIM verifier behavior treats an absent, revoked, or unusable key as a verification failure.

Then enable signing in the sending service if it is a separate step. Publish a new selector rather than replacing unrelated services that already use their own keys.

How do I validate the repair?

Query the full selector name from more than one resolver, then send a new message through the affected application. Confirm the message contains the expected d= and s= values and that the receiver records DKIM pass. Check DMARC alignment separately.

Use Palisade's DNS lookup tool for the exact name and Email Security Score for public posture. The delivered result proves the private key and production signer match the DNS key.