LowAuthentication

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

Leave the selector blank and we will probe the selectors that common providers use.

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.

namegoogle._domainkey.example.comGoogle Workspace default selector
nameselector1._domainkey.example.comMicrosoft 365 publishes two, selector1 and selector2
nameresend._domainkey.example.comeach sending service adds its own
typeCNAME to the providerpreferred where offered: the provider can rotate the key without your involvement

How to fix it

Confirm your actual selector, and enable DKIM at every service that sends for you.

  1. Open a message you sent recently and look at the Authentication-Results or DKIM-Signature header. The s= value is your selector.
  2. 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.
  3. 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

  1. Publish the key at selector._domainkey.yourdomain.com, using a CNAME where the provider offers one.
  2. Enable signing in the sending platform. Publishing the DNS record does not by itself cause anything to be signed.
  3. 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.
  4. 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.