deliverlensName the two checks
A key lookup queries the selector and signing domain from a DKIM-Signature field. For s=outbound and d=example.com, the DNS name is outbound._domainkey.example.com. A syntactically usable key at that name shows that DNS retrieval worked at the observation time.
A signature verification takes a particular received message, canonicalizes the body and listed headers, computes hashes, retrieves the key, and verifies the cryptographic signature. It can fail even when the key record exists.
Compare the evidence
Use separate rows:
| Observation | Required evidence | What it can support |
|---|---|---|
| DNS key lookup | exact name, answer, resolver, time | a record was retrievable and parseable |
| Body hash check | original message bytes and bh= | signed body content matched after canonicalization |
| Signature check | original headers, b=, key, algorithm | the signature verified for the d= domain |
| Receiver result | trusted Authentication-Results | that receiver’s evaluation of that message |
Do not upload a customer message to an unknown web validator. Use the receiving provider’s trusted result or an approved local verifier, and redact only after verification because changing bytes can change the outcome.
Diagnose a mismatch
If the lookup fails, distinguish no record, invalid record, DNS timeout, and temporary resolver error. If the body hash fails, investigate content transformations. If the body hash matches but the signature does not, inspect signed headers, key/algorithm compatibility, and whether the wrong selector or message bytes were supplied.
A dashboard can show “DKIM record valid” while a real message is unsigned, uses another selector, or carries a failing signature. Conversely, a later DNS query can fail after a receiver successfully verified an earlier message; key rotation and cache timing matter.
Report precisely
Write: “At 12:00 UTC, resolver X returned a DKIM key for selector Y. Receiver Z reported dkim=fail for message M.” Keep those statements separate until the message-level cause is proven. Retest with a fresh message through the same sending stream after a change. Success means the trusted receiver verifies the intended signing domain, not merely that a DNS checker finds some key.