DKIM Key Not Found: What This Site AI Audit Notice Means

Short answer: The finding “No DKIM key found at common selectors” is a notice in the e-mail area of a Site AI Audit report. It appears when your domain receives mail but the audit cannot find a DKIM public key in DNS at any of the commonly used selector names. It does not always mean that DKIM is missing, because your provider may use a selector the audit did not try. Check with your mail provider, and if DKIM is off, turn on signing and publish the key.

What DKIM does

DKIM stands for DomainKeys Identified Mail. When your mail system sends a message, it adds a digital signature to the headers, made with a private key that only your mail system has. The matching public key is published in your DNS. The receiving server looks up the public key, checks the signature and learns two things: the message really passed through a system authorised by your domain, and nobody changed it on the way.

This is one of three proofs that work together. SPF lists the servers that may send for your domain, DKIM signs the message itself and DMARC decides what happens when the proofs fail. Mail with a valid DKIM signature is trusted more and is less likely to be filtered as spam. The article on the e-mail checks in the audit shows how the three fit together.

How the audit looks for a key

The audit cannot read your mail system. It can only look in public DNS. A DKIM key is published as a TXT record at a name made from a selector, then “._domainkey”, then your domain. The selector is chosen by whoever set up the signing: “google” for Google Workspace in some setups, “selector1” and “selector2” for Microsoft 365, “default” for many hosting panels, and so on. There is no list of selectors in DNS, so the audit tries a list of common names, including default, google, selector1, selector2, k1, k2, mail, dkim, s1, s2, smtp, zoho, mailjet, sendgrid and amazonses, and looks for a record that holds a public key.

The finding appears only when the domain has an MX record, meaning it receives mail, and none of the common selectors returned a key. If the domain has no MX record at all, the audit raises a different notice about the domain not receiving e-mail.

What the finding says

The notice reads: “No DKIM key found at common selectors”. The explanation is that DKIM signs your e-mails so receivers can verify them, and that without it more mail lands in spam. A sentence in brackets gives the honest caveat: your provider may use a selector the audit did not check. The advice is to enable DKIM signing in your mail service and publish its public key in DNS.

The severity is a notice, the lowest level, for a good reason. The audit can say that it found no key, but it cannot say that no key exists. That is why this guide starts with the question you should answer before changing anything: is DKIM really off?

Step 1: find out whether DKIM is already on

There are three quick ways to find out:

Look in your mail provider’s settings. Google Workspace, Microsoft 365 and most business mail services have a DKIM section in the admin console. It usually shows the selector name and whether signing is active.
Send yourself a test message to an address at a large provider and open “show original” or “view source”. A line starting with “DKIM-Signature” has a “d=” value, which should be your domain, and an “s=” value, which is the selector. The result line “dkim=pass” confirms that it works. See DKIM selectors explained for details.
Ask your host or IT contact. If your mail runs on a hosting account, DKIM is often a switch in the mail section.

If the signature is there and passes, you have a custom selector that the audit did not try. Nothing needs fixing. If there is no signature, continue to step 2.

Step 2: turn on signing and publish the key

Each mail service does this a little differently, but the pattern is the same:

In the mail service, generate a DKIM key for your domain. It shows you a selector and a record to add.
In your DNS, add the record exactly as shown. Some services give a TXT record with a long value, and others give a CNAME that points to a key they manage. The article on DKIM CNAME records explains the second kind.
Wait for DNS to update, then return to the mail service and press the button to start signing.
Send a test message and confirm “dkim=pass”.

Long keys can be a problem, because a single DNS string is limited to 255 characters and some panels do not split the value for you. If your key does not save, see DNS TXT records over 255 characters.

Every sender needs its own key

A domain often sends mail through several systems: the main mailbox, a newsletter tool, an invoicing service and a website contact form. Each of them should sign with a key for your domain, and each uses its own selector. The audit tests only for the presence of a key at common names, so one found key is enough to clear the finding, but real protection needs every sender to sign. Use your DMARC reports to see which sources pass and which do not. When you add DMARC, signing for every sender becomes more important; see how to fix a missing DMARC record.

Common problems

The key was published but signing was never switched on. The record exists, but the mail system still sends unsigned messages.
A typo in the selector name. A record at the wrong name is invisible to everything.
A short, weak key. Use 2048 bits where the service supports it; see DKIM key length.
Old keys that were never rotated. The guide to DKIM key rotation explains how to change keys safely.
Signature fails after forwarding or editing. Mailing lists and some security gateways change messages and break the signature; the guide on troubleshooting dkim=fail helps.

Why alignment matters for DMARC

For DMARC to pass, DKIM must not only be valid but also aligned: the domain in the signature should match the domain in the visible From address. Many mail services sign with their own domain by default, which gives a valid signature that does not help your domain. When you set up a service, look for the option to sign with your own domain, often called a custom domain or authenticated domain. That is what the key you publish in your DNS is for.

How long to wait before you check again

DNS changes usually appear within minutes but can take longer, depending on the time to live of the records. After you publish a key, wait until a DNS lookup shows it, send a test message and then run the audit again. If the notice remains even though the signature passes, your selector is probably not on the common list, which is no reason for concern.

A worked example

A consulting firm uses a business mailbox service. The audit report shows the DKIM notice. The office manager first suspects that her provider has no DKIM at all. She opens the admin console and finds that DKIM is on, using a selector named after the provider’s own pattern, which is not on the audit’s list of common names. A test message shows “dkim=pass”. She decides to leave it as it is. A month later, the firm adds a newsletter tool. The tool’s DKIM was not set up, and the DMARC reports soon show that newsletters fail authentication. She adds the tool’s DKIM records and the reports turn green. In both cases, the audit’s notice had been the starting point for a useful look at her mail setup, even though the first reading was a false alarm.

To see the e-mail results for your own domain, check your website with Site AI Audit. The check needs a free account; the plans unlock the full report.

The bottom line

The DKIM notice is a prompt, not a verdict. First find out whether your mail provider already signs your messages with a selector that the audit does not know. If not, generate a key, publish it, switch signing on and test it. Then run the audit again.

FAQ

Is the DKIM notice a serious problem?

It is the lowest severity, because the audit may simply not know your selector. Without DKIM, though, more of your mail can land in spam, so it is worth checking.

Can the audit see my DKIM selector if it is unusual?

No. It tries a list of common selector names. A custom selector can be valid and still not found by the audit.

Do I need DKIM if I have SPF?

They protect different things. SPF checks the sending server, DKIM signs the message. Having both makes DMARC more reliable.

How can I test DKIM myself?

Send a message to a large mail provider and view the original message. Look for a DKIM-Signature header and a result of dkim=pass.

What if my domain does not send e-mail?

The finding appears only for domains that receive mail. If you do not use e-mail on the domain at all, the audit mentions publishing a strict SPF record instead.