DKIM Record Not Found: 7 Causes and How to Fix Each

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.

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.