How to Check DKIM Records Using dig and nslookup

Sometimes you need to check a DKIM (DomainKeys Identified Mail) record at the DNS level. Maybe you are debugging why a newly added record is not showing up, maybe you are scripting automated checks, or maybe you just prefer working in the terminal. The command-line tools dig and nslookup can query DKIM records directly from DNS, and knowing how to use them is a valuable skill for anyone managing email authentication.

The Basic DKIM DNS Query

Every DKIM public key is stored as a TXT record (or a CNAME that points to one) at a predictable DNS address:

[selector]._domainkey.[domain]

You need two pieces of information: the selector (which identifies which key to use) and the domain (the sending domain). For example, Google Workspace typically uses the selector google, so the lookup address for example.com would be:

google._domainkey.example.com

If you do not know your selector, check your email service's admin panel or examine the s= value in the DKIM-Signature header of a sent email. Our guide on DKIM selectors explained lists the common selectors for every major provider.

Using dig

The dig command is available on macOS and Linux by default, and on Windows through WSL or the BIND utilities package. It is the most widely used DNS lookup tool among system administrators.

Basic DKIM lookup

dig TXT google._domainkey.example.com

This queries the TXT record and returns the full DNS response, including the answer section, authority section, and query metadata.

Short output

If you just want the record value without all the extra information:

dig +short TXT google._domainkey.example.com

Output:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

This is much cleaner for quick checks.

Check a specific nameserver

To see what a particular DNS resolver returns (useful for checking propagation):

dig @8.8.8.8 TXT google._domainkey.example.com

This queries Google's public resolver directly. You can also check Cloudflare's resolver at 1.1.1.1.

Check the authoritative nameserver

To see what your own DNS provider has without waiting for propagation:

dig NS example.com +short

This gives you your nameservers. Then query one directly:

dig @ns1.yourprovider.com TXT google._domainkey.example.com +short

If the record appears here but not on public resolvers, propagation is still in progress.

Check for CNAME records

Some email services use CNAME records instead of TXT. To check explicitly:

dig CNAME selector1._domainkey.example.com +short

Note that dig TXT will usually follow CNAME chains automatically, so a TXT query often works even when the record is a CNAME. But if you get an empty response on TXT, try CNAME separately.

Using nslookup

The nslookup command is available on Windows, macOS, and Linux. It is the default choice on Windows systems where dig is not installed.

Basic DKIM lookup

nslookup -type=TXT google._domainkey.example.com

This returns the TXT record along with server information.

Specify a DNS server

nslookup -type=TXT google._domainkey.example.com 8.8.8.8

The server address goes at the end. This works the same way as the @ syntax in dig, useful for checking propagation against different resolvers.

Check for CNAME records

nslookup -type=CNAME selector1._domainkey.example.com

Replace -type=TXT with -type=CNAME to look specifically for CNAME records.

Reading the Output

When your lookup returns a DKIM record, the TXT value contains several tags separated by semicolons. Here is what each one means:

The p= tag is the most important. It contains the actual public key that receiving servers use to verify signatures. If p= is empty (just p= with nothing after it), the key has been revoked and DKIM verification will fail for any email using that selector.

Common Scenarios

Checking DNS propagation after adding a record

You just added a DKIM record and want to know if it is live. Query your authoritative nameserver first, then a public resolver:

dig @ns1.yourprovider.com TXT google._domainkey.example.com +short
dig @8.8.8.8 TXT google._domainkey.example.com +short

If the first returns the record but the second does not, the record exists at your provider but has not propagated globally yet. Wait and try again in 15 to 30 minutes.

Verifying a record exists before enabling signing

Before you flip the switch to enable DKIM signing in your email service, confirm the public key is reachable:

dig TXT selector._domainkey.yourdomain.com +short

If you get a result starting with v=DKIM1, you are safe to enable signing. If not, do not enable it yet or your emails will fail DKIM.

Debugging different results from different nameservers

When you get inconsistent results, check multiple resolvers to narrow down the issue:

dig @8.8.8.8 TXT selector._domainkey.example.com +short
dig @1.1.1.1 TXT selector._domainkey.example.com +short
dig @9.9.9.9 TXT selector._domainkey.example.com +short

If all public resolvers agree but your local resolver disagrees, your local DNS cache may be stale. Flushing the local cache or waiting for the TTL to expire will resolve it.

When to Use Command Line vs a DKIM Checker

Command-line tools and dedicated DKIM checkers serve different purposes. Here is when to use each:

Use dig or nslookup when:

• You are checking whether a record has propagated to a specific nameserver
• You are scripting or automating DNS checks in a CI/CD pipeline
• You need to compare results across multiple resolvers quickly
• You are debugging DNS infrastructure issues (SERVFAIL, NXDOMAIN, etc.)

Use a DKIM checker tool when:

• You want to validate the key is well-formed and the correct length
• You need to parse individual DKIM tags and understand what they mean
• You want key strength analysis (1024-bit vs 2048-bit)
• You want ongoing monitoring and alerts when records change or disappear

Command-line tools tell you whether a record exists. A DKIM checker tells you whether it is correct, secure, and complete.

If you need to create a DKIM record from scratch, dkimcreator.com can generate a key pair with your chosen selector and key size. For checking your complete email authentication setup, test your SPF record and DMARC policy as well. And for continuous monitoring of all your DNS-based email records, deliverabilitychecker.com runs daily checks and sends alerts when anything breaks.

Monitor Your DKIM Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.