# DKIM Record Not Found: 7 Causes and How to Fix Each URL: https://warmerly.com/blog/dkim-record-not-found-causes-and-fixes Published: 2026-10-14 Reading time: 6 minutes Tags: DNS, Authentication, Troubleshooting > DKIM record not found usually means a wrong selector, a record on the wrong name, or a DNS host that changed what you pasted. Seven causes, with fixes. DKIM record not found almost always means the lookup was made at the wrong name, not that your record is missing. A DKIM key lives at selector._domainkey.yourdomain, so the check needs the exact selector your mail provider signs with. If the selector is right, the next suspects are a DNS host that appended your domain twice, a pasted key that got broken, or signing that was never switched on. > **How this was checked**: The record format and the selector rule come from RFC 6376, the DKIM standard. The tag handling (key size, test mode, revoked keys) is what Warmerly's own DKIM checker reads. The causes are the ones that come up most often; the order is a suggested checking order, not a ranking from data. ## Cause 1: the selector is wrong Selectors are chosen by whoever generates the key, so there is no universal name. A checker that tries default will report not found for a domain signed with google, selector1 or something your provider made up. Find the real selector in a message header first: see how to find your DKIM selector. Then check that exact name. ## Cause 2: your DNS host added the domain twice Many DNS panels add your domain to whatever you type in the name box. If you enter google._domainkey.example.com, the record is saved as google._domainkey.example.com.example.com. Enter only google._domainkey, then check the result with a lookup tool. ## Cause 3: the key was pasted badly - Line breaks or spaces inside the p= value. The key must be one unbroken string. - Smart quotes copied from a document. Use plain text. - A 2048-bit key is longer than one 255-character DNS string. Most DNS hosts split it for you. If yours does not, publish it as several quoted strings in the same record, which receivers join back together. ## Cause 4: the record is on the wrong domain The domain in the DKIM signature (the d= tag) is the domain that must hold the record. If your provider signs as mail.example.com, a record on example.com will not be found. Read the d= value in the header, not the From address. ## Cause 5: a CNAME and a TXT record clash Some providers, Microsoft 365 for one, ask for CNAME records that point at their own key. Others want a TXT record. A name cannot hold both. Use the record type your provider shows in its admin screen. On Cloudflare, set DKIM CNAME records to DNS only, not proxied. ## Cause 6: signing was never switched on Publishing the record is half the job. Google Workspace and Microsoft 365 both make you generate the key, publish it and then press a button in the admin console to start signing. Until you do, mail goes out unsigned and the record, even though correct, protects nothing. The exact menu names change, so use the admin screen's own prompts. ## Cause 7: it has not spread yet, or the key was revoked A new record can take from minutes to a few hours to show everywhere, depending on the old record's time to live. A record with an empty p= is a revoked key on purpose, so it reads as present but unusable. A record with t=y is in test mode, which asks receivers to treat signed and unsigned mail the same. Warmerly's checker reports both, because a record can look healthy and still do nothing. **Check and learn more** - [Free DKIM checker (enter your selector if you know it)](https://warmerly.com/dkim-checker) - [How to find your DKIM selector](https://warmerly.com/blog/how-to-find-your-dkim-selector) - [SPF, DKIM and DMARC for cold email](https://warmerly.com/blog/spf-dkim-dmarc-cold-email) --- Source: https://warmerly.com/blog/dkim-record-not-found-causes-and-fixes Full content index: https://warmerly.com/llms-full.txt Site index: https://warmerly.com/llms.txt