DKIM Checker

Short answer: A DKIM check reads the public TXT record at selector._domainkey.domain. It can show whether a selector publishes a public key record, but it cannot prove a particular message was signed, that the private key matches or that a receiver accepted the signature. Pair this DNS observation with message-level verification and DMARC alignment. This page gives a bounded public observation for DKIM Checker, not a universal promise about every user, provider or future request.

What it measures

The tool validates the domain and selector, constructs the DNS name and requests its TXT record. It keeps the public response bounded and reports the key record without fetching mail or private signing material. A selector comes from the DKIM-Signature header, so choosing the wrong selector can produce an empty result even when another selector is active. Read the form status and result together. A missing or unavailable upstream response is different from a clean result, and the submitted input must remain attached to the evidence.

Protocol and standards

RFC 6376 defines DKIM signing and verification, including the selector namespace and public-key record. RFC 8301 documents cryptographic and key-size guidance, while RFC 8616 updates DKIM considerations. DNS is only one input to verification; canonicalization, selected headers, body hash, signature timestamp and receiver policy are message-specific. The linked primary references explain the terminology and normative boundaries. Implementations, caches, trust stores, resolver behavior and operator policy can still affect a live observation, so standards should guide interpretation rather than replace it.

Inputs and validation

Enter the sender domain and exact selector, such as s1. Do not paste a complete email, signature header or private key. The selector is case-sensitive in operational configuration even though DNS comparison has defined rules. Confirm the provider selector from a signed message or documented setup before checking the record. Keep private mail data out of the form. Use only the public value requested by the form. Remove credentials, fragments, private addresses and unrelated paths. Validation protects the upstream request and prevents private material from entering a diagnostic workflow.

Outputs and evidence

The result shows a public TXT response and whether a DKIM-style key value is visible. A p= value identifies public key material when present; an absent value differs from DNS failure. The tool does not decode private data, validate a signature over a message or decide whether a receiver’s trust policy will pass. Preserve selector and domain with the result. Preserve the input, status and check time when sharing the result. Empty, unavailable and positive responses have different meanings. Do not combine rows from separate checks without keeping their names, protocols and timestamps visible.

Worked example

If a signed message contains d=example.com and s=s1, query s1._domainkey.example.com. A response containing a public key supports the limited conclusion that the selector record is published. To verify the message, a mail system must also check signature, body hash, canonicalization, header selection, time and key policy. A DNS answer alone cannot make that conclusion. This is an explanatory example, not a claim that the same value exists for another domain or endpoint. Re-run after a controlled change with equivalent inputs so the difference can be attributed safely.

How to interpret the result safely

Match domain and selector from the actual DKIM-Signature header. A visible record with an unsupported or weak key is not automatically healthy, and a missing record can reflect rotation or a provider using another selector. Treat DNS visibility, cryptographic verification and DMARC alignment as separate checkpoints. Compare the message timestamp with key publication and rotation windows. First ask whether the tool measured the question you actually have. Then compare an important conclusion with an independent source such as provider configuration, a real message, an authoritative registry, a browser observation or an operator log.

Limitations and upstream behavior

DNS caches, selector rotation, provider aliases and multiple sending services can change results. A public key record does not expose a private key and cannot tell whether the signer used it correctly. The checker does not inspect mail headers, calculate a body hash, enforce algorithm policy or emulate every receiver’s trust rules. Use authorized mail logs for final diagnosis. Network location, cache state, rotation, rate limits and policy can change public results. Use the upstream operator documentation for remediation or account action. This tool reports uncertainty instead of inventing a value.

Troubleshooting checklist

1. If the result is empty, copy selector and domain from a real signed message and check the exact underscore path.
2. If DNS returns text but verification fails, inspect canonicalization, header changes, body modification and key algorithm support.
3. If a provider recently rotated keys, compare message time with old and new selector publication windows.

Key takeaways

• The tool validates the domain and selector, constructs the DNS name and requests its TXT record. It keeps the public response bounded and reports the key record without fetching mail or private signing material. A selector comes from the DKIM-Signature header, so choosing the wrong selector can produce an empty result even when another selector is active.
• Match domain and selector from the actual DKIM-Signature header. A visible record with an unsupported or weak key is not automatically healthy, and a missing record can reflect rotation or a provider using another selector. Treat DNS visibility, cryptographic verification and DMARC alignment as separate checkpoints. Compare the message timestamp with key publication and rotation windows.
• DNS caches, selector rotation, provider aliases and multiple sending services can change results. A public key record does not expose a private key and cannot tell whether the signer used it correctly. The checker does not inspect mail headers, calculate a body hash, enforce algorithm policy or emulate every receiver’s trust rules. Use authorized mail logs for final diagnosis.

FAQ

Sources

Primary references used for this guide:

• RFC 6376 - DomainKeys Identified Mail
• RFC 8301 - DKIM Cryptographic Update
• RFC 8616 - Email Authentication Status Codes

Related tools