"DKIM Selector Not Found" Error: What It Means and How to Fix It

You tried to look up your DKIM (DomainKeys Identified Mail) record and got back "selector not found." Maybe you noticed it in a deliverability report, maybe a monitoring tool flagged it, or maybe you were running a quick check after setting up a new email service. Either way, your DKIM authentication is broken right now, and any emails relying on that selector are failing verification. This is one of the most common DKIM issues, and the good news is that it is almost always fixable once you identify the root cause.

What This Error Means

When an email server receives a message with a DKIM signature, it reads the selector name from the s= tag in the DKIM-Signature header. It then performs a DNS query for a very specific address:

[selector]._domainkey.[yourdomain.com]

For example, if your email uses selector google and your domain is yourcompany.com, the receiving server looks up:

google._domainkey.yourcompany.com

A "selector not found" error means that DNS query came back empty. There is no TXT record and no CNAME record at that location. Without the public key stored in that record, the receiving server has no way to verify the DKIM signature on your email. The result is a DKIM failure, which can send your messages straight to spam or get them rejected entirely.

Why Your DKIM Record Cannot Be Found

There are six common reasons this happens, roughly in order of how often we see them.

1. Wrong selector name. This is by far the most common cause. You are looking up a selector that does not match what is actually published in DNS. Every email service uses its own selector names. If you send through Google Workspace but search for s1 (a SendGrid selector), the lookup returns nothing even though your DKIM is set up correctly under the google selector.

2. Record was never published. You started the DKIM setup in your email service, saw the DNS records you were supposed to add, and then never actually added them. Or you added them to a draft that was never saved. The setup is incomplete, and no record exists in DNS at all.

3. DNS propagation delay. You just added the record minutes ago. DNS changes can take anywhere from a few minutes to 48 hours to propagate globally, though most records appear within 30 minutes. If you check too early, you get "not found" even though the record is on its way.

4. CNAME vs TXT confusion. Some email providers give you a CNAME record to add, while others give you a TXT record. If you created the wrong type, the lookup may fail. A CNAME pointing to the provider's servers is not the same as a TXT record containing the public key directly.

5. Wrong DNS zone. You added the record to the wrong domain or subdomain. If your emails send from mail.yourcompany.com but you added the DKIM record to yourcompany.com, the lookup for selector._domainkey.mail.yourcompany.com will find nothing.

6. Record deleted accidentally. During a DNS cleanup or provider migration, someone removed the DKIM record without realizing what it was. This happens more often than you would expect, especially when multiple people manage DNS.

How to Find Your Correct Selector

If you are not sure which selector your email service uses, there are two reliable ways to find it.

Check the email headers. Send a test email from the service in question, then view the raw headers of that message. Look for the DKIM-Signature header and find the s= tag. Whatever value follows s= is the selector you need to look up.

Check your provider's admin console. Most email services show the selector and DNS records you need during the domain authentication setup. Log in and look for DKIM or domain authentication settings.

If neither of those works, try the common selectors for your provider:

Fixing the Problem

CNAME Records vs TXT Records

This distinction trips up a lot of people. Some email services (like Google Workspace and Mailgun) give you a TXT record containing the actual public key. Others (like Microsoft 365, Mailchimp, and SendGrid) give you a CNAME record that points to their servers, where they host the public key on your behalf.

The advantage of CNAME records is that the provider can rotate keys automatically without you needing to update DNS. The disadvantage is that if the provider's target hostname changes or becomes unreachable, your DKIM breaks through no fault of your own.

If your service uses CNAME records and the lookup fails, check that the CNAME target itself resolves. You can do this by looking up the target hostname directly. If the target is down, contact your email service provider.

Creating a New DKIM Record

If your record was deleted, never existed, or is damaged beyond repair, you may need to generate a fresh DKIM key pair. Visit dkimcreator.com to generate a new public/private key with your chosen selector name and key size. Publish the public key as a TXT record in DNS, and configure your mail server with the corresponding private key.

For services like Google Workspace or Microsoft 365, use the provider's built-in key generation instead, as they manage the private key for you.

Once your record is in place, verify it with our free DKIM checker tool, then set up ongoing monitoring with deliverabilitychecker.com so you will know immediately if the record ever disappears again. You should also check that your SPF record and DMARC policy are properly configured to complete your email authentication.

Monitor Your DKIM Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.