Why is my DKIM key failing?
Separate a missing public key from a failing message signature. DNS publication and signing are different steps, and a valid key record cannot prove that a message was signed correctly.
Get the exact domain and selector
Open a message that was actually sent through the affected service. In DKIM-Signature, read d= for the signing domain and s= for the selector. In a synthetic example with d=sender.example and s=mail1, the lookup name is mail1._domainkey.sender.example.
Enter those values in DKIM Checker. Common-selector discovery is a convenience, not an exhaustive inventory. A failed guess does not prove that the domain has no key.
Check what DNS publishes
Use TXT Lookup on the full name to inspect the record. Compare the complete value with the sending service's current public key. Check for an empty p= value, which revokes the key, damaged Base64 or the wrong key type. Do not publish a private key.
A DNS interface may expect a relative record name and append the zone automatically. Check the actual published owner name instead of assuming what the interface stored. Split strings within one TXT record are not separate keys.
Investigate a signature failure
If the key is readable, compare its fingerprint with the sender configuration. Rotation can leave the sender using a different key. Message transformations can also affect signed data. Read the trusted receiver's reported result in Email Header Analyzer, then use the sending service's logs or a full message verifier to investigate further.
Neither of these tools independently verifies the complete message's DKIM signature. Keep sensitive message contents out of public bug reports.
Worked example: one stale selector after rotation
A synthetic delivered message contains:
DKIM-Signature: v=1; a=rsa-sha256; d=sender.example; s=mail2; ...
Authentication-Results: mx.receiver.example; dkim=fail header.d=sender.example header.s=mail2
The relevant DNS name is mail2._domainkey.sender.example. Checking mail1 instead may show a valid 2048-bit key but tells you nothing about this message. Suppose mail2 publishes v=DKIM1; k=rsa; p=. Its empty key revokes that selector, so the checker reports a revoked key: zero usable keys at the required selector, even though the old selector works.
Obtain the exact public key from the configured signing service and replace the empty p= value in one TXT record. A healthy recheck should show the expected key type, 2048 bits for this example and a matching fingerprint. Do not copy a key from another sender or generate an unrelated one in DNS.
Send a new message. A trusted receiver reporting dkim=pass header.d=sender.example header.s=mail2 confirms its verification of that new message. The record checker alone cannot establish that result, and an old message signed before the repair need not verify.