DKIM adds a cryptographic signature to outgoing mail, letting a receiving server verify two things at once: that the message genuinely came from a server authorized by the sending domain, and that it wasn't altered anywhere in transit. Unlike SPF, which is checked at one fixed location, DKIM is published per selector — and that one difference is what makes it impossible to check blind.
Why a Selector, Not a Fixed Location
A domain can sign mail with more than one key at once — different services (a marketing platform, a transactional mail provider, the domain owner's own servers) each signing independently, or a key rotation in progress with both the old and new key temporarily valid. The selector is what tells a receiving server which specific key to check, published as a TXT record at <selector>._domainkey.<domain>. Two different selectors are two entirely separate DNS lookups — there's no single "DKIM record" the way there's a single SPF record.
Finding the Right Selector
The selector isn't guessable from the domain name — it's chosen by whoever configured mail sending, and different providers default to different values (some use a fixed name like google or selector1; others generate one per account). The reliable way to find it is the source of an actual email from that domain: the DKIM-Signature header includes an s= tag naming the exact selector used to sign that message. Checking a domain without that header in hand means guessing among common conventions, which is why a "not found" result under a guessed selector doesn't confirm DKIM isn't configured — only that it isn't configured under that particular guess.
Reading the Result
- Key type — almost always RSA; some newer configurations use Ed25519.
- Public key present — the actual signing key material is published and usable for verification.
- Public key missing (empty p= tag) — a deliberately revoked or rotated key, not necessarily a mistake. Providers do this routinely when cycling keys; an empty
p=is the documented way to invalidate a selector without deleting the record outright.
What DKIM Doesn't Decide
A DKIM pass or fail is just one input — DKIM itself has no opinion on what a receiving server should do with a message that fails. That determination belongs to DMARC, which grades DKIM's (and SPF's) result against alignment with the visible sender and applies its own policy on top.
Frequently Asked Questions
I checked a common selector and got "not found" — does that mean DKIM isn't set up?
Not necessarily. It means DKIM isn't published under that specific selector — the domain could easily be signing under a different one. The only way to know for certain is the s= tag in a real email's DKIM-Signature header from that domain.
Why does my provider's DKIM key look empty or missing after I just set it up?
DNS propagation delay is the most common cause — a newly published record can take time to become visible everywhere. If it's been longer than expected, double check the exact selector the provider gave you; a typo in the selector name is the next most common cause.
Can I have multiple DKIM keys at once?
Yes, and it's normal — different selectors are independent, so a domain sending through several services (or mid-rotation between an old and new key) can have more than one valid DKIM key published simultaneously with no conflict.
Check a domain's DKIM key for a known selector with the DKIM Checker.