DKIM record inspector

How to make the most of the DKIM inspector

Gather the selector and From domain before launching the analysis. The tool transforms them into selector._domainkey.domain and lets you choose the resolver or DNS-over-HTTPS endpoint.

Prepare the fields

Enter the selector exactly as published - case matters - and the sending domain without _domainkey suffix. The inspector assembles them into {selector}._domainkey.{domain} before issuing the query.

Switch selectors with confidence

Test each selector during a key rotation or deliverability investigation. Alternate between available resolvers (public, custom or DoH) to verify the TXT is propagated everywhere before updating your MTA.

Interpret DKIM diagnostics

Errors signal missing TXT, invalid syntax or mismatch between public key and policy. Warnings highlight weaker parameters or test mode. Use resolver, latency and DoH details to distinguish configuration from propagation.

Why use this DKIM inspector?

Check before sending that your DKIM public key is published correctly.
The tool resolves selector._domainkey.domain, follows any CNAME, reads the returned TXT and highlights syntax errors, keys too short or revoked and inconsistent tags. You save time and avoid failed attempts in production.

DKIM in brief

DKIM signs the message with a private key. The recipient verifies the signature with the public key published in DNS. This key lives in a TXT record at selector._domainkey.domain. Important tags are:

v=DKIM1 version
k= key type rsa or ed25519
p= public key in Base64
t= test flags y or restriction s
n= optional note
g= historical granularity rarely used
s= optional services

Instructions

Enter the domain and selector to check.
Click Inspect record.
Read the summary then the details. Errors block verification on recipient side. Warnings signal risk or practice to improve.
Correct then run another check.

What the inspector checks

DNS resolution

Existence of selector._domainkey.domain as TXT.
CNAME chain followed to final TXT.
Readable TTL and total response size.

TXT syntax

Presence of v=DKIM1.
Consistent k= rsa or ed25519.
p= non-empty and valid in Base64. Empty p= = revoked key.
Unknown or duplicate tags reported.
Fragmented strings accepted and reassembled when zone splits into 255-character segments.

Public key

For RSA minimum length 1024 refused. Recommended 2048. Acceptable 3072. 4096 possible but watch DNS size.
For ed25519 compact format expected.
Detection of forbidden characters, stray spaces and incorrect quotes.
Fingerprint calculated to ease inventory.

Diagnostic aids

Presence of a DMARC record and reminder of expected alignment.
Notes on key age when TTL and history suggest it.
Rotation advice when multiple active selectors are visible.

Common errors

Misspelled selector key cannot be found.
Empty p= key revoked by mistake.
RSA 1024 key likely rejection by major platforms.
Non-Base64 characters broken copy-paste, typographic quotes.
Key too long or TXT badly segmented exceeding 255 characters per fragment.
CNAME to a name that does not publish final TXT.

Best practices

Publish at least two selectors and rotate regularly.
Prefer RSA 2048 or ed25519 depending on your ecosystem.
Keep TXT clean v k p and avoid exotic unnecessary tags.
Test DNS reading after each deployment then send test message and read Authentication-Results header.
Document selector date key size issuing service and responsible person.

Quick troubleshooting

Signature fail but key published verify selector used by sender. Selector name in DKIM-Signature header must match TXT.
Signature pass but DMARC fail review alignment between From and DKIM domain.
Some recipients ignore key verify there is only one useful TXT on final name.