DKIM failures tend to show up only in DMARC reports or in a provider's postmaster dashboard: messages are signed, but receivers cannot find or use the key. The usual reasons are a selector published under the wrong name, a key truncated by a DNS panel that does not handle long TXT values, a 1024-bit key that receivers now treat as weak, or a record left revoked after a rotation.
The DKIM Lookup fetches the TXT record at <selector>._domainkey.<domain>, decodes the public key and reports its type and size, flags revoked keys and test mode, and lists every tag of the record. Use it after setting up a new sending service, after rotating keys, and whenever DMARC reports show dkim=fail for a source you trust.
What is DKIM?
In simple terms
DKIM (DomainKeys Identified Mail) is a tamper seal for email. The sending server signs selected headers and the body with a private key. The matching public key is published in DNS. A receiver fetches that key and checks the seal; if the message was altered on the way or signed with a different key, the check fails. Because the signature travels with the message, it survives forwarding, unlike SPF.
Technical background
DKIM is defined in RFC 6376. The signer adds a DKIM-Signature header with tags such as:
d=the signing domain, ands=the selector;a=the algorithm (rsa-sha256, ored25519-sha256from RFC 8463);h=the signed header fields,bh=the body hash andb=the signature.
The verifier queries the TXT record at s._domainkey.d, for example sel2026._domainkey.example.com. That record uses tag=value pairs:
v=DKIM1(optional, but if present must be first and exactly this value);k=key type,rsaby default ored25519;p=the base64 public key (empty means revoked);t=flags, whereymeans testing mode andsrestricts the key to the exact domain;- optionally
h=acceptable hash algorithms ands=service type.
RSA keys of 2048 bits produce a p= value longer than 255 characters, so the TXT record has to be split into several strings that receivers join. RFC 8301 requires at least 1024-bit RSA keys for verification.
Command-line equivalent: dig TXT sel2026._domainkey.example.com +short.
Why use a DKIM lookup?
- Confirm a new sending service is ready before switching it on.
- Check key strength: find 1024-bit keys that should be rotated to 2048 bits.
- Detect truncated or corrupted keys: a
p=value that does not decode is reported as an error. - Verify a rotation: the new selector has a key, the old one is revoked or removed.
- Explain DMARC failures where DKIM is the only aligned mechanism for forwarded mail.
Who should use it?
- Mail administrators running their own signing (OpenDKIM, rspamd, Exchange connectors).
- DNS administrators publishing keys provided by SaaS senders.
- Security and deliverability engineers preparing a DMARC enforcement rollout.
- MSPs auditing customer domains.
How DKIM lookup works
During verification a receiver reads d= and s= from the signature, fetches the key from DNS, and verifies the signature with it. The NetTools.tech DKIM Lookup performs the DNS and key analysis part:
- The domain is validated (public names only) and the selector is checked: letters, digits, hyphens and underscores, optionally several dot-separated labels.
- The NetTools.tech server queries the public resolvers 1.1.1.1 and 8.8.8.8 for a CNAME at
<selector>._domainkey.<domain>(shown if present), then for the TXT record at that name. - TXT strings are joined. Only TXT values that look like a DKIM key record (containing
v=DKIM1,p=ork=) are considered. - The tags are parsed. The
p=value is base64-decoded: for RSA the key is parsed as a public key to read its modulus length; fork=ed25519the 32-byte key is recognized as a 256-bit Ed25519 key. - Findings are produced for a missing key, a missing or empty
p=, an undecodable key, short RSA keys, an unknown version andt=ytest mode.
The operation has a 12-second time limit and normal per-client rate limits.
How to use the NetTools.tech DKIM Lookup
- Find the selector: open a message from the domain, view its headers and read
s=in theDKIM-Signatureheader, or paste the headers into the Email Header Analyzer. - Open DKIM Lookup.
- Enter the domain (the
d=value) in Domain, for exampleexample.com. - Enter the selector in Selector, for example
selector1. Enter only the selector, not the fullselector1._domainkey.example.comname. - Press Run DKIM Lookup, or use the example chip.
- Read the Name, CNAME and Key rows, the findings, and expand Record tags for details. Open in terminal runs
/dkim example.com selector1in the web terminal.
Understanding the results
| Result | Meaning | What to look for |
|---|---|---|
| Name | The DNS name queried, <selector>._domainkey.<domain> | That it matches s= and d= from the signature |
| CNAME | Alias target, if the selector is delegated | The provider's documented target |
| Key | Key type and size, e.g. "RSA 2048 bits" | "—" means no usable key |
| "RSA/ED25519 N-bit key." (pass) | A usable key of adequate size | — |
| "2048 bits is recommended" (warning) | RSA key between 1024 and 2047 bits | Plan a rotation to 2048 bits |
| "too short" (error) | RSA key under 1024 bits | Receivers may ignore it; rotate now |
| "p= is empty: this key has been revoked" (warning) | Revoked key | Expected for retired selectors only |
| "The public key could not be decoded" (error) | p= is not a valid key | Truncation, stray quotes or spaces inside the value |
| "The required p= tag is missing" (error) | A DKIM-like record without a key | Incomplete record |
| "No DKIM key found for this selector" (error) | No DKIM TXT record at that name | Wrong selector, wrong domain, or not published yet |
| "Unknown version" (error) | v= other than DKIM1 | Fix the version tag |
| "t=y: test mode" (info) | Receivers may treat failures as passes | Remove t=y once signing works |
| Record tags | Every tag and value (long values shortened) | k=, t=, h=, and the start of p= |
Example: checking a 2048-bit RSA key
Illustrative result for a hypothetical domain example.com with selector sel2026:
| Field | Value |
|---|---|
| Name | sel2026._domainkey.example.com |
| Key | RSA 2048 bits |
Finding: "RSA 2048-bit key." (pass)
Record tags:
| Tag | Value |
|---|---|
| v | DKIM1 |
| k | rsa |
| p | MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA… (shortened) |
If the same lookup returned "RSA 1024-bit key: 2048 bits is recommended.", the signing setup works, but you should generate a new 2048-bit key under a new selector (for example with the DKIM Record Generator or your provider's console), publish it, switch signing to it, and revoke the old selector later.
Common use cases
- Verifying the DNS records a hosted mail or marketing provider asked you to publish.
- Checking selectors found in DMARC aggregate reports or message headers.
- Planning a rotation from 1024-bit to 2048-bit RSA keys.
- Confirming that an old selector is revoked after a provider change.
- Including DKIM in a domain report with the Email Health Check by passing the selector there.
Troubleshooting
"No DKIM key found for this selector"
Check the selector spelling and the domain: the key must be at s._domainkey.d using the d= domain from the signature, which may be a subdomain. Some DNS panels append the zone automatically, so entering sel._domainkey.example.com as host creates sel._domainkey.example.com.example.com. Also make sure the record is published as TXT (or a CNAME the provider documents).
"The public key could not be decoded"
The p= value was damaged. Common causes: the panel truncated the value at 255 characters, line breaks or quotes ended up inside the key, or part of the key was lost when copying. Republish the value exactly as generated, split into multiple strings if your DNS provider requires it.
The key is found but DKIM still fails
The key is fine, so look at the signature: check the message's Authentication-Results with the Email Header Analyzer. Typical causes are a signature made with a different key than the one published, or a gateway that modifies the message (footers, rewritten links) after signing.
The lookup times out or reports SERVFAIL
The domain's name servers did not answer. Check them directly with dig @ns1.example.com TXT sel2026._domainkey.example.com.
Common mistakes
- Entering the full
selector._domainkey.domainname in the Selector field. - Looking up the visible From domain when the signature uses a different
d=domain. - Publishing the private key instead of the public key.
- Leaving
t=yin place permanently. - Keeping 1024-bit keys for years without rotation.
- Deleting the old selector immediately after rotation, which breaks verification of messages still in transit.
Limitations
- Selectors cannot be discovered from DNS; you must supply the right one.
- The tool checks the published key only. It does not verify a message signature or check body and header canonicalization.
- RSA key sizes are read from the decoded key. For Ed25519 only the 32-byte length is checked.
- Optional tags such as
h=,s=andt=sare listed but not evaluated. - DNS answers come from 1.1.1.1 and 8.8.8.8 and may be cached.
Security & privacy
The domain and selector are sent to the NetTools.tech server, which queries public resolvers. Only public names are accepted, results are not stored, and the tool log keeps the tool name, the target and your shortened IP address for 30 days (see the privacy policy). A DKIM lookup only needs public DNS data: never paste a DKIM private key into any web form, including this one.
Related tools
- DKIM Record Generator – generate a key pair and the TXT record in your browser (guide).
- Email Header Analyzer – find selectors and see DKIM results of real messages (guide).
- DMARC Lookup – check the policy that uses DKIM alignment (guide).
- SPF Lookup – the other authentication mechanism DMARC relies on (guide).
- Email Health Check – all core checks in one report (guide).
Summary
DKIM lets receivers verify that a message really comes from the signing domain and was not altered, but only if the public key is published correctly under the right selector. The NetTools.tech DKIM Lookup fetches that key, decodes it, reports type and size, and flags revoked, weak, malformed and test-mode keys. It checks DNS, not individual messages; use the Email Header Analyzer to see how a real signature was evaluated.
Frequently asked questions
What is a DKIM record?
A DKIM record is a DNS TXT record at selector._domainkey.domain that publishes the public key receivers use to verify a message's DKIM signature. It normally contains v=DKIM1, the key type in k= and the base64-encoded key in p=.
How do I find my DKIM selector?
Open the headers of a message sent from the domain and look at the DKIM-Signature header: s= is the selector and d= the signing domain. The NetTools.tech Email Header Analyzer lists both for every signature it finds.
Why can't the tool find my DKIM key automatically?
DNS offers no way to list the names under _domainkey, so a selector cannot be discovered from DNS. You need the exact selector from a signed message or from your mail provider's settings.
What key length should I use?
2048-bit RSA is the common recommendation. The NetTools.tech lookup warns about RSA keys under 2048 bits and reports keys under 1024 bits as an error, because many receivers ignore them.
What does an empty p= mean?
An empty p= tag means the key has been revoked, as defined in RFC 6376. Signatures made with that selector will fail verification, which is the intended result after a key rotation.
Is a CNAME at the selector name a problem?
No. Hosted providers often ask you to publish the selector as a CNAME pointing to a key they manage, so they can rotate it. The lookup shows the CNAME target and evaluates the TXT record that the name resolves to.
Does the DKIM lookup verify that my messages are signed correctly?
No. It checks that a usable public key is published for the selector. Whether a specific message's signature verifies is shown in that message's Authentication-Results header, which you can read with the Email Header Analyzer.