Begin with the signature that needs explaining
A useful DKIM checker starts with a particular signature or a confirmed sending configuration. Asking only for a domain invites the checker to guess a selector and then report an absence that may be irrelevant. The first question is which message, signing domain and selector the reader is investigating. If those inputs are unavailable, the honest result is that the target key cannot yet be identified.
This guide specifies a proposed diagnostic approach. It does not provide or demonstrate a working EmailAuth checker. No message was imported, DNS request sent or signature verified. The exact catalogue implementation gate remains open: Implement and test the promised function. An article, mock-up or specification alone is not a working tool.
Preserve the evidence before extracting fields
For a later authorized investigation, retain the received message in a controlled location before making a redacted working copy. Record its origin and collection time. Copying only a visually displayed header may discard folding, repeated fields or the body bytes required for cryptographic verification. The diagnostic view should explain which input was supplied and whether it is sufficient for the claimed check.
Locate each DKIM-Signature field separately. Read its d= signing domain and s= selector without replacing either with the visible From address or a provider's familiar default. Other tags describe the algorithm, canonicalization and signed material. Multiple signatures deserve separate rows; selecting only the first can conceal another signature relevant to DMARC. RFC 6376 defines the signature fields.
Construct the exact public-key question
The lookup owner is formed from the selector, the _domainkey label and the signing domain. In a purely fictional example, d=sender.example and s=mail2026 imply mail2026._domainkey.sender.example. That is a constructed name, not an executed query or an observed key. A confirmed provider configuration can supply these values when a message is not available, but that path proves configuration intent rather than live signing.
Retain the input fields beside the constructed owner and TXT record type so another reviewer can check the derivation. Preserve any alias chain and resolution status rather than presenting only the final text. A network timeout, refused query or server failure is not a finding that the selector has no key. DNS response semantics and resolver context matter. RFC 6376 key lookup and RFC 1035.
Explain the key record without collapsing distinct outcomes
A TXT record can contain several character strings that together form its value. That differs from receiving multiple separate key records. The proposed checker should preserve record boundaries, parse the DKIM tags and report malformed or ambiguous data explicitly. An empty p= value indicates revocation, not a missing DNS response. A public key's presence alone does not establish that the sending application possesses or uses the matching private key.
Algorithm interpretation must include updates to the original DKIM specification. RFC 8301 prohibits rsa-sha1 for signing and verification and updates RSA key requirements. RFC 8463 adds Ed25519-SHA256. A tool should state its supported algorithms and version instead of turning an unsupported implementation into a universal claim that a key is invalid. No library, algorithm implementation or installed tool has been tested here. RFC 8301 and RFC 8463.
Separate lookup, verification and alignment
Use three distinct conclusions: key material was observed, the supplied signature verified, and the resulting signing identity aligned with the author domain. Each needs different evidence. Cryptographic verification needs the relevant message bytes, signature parameters and key. A current key lookup may also differ from what a receiver saw when an older message arrived, particularly around rotation or revocation.
A trusted Authentication-Results assertion can document what a receiver reported, but it is not interchangeable with independently re-verifying an altered message. Identify the receiver and trust boundary before relying on that assertion. Conversely, redacting a signed header or body can change the verification input; a failure on the derivative does not automatically prove the original failed. RFC 8601 and RFC 6376.
Under current RFC 9989, a passing DKIM signature contributes to DMARC when its authenticated identifier aligns with the author domain. A valid signature from an unrelated domain is therefore not enough by itself. The checker should label the alignment mode and evaluated identities instead of converting any DKIM pass into a DMARC pass. RFC 9989.
Design a result that leads to a bounded next step
A useful proposed result contains the supplied message reference, extracted d= and s= values, exact query owner, observation time, record parsing outcome, verification scope and alignment assessment. Add the evidence supporting each conclusion and explain what was not checked. Do not invent a green live-signing badge from a successful DNS lookup.
If the selector was guessed, request a real signature or confirmed configuration before advising a DNS correction. If the key is available but verification fails, investigate message modification, wrong key selection and sender configuration before recommending a replacement. Keep private keys out of the checker entirely. Obtaining a customer message, querying a domain, sharing evidence and changing DNS each require their own authorized scope.
Keep the promised demonstration outstanding
The exact original-evidence requirement is: Show the message-to-query chain and distinguish key availability from live signing. The fictional derivation above explains the method but does not meet that operational requirement. A working implementation would need retained tests for real selector extraction, record boundaries, errors, supported algorithms and message verification before its results could be trusted.
Sources were reviewed on 8 November 2026. This article remains documentary preparation with independent review, human technical and privacy approval, implementation evidence, visual checks and owner publication release pending. It reports no completed lookup, test or product capability.