Check a DKIM TXT record for a domain and selector, or scan common selectors if you don't know yours.
DKIM (DomainKeys Identified Mail) publishes a public key as a TXT record at selector._domainkey.yourdomain.com, where the selector is chosen by whoever configured your mail sending service. Enter your domain and selector above to confirm the key is published correctly - a missing or malformed DKIM record means receiving servers can't verify your messages were actually signed by you.
DKIM works together with SPF and DMARC. Understand how the three combine to protect your domain from spoofing.
Read the Email DNS WikiDKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail so receivers can verify a message was not altered in transit and genuinely came from a server authorized by your domain. The public key lives in DNS at selector._domainkey.yourdomain, where the selector is a short label chosen by whoever configured your mail platform (Google, Microsoft 365, an ESP, or your own mail server). Because the selector is not standardized, this checker either looks up a selector you provide or scans a list of common selector names when you do not know yours.
A DKIM record existing in DNS does not always mean it is active. A record with an empty p= tag is an explicitly revoked key per RFC 6376 and must be treated as failing, even though the TXT record itself resolves fine. Rotating selectors is also normal practice, so having more than one selector with a valid key is expected, not an error.
If you need related checks, try Email DNS check lookup and Email deliverability score check tool.
It is inconclusive, not necessarily a failure. Selectors are chosen freely by whoever configured DKIM, so a scan of common names (google, default, selector1, and similar) can miss a custom one. Check your mail provider dashboard for the exact selector and enter it directly.
A TXT record with p= followed by nothing (an empty value) is a deliberately revoked key. Receivers must treat it as invalid. This usually happens after a key rotation where the old selector was intentionally disabled rather than deleted.
Yes, and it is common. Providers rotate keys by publishing a new selector while the old one is still valid, then retire the old one later. Multiple working selectors is normal, not a misconfiguration.
No. DKIM only proves a message was signed by a key you published; it does not by itself tell receivers what to do with unsigned or failing mail. That enforcement decision is DMARC's job, which is why DKIM, SPF, and DMARC are normally checked together.
Each sending platform (your inbox provider, a marketing tool, a transactional email API) typically signs with its own key and selector. You need a valid DKIM record for every service that legitimately sends mail on your behalf, not just your primary inbox provider.
DKIM keys are published as a TXT record. Some providers also support a CNAME pointing to a key they host, which resolves to the same effective TXT content.