DKIM records, selectors and key analysis

1. DKIM Records Detected overview

This row in your DNSprobe report confirms whether any DKIM records were found for the tested selectors and shows their details in a compact list.

Why DKIM matters

DKIM is one of the two main signals used by DMARC. Without valid DKIM signatures, many receiving systems will treat messages from your domain as less trustworthy, especially when combined with strict DMARC policies.

How to read this block

For each selector, you see the hostname (selector._domainkey.example.com), the DKIM record, the provider label when known and a short Key Analysis. At the bottom of the block DNSprobe displays the DKIM Evaluation Score and a one-line verdict.

Best practices at a glance

• Ensure that every mail system you use publishes at least one working DKIM selector.
• Use different selectors for different providers or servers so you can rotate keys independently.
• Keep a list of live selectors and remove old ones when systems are decommissioned.

2. DKIM selectors and hostnames

A selector is the first part of the DKIM DNS name. It allows multiple keys to coexist for the same domain and makes it possible to rotate keys without downtime.

Why selectors are important

Selectors let you run separate keys for different mail servers, applications or third-party providers. This avoids sharing the same private key everywhere and simplifies key rotation.

How DNSprobe displays selectors

For each selector that responds, DNSprobe prints the selector name, the full hostname under _domainkey and, when it recognises it, a label indicating the platform (for example DirectAdmin, Mailchimp, etc.).

Best practices for selectors

• Use descriptive selector names that help you remember which system they belong to (for example mail2025, mcsv1).
• Avoid reusing the same selector across unrelated systems; rotate selectors when changing providers.
• Document which selectors are active and which can safely be removed.

3. DKIM key records (TXT and CNAME)

A DKIM record typically looks like v=DKIM1; k=rsa; p=… and contains the public key used to verify signatures. Some providers instead publish a CNAME pointing to a key they host themselves.

Why key records matter

If the key record is missing, malformed or points to the wrong place, recipients cannot verify your DKIM signatures and may treat messages as unauthenticated.

How DNSprobe shows DKIM keys

In the DKIM section, each selector entry includes the raw DKIM TXT value or CNAME target so that you can compare it to the configuration provided by your hosting control panel or e-mail provider.

Best practices for DKIM records

• Always include the v=DKIM1 and k=rsa (or k=ed25519 when supported) tags in your TXT records.
• If a provider asks you to create a CNAME for DKIM, copy the target exactly as given and avoid altering the hostname.
• Do not publish private keys in DNS; only the public key belongs in the DKIM record.

4. Key Analysis: length and algorithm

Under each key, DNSprobe runs a basic Key Analysis that focuses on key length and algorithm to highlight obviously weak or outdated keys.

Why key strength matters

Short or obsolete keys can be broken more easily, weakening the security guarantees offered by DKIM. Many providers are gradually deprecating 1024-bit RSA keys in favour of 2048 bits or more.

How DNSprobe evaluates key strength

DNSprobe parses the public key from the p= tag or from the provider’s target, calculates its size in bits and identifies the algorithm (for example RSA). It then labels the key length as good or weak based on current recommendations.

Best practices for DKIM key management

• Use at least 2048-bit RSA keys whenever possible, or modern algorithms such as ed25519 where supported.
• Rotate DKIM keys periodically by introducing a new selector and retiring the old one after a safe overlap period.
• Ensure that all active keys meet your organisation’s security policies and compliance requirements.

5. DKIM Evaluation Score and verdict

At the bottom of the DKIM section, DNSprobe displays a DKIM Evaluation Score and a short sentence such as “DKIM is properly configured.”

What the score tells you

The score summarises whether valid DKIM keys were found, whether their length is considered sufficient and whether the overall configuration is coherent.

How DNSprobe computes the score

The score takes into account the presence of at least one usable key, the strength of the keys that were detected and any obvious misconfigurations. Custom selectors that are not tested may still exist outside of this view.

How to use the DKIM score

• Use a perfect score as confirmation that your core DKIM setup looks healthy from the outside.
• If the score is lower than expected, review the individual selectors and keys shown in the section to identify which ones need attention.
• Combine the DKIM score with DMARC and SPF analysis for a complete view of your e-mail authentication posture.

6. Test DKIM records manually from your own terminal

The DKIM section in DNSprobe looks up TXT records on selector._domainkey.yourdomain to verify that your public keys are published correctly. Each mail system uses one or more selectors (for example selector1 or default). You can inspect the raw DKIM records yourself from a terminal by querying the TXT record for each selector.

Linux: using dig (BIND utilities)

On most Linux distributions, the dig command is provided by the BIND utilities package. The examples below show how to query the DKIM TXT record for a selector and, if you use multiple selectors, how to check each one:

                dig selector1._domainkey.example.com TXT
                dig selector1._domainkey.example.com TXT +short
    
                # If you rotate keys or use multiple mail systems, repeat the query for each selector (selector2, default, mail, etc.)    
                dig selector2._domainkey.example.com TXT +short
    
                # Optional: filter the output to show only the line that starts with v=DKIM1 for easier inspection    
                dig selector1._domainkey.example.com TXT | grep "v=DKIM1"
        

macOS: using dig from the built-in tools

macOS ships with dig as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to list the DKIM TXT record for each selector used by your mail provider:

                dig selector1._domainkey.example.com TXT
                dig selector1._domainkey.example.com TXT +short
    
                # If you rotate keys or use multiple mail systems, repeat the query for each selector (selector2, default, mail, etc.)    
                dig selector2._domainkey.example.com TXT +short
    
                # Optional: filter the output to show only the line that starts with v=DKIM1 for easier inspection    
                dig selector1._domainkey.example.com TXT | grep "v=DKIM1"
        

Windows: using nslookup

On Windows, the legacy nslookup tool can query TXT records on selector._domainkey.yourdomain. From a Command Prompt or PowerShell window, you can retrieve the DKIM record for each selector configured on your mail service:

                nslookup -type=TXT selector1._domainkey.example.com
    
                REM Repeat the query for any additional selectors configured on your mail provider (selector2, default, mail, etc.)    
                nslookup -type=TXT selector2._domainkey.example.com
        

Important: only query DKIM records for domains that you own or are authorised to analyse. Repeated automated lookups against third-party domains without permission may be treated as abusive traffic by some providers.