# Dig DKIM record > Use dig to query a DKIM record by selector, interpret TXT or CNAME results, and know when DNS evidence is not a message pass. To dig a DKIM record, query the selector and signing domain from `DKIM-Signature`: `dig +short TXT ._domainkey.`. For example, `s=mail2026` and `d=example.com` become `mail2026._domainkey.example.com`. A non-empty `p=` value shows public key material at that name. An empty `p=` revokes the key and cannot verify a signature. Neither result proves that a receiving mailbox passed a specific message. [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html) defines the selector-based lookup. ## Quick takeaways - Start with the `s=` selector and `d=` signing domain, not the visible From address. - Query the selector-scoped name for a TXT answer. - Treat a non-empty `p=` value as DNS-publication evidence only; an empty `p=` revokes the key. - If the selector is a CNAME, verify the target before judging the key path. - Use receiver-added `Authentication-Results` to check whether a delivered message passed DKIM. ## Build the DKIM DNS name A DKIM signature identifies a signing domain with `d=` and a selector with `s=`. A verifier combines them as `._domainkey.` when retrieving the public key. That selector lets one domain publish separate keys for different senders or key rotations. [RFC 6376 section 3.1](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.1) describes selectors, while [DNSimple's DKIM record guide](https://support.dnsimple.com/articles/dkim-record/) shows the same selector-scoped DNS pattern. Use an actual delivered message when possible. Copy the values from its `DKIM-Signature` field instead of guessing a selector from a provider name or querying the root domain. This is an illustrative header, not a record to publish: ```text DKIM-Signature: v=1; d=example.com; s=mail2026; ... ``` Those values produce this lookup name: ```text mail2026._domainkey.example.com ``` ## Run the dig command Run the TXT query against the full selector-scoped name: ```bash dig +short TXT mail2026._domainkey.example.com ``` Replace both example values with the `s=` and `d=` values for the message or the exact provider-generated selector. Cisco's [DNS lookup guide for DKIM](https://www.cisco.com/c/en/us/support/docs/security/secure-email-gateway/217073-how-to-use-dig-nslookup-to-find-spf-dki.pdf) documents the same `dig` approach for DKIM-related DNS records. If that command does not show a TXT public key, ask DNS specifically whether the selector is delegated: ```bash dig +short CNAME mail2026._domainkey.example.com ``` Then query the returned target for TXT. Do not replace the target with a guessed provider hostname. A [CNAME record](https://www.rfc-editor.org/rfc/rfc1034.html) can be a valid delegation path, but the target must still return usable DKIM key material for the lookup to reach a public key. ## Read the result A TXT result with a non-empty `p=` value contains public key material for the exact name you queried. It supports the limited conclusion that the selector's public DNS path is published. An empty `p=` means the key is revoked and cannot verify a signature. Neither result reveals a private key, proves that a sender is currently signing, or establishes the result at a receiving mailbox. [RFC 6376 section 3.6.1](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.6.1) defines the DKIM key record and its `p=` tag. A CNAME result means the selector name delegates elsewhere. Follow that target and inspect its TXT result. A no-answer or `NXDOMAIN` result means the queried name did not provide a usable answer. It can reflect a wrong selector, wrong signing domain, unpublished record, or resolver view. It is not evidence that the entire domain has no DKIM configuration. ![Decision flow for interpreting a selector-scoped DKIM dig lookup, including TXT key, CNAME, no-answer, and message-pass boundaries.](/images/editorial/dig-dkim-record/dkim-dig-decision.png "1600x900") *Source: Original deterministic diagram based on [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html). [Open the full-size diagram](/images/editorial/dig-dkim-record/dkim-dig-decision.png).* ## What to do after the DNS lookup When the TXT record is present, send a fresh message through the same production path and inspect the receiver's `Authentication-Results`. A `dkim=pass` result there is message-level evidence, whereas the DNS query only checked the public lookup path. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) specifies the `Authentication-Results` field and its trust boundary. When the selector does not resolve, compare the exact `s=` and `d=` values with the sender's generated settings and the authoritative DNS zone. Do not create a new key just to make a lookup return something: a working DKIM signer also needs the matching private key. For a focused missing-record workflow, see [why a DKIM checker says no record found](/learning/no-dkim-record-found). If the record resolves but a message still fails, move to message evidence rather than changing DNS blindly. The [DKIM record-check workflow](/learning/check-dkim-record) explains that distinction, and the [DKIM alignment guide](/learning/why-does-my-dkim-signature-fail-alignment) covers the separate case where DKIM can pass but DMARC does not align. For the protocol background, read [what DKIM is](/learning/what-is-dkim). ## Check the selector without the terminal If you have the selector and signing domain but need a browser-based public-DNS check, use Palisade's [DKIM checker](/tools/dkim) after the command result. Its [public tool page](https://www.palisade.email/tools/dkim) describes a public DKIM lookup. It cannot validate an unseen message, access a private key, change DNS, or control a receiver's DKIM verdict. ## Sources and further reading - [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8601: Authentication-Results](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 1034: Domain names and concepts](https://www.rfc-editor.org/rfc/rfc1034.html) - [Cisco: Use dig or nslookup to find SPF, DKIM, and DMARC records](https://www.cisco.com/c/en/us/support/docs/security/secure-email-gateway/217073-how-to-use-dig-nslookup-to-find-spf-dki.pdf) - [DNSimple: What is a DKIM record?](https://support.dnsimple.com/articles/dkim-record/) ## Frequently asked questions ### Where do I find the DKIM selector? Find it in the `s=` tag of a delivered message's `DKIM-Signature` header or in the sending provider's generated DKIM settings. A DNS lookup cannot reliably enumerate every selector a domain might use. ### Why does dig show a CNAME instead of a DKIM key? A CNAME can delegate the selector to another DNS name, often operated by the sending service. Query the returned target for TXT and confirm that its answer contains usable DKIM key material before treating the lookup path as complete. ### Does a public DKIM record mean DKIM passes? No. A public record establishes that a key is published at the queried DNS name. A pass also depends on a message being signed with the matching private key and surviving verification by the receiver. ### What does an empty p= value mean? An empty `p=` value means the DKIM key is revoked. It is not usable public key material, so a verifier cannot use it to verify a signature. Check the sender's current selector and its published key before replacing DNS records. ### What does no answer mean for a DKIM dig lookup? It means the exact selector-scoped name did not return usable key material to that query. Recheck the selector, signing domain, authoritative DNS zone, and any CNAME delegation before concluding that DKIM is absent.