No DKIM key found at the selectors we checked
No DKIM key was found at the selectors checked, so messages from this domain carry no cryptographic signature a receiver can verify. DKIM is the only authentication method that survives forwarding intact, which makes its absence more consequential than it first appears: mail forwarded through a mailing list or an alias arrives with SPF broken and, without DKIM, nothing left to pass DMARC on.
Check your own domainDKIM checker
What causes this
DKIM keys live at selector._domainkey.yourdomain.com, and the selector name is chosen by whoever set up signing. There is no way to list the selectors a domain uses (DNS does not support enumeration), so any checker can only probe names it already knows about. We check the selectors published by the major mailbox and sending providers. Finding none does not prove DKIM is absent; it means DKIM is not present at any selector we know to look for.
What it breaks
If DKIM genuinely is not configured, your mail can only satisfy DMARC through SPF, which breaks whenever a message is forwarded. If DKIM is configured at a selector we do not know, there is no problem. Check a message header to confirm.
What the receiving server does
A receiver reads the DKIM-Signature header of an incoming message, takes the selector and domain from it, and fetches the public key from selector._domainkey.yourdomain.com. Absent a signature header there is nothing to look up and the result is none. Where a signature exists but the key does not resolve, the result is a permanent failure. The distinction matters for diagnosis: no signature means the sending platform is not signing, while a signature with no key means it is signing but the DNS record was never published or was published at the wrong name.
Where the key lives
The selector is chosen by whatever signs the mail, and each sending platform uses its own. The record name is always the selector, then _domainkey, then your domain. Most platforms publish it as a CNAME pointing at a key they rotate for you, which is preferable to a TXT record you have to maintain by hand.
How to fix it
Confirm your actual selector, and enable DKIM at every service that sends for you.
- Open a message you sent recently and look at the Authentication-Results or DKIM-Signature header. The s= value is your selector.
- If a selector is present there, DKIM is working and this finding can be ignored. Enter the selector in the DKIM checker to verify it directly.
- If no DKIM-Signature header exists, enable DKIM in each sending service's admin console and publish the record it gives you.
If you send with
- Google Workspace
- DKIM is not enabled by default. Generate the key in the Admin console under Apps, Google Workspace, Gmail, Authenticate email, publish the TXT record it produces, then return and press Start authentication. Skipping that final step is the usual reason a correctly published record still yields no signature.
- Microsoft 365
- Publish both CNAMEs (selector1 and selector2), then enable signing for the domain in the Defender portal. Microsoft rotates between the two selectors, so publishing only one leaves signing broken half the time and produces intermittent failures that are hard to attribute.
- Marketing and transactional senders
- Every service that sends as your domain needs its own selector and key. A domain can carry any number of DKIM records, because each is on a distinct selector name. This is not like SPF, where only one record is permitted.
Confirming the fix worked
- Publish the key at selector._domainkey.yourdomain.com, using a CNAME where the provider offers one.
- Enable signing in the sending platform. Publishing the DNS record does not by itself cause anything to be signed.
- Send a message to an address you control elsewhere and check the headers for a DKIM-Signature line and an Authentication-Results line showing dkim=pass.
- Confirm the d= value in the signature matches your domain, since a signature that verifies against the provider's domain will not align for DMARC.
Common questions
- Can I have more than one DKIM record?
- Yes, and most domains should. Each sending service uses its own selector, and each selector is a separate DNS name, so they do not conflict. This is the opposite of SPF, where exactly one record is allowed.
- Why did you check those particular selectors?
- Selectors are chosen by the signer and cannot be enumerated from DNS, so there is no way to list them. We probe the defaults used by the major platforms. If your provider uses a custom selector, supply it and we will check that name directly.
- Is DKIM more important than SPF?
- They fail in different situations, and DKIM fails in fewer. SPF breaks when mail is forwarded, because the forwarding server is not in your record. A DKIM signature travels with the message and still verifies, which is why DKIM is usually what keeps DMARC passing for forwarded mail.
- What does alignment mean for DKIM?
- DMARC requires that the domain in the signature's d= tag matches the domain in the visible From: address. A provider signing with its own domain produces a valid signature that does not align, so DMARC still fails. Signing must happen with your domain.