Free DKIM Lookup Tool
Query the live DKIM TXT record for any domain and selector. Instantly verify your DKIM key is published correctly and that receiving servers can find it.
How to Use This Tool
Enter your domain and selector
The selector is the label before ._domainkey — e.g. "mail", "s1", or "google". Your email provider will tell you what selector to use.
Review the live record
The tool queries {selector}._domainkey.yourdomain.com and returns the raw TXT record. Check that v=DKIM1 and the public key (p=) are present.
Fix any issues
If the record is missing, check your DNS provider published it at the correct host name. If the key looks wrong, regenerate via your email provider and re-publish.
What a DKIM Lookup Returns and How to Read It
A DKIM lookup retrieves the public key record published in DNS for a specific selector and domain. To perform the lookup, you need two pieces of information: the domain (from the From header) and the selector (from the `s=` field in the `DKIM-Signature` header of a signed message). The lookup queries the TXT record at `{selector}._domainkey.{domain}` and returns the raw record alongside a parsed view of each tag.
The most important field in the returned record is `p=`, which contains the base64-encoded RSA public key. This is the key that receiving servers use to verify message signatures. If `p=` is present and populated, the key is active. If `p=` is empty, the key has been deliberately revoked — this is the standard mechanism for invalidating a DKIM key without removing the DNS record entirely. A `k=` tag specifies the key type, almost universally `rsa`. The `t=y` flag indicates testing mode, where receivers should not use the DKIM result for filtering decisions; this flag should be removed once you have confirmed signing is working.
The `h=` tag, when present, restricts which hash algorithms are acceptable for this key. If your signing daemon uses a hash algorithm not listed in `h=`, verification fails. Understanding these tags allows you to diagnose verification failures that go beyond simple key mismatches.
How Selectors Work in the Lookup Context
The selector is the mechanism that makes DKIM extensible: a single domain can have multiple DKIM keys active simultaneously, each identified by a unique selector. ESPs use this to give each customer their own signing key, or to differentiate between marketing and transactional streams. When you rotate keys, you use a new selector for the replacement key while keeping the old selector active during the transition.
When you do not know your selector — a common situation when you inherit an email infrastructure or are debugging a new configuration — the fastest way to find it is to examine the raw headers of a recently sent message. Every DKIM-signed message includes a `DKIM-Signature` header with an `s=` tag whose value is the selector in use. Retrieve a test message from your mail client's full header view, locate the DKIM-Signature header, and read the `s=` value. Then supply that selector plus your domain to the lookup tool.
For ESPs that use CNAME-based DKIM, the lookup may follow a CNAME chain before returning the final public key. This is intentional: the CNAME points to the ESP's DNS infrastructure where they manage the actual TXT record. From a verification standpoint, this works identically to a direct TXT record — the receiving server follows the CNAME chain during resolution.
Common DKIM Lookup Failures and What They Mean
The most frequent DKIM lookup failure is a simple NXDOMAIN result: the record does not exist. This means either the selector was entered incorrectly, the record was never published, or it was deleted. Cross-check the selector against the `s=` tag in a recent message header. If they match and the record genuinely does not exist, you need to republish it.
DNS propagation lag causes a different class of failures. After publishing a new DKIM record, there is a window — typically minutes but potentially up to an hour depending on TTL — where some resolvers still return NXDOMAIN while others have the new record. If you see inconsistent results across different resolvers immediately after publishing, wait for propagation to complete before concluding the record is missing. Check the authoritative nameserver directly to confirm the record was saved.
An empty `p=` field is a deliberate failure state. It means the domain owner has revoked the key, and any DKIM signature using that selector must be treated as invalid. This is sometimes found on old selectors left in DNS after a key rotation. If you are seeing DKIM failures traced to an empty `p=`, you need to either restore the key or update your mail server to sign with a different, active selector.
Verifying DKIM After Configuration Changes
After any DKIM configuration change — publishing a new key, changing selectors, switching ESPs, or rotating keys — a lookup is the immediate next step. Do not assume the change worked; confirm it. The lookup verifies that the DNS record is accessible, syntactically correct, and contains a non-empty public key. Then, send a test message through your full sending path and examine the headers to confirm the `DKIM-Signature` header is present and that the `s=` and `d=` values match your published record.
Header inspection tools provided by inbox providers are also valuable here. Gmail's 'Show Original' view includes a DKIM pass/fail result alongside the full headers. Microsoft's Outlook header analyser and Yahoo's header display similarly decode authentication results. These provider-side verifications are the ground truth — they show how the actual inbox provider evaluated the message, not just whether the DNS record is technically correct.
For ongoing monitoring rather than one-time verification, DMARC aggregate reports are the systematic tool. They provide daily summaries of DKIM pass and fail rates across all receiving domains that implement DMARC reporting. A sudden drop in DKIM pass rate visible in aggregate reports — without any deliberate change — typically indicates a configuration regression, a key expiry, or a sending path change that bypassed the DKIM signing infrastructure.
Key Features
Selector and Domain Lookup
Enter any selector and domain to retrieve the live DKIM TXT record from authoritative DNS.
Public Key Decoded
Decodes the p= base64 key and displays key length and type so you can confirm 2048-bit compliance.
Revoked Key Detection
Clearly flags records with an empty p= field and explains that this means the key has been revoked.
CNAME Chain Resolution
Follows CNAME redirects used by ESP-managed DKIM and shows the full resolution path.
Testing Mode Warning
Detects t=y in the returned record and warns that receivers may be ignoring DKIM results.
Selector Discovery Guide
Explains how to find your selector by reading the DKIM-Signature header from a real sent message.
Frequently Asked Questions
Related Tools
Continue your email deliverability setup with these free tools.
Tools Are Just the Start
Once your domain is set up, mailtani handles sending, warmup, sequences, and rotation.
See How mailtani Compares
Never Lose Track of Your Authentication
mailtani monitors DKIM, SPF, and DMARC across all your sending domains and alerts you when something breaks — all included at a one-time price.
- DKIM monitoring across all domains
- Key rotation alerts
- Inbox warmup & rotation
- One-time price
14-day free trial · €89 lifetime access after