DKIM Signature Not Found: How to Fix It

DKIM signature not found means the message was not signed

One missing header can turn a normal campaign into mail that looks easy to spoof.

If a test result says dkim=none or DKIM signature not found, the receiver did not see a DKIM-Signature header it could check. That is different from dkim=fail. A fail usually means the message was signed, but the key, selector, body hash, or DNS record did not match.

Start with the raw message source from Gmail, Outlook, or your tester. Look for a header named DKIM-Signature. If it is missing, DNS cannot fix that message. Your sending service must sign new mail before it leaves.

• Send a fresh test from the same tool, app, or campaign path that is failing.
• Open the full headers and read Authentication-Results.
• If you see dkim=none, fix signing in the provider first.
• If you see a DKIM-Signature header, note d= for the signing domain and s= for the selector.
• Check that the visible From domain is the domain you mean to authenticate.

Turn on DKIM at the sender

DKIM is created by the system that sends the message. Your DNS only publishes the public key.

In Google Workspace, Microsoft 365, your CRM, your email service provider, or your app mailer, find the DKIM or domain authentication screen. Add the domain, generate the DKIM record, and enable signing. Many providers give you a TXT record. Some hosted email tools give you one or more CNAME records that point at their keys.

Publish exactly what the provider gives you. The usual name is selector._domainkey.example.com. The selector is the value that will appear as s= in the DKIM-Signature header. If the provider gives s1, publish s1._domainkey. If it gives selector1 and selector2, publish both.

• Do not invent the selector. Copy it from the sender settings or from a signed test message.
• Do not paste a DKIM key at the root domain. DKIM lives under ._domainkey.
• Do not remove an old selector until every sender using it has stopped signing with it.
• After DNS saves, send a new message. Old mail will still show the old result.

Publish the selector that matches the signing domain

A DKIM key can be correct and still miss DMARC if it signs the wrong domain.

The d= value in DKIM is the signing domain. For DMARC to pass through DKIM, that domain must align with the visible From domain. With relaxed alignment, the same organizational domain is enough, such as mail.example.com signing mail from example.com. With strict alignment, it must match exactly.

If your provider signs as its own domain, DKIM can pass but DMARC may still fail. Add your domain to that provider and complete its DKIM setup so it signs as your domain. Then check the next test for dkim=pass and header.d=yourdomain.

• Use one DKIM setup for each sender: workspace mail, CRM, support desk, invoicing, and product mail.
• Check subdomains separately. news.example.com may use a different selector from example.com.
• Use at least a 1024-bit DKIM key for mail to Gmail. Use 2048-bit keys when your provider and DNS host support them.
• If a message is forwarded or changed by a list, DKIM can break. ARC may help receivers evaluate the chain, but it does not replace signing your own mail.

Check SPF and DMARC before you call it fixed

DKIM is one leg of the setup. DMARC ties the result to your visible From domain.

SPF lists which servers may send for your domain. Publish one SPF TXT record at the root domain. Keep it under the SPF 10 DNS lookup limit, because too many include, a, mx, exists, or redirect lookups can turn SPF into a permanent error. Use ~all while you are still testing. Move to -all only when you are sure every real sender is listed. Never use +all.

DMARC lives at _dmarc.example.com. Start with p=none and a rua address so you can see who is sending as you. Move to p=quarantine or p=reject after DMARC reports show your real mail passes SPF or DKIM with alignment. If you need to read a DMARC aggregate report, use the free DMARC report reader before tightening policy.

A free InboxRadar domain check can read SPF, DKIM, DMARC, and MX records in one place and flag drift before a provider change breaks sending.

Why Gmail or Outlook may still send mail to spam

A passing DKIM result removes a major red flag. It does not buy inbox placement by itself.

Gmail and Outlook also look at domain reputation, IP reputation, complaint rate, engagement, content, link safety, sending volume changes, blocklists, and whether your DNS is consistent. If you send from your own mail server, your sending IP should have matching forward and reverse DNS. Your MX records should also be valid so people can reply and receivers can see a normal mail setup.

If DKIM is now passing but mail still lands in spam, check recent volume spikes, cold lists, high bounce rates, URL shorteners, compromised forms, and blocklist listings. Then compare results by provider. A Gmail-only issue is often a reputation or engagement problem. A failure everywhere is more often DNS, authentication, or a sender configuration problem.

For a wider deliverability checklist, see the related guides at InboxRadar guides.

Do not mix DKIM with AI search crawlability

Email authentication and AI search visibility use different systems, but both can break quietly after a settings change.

If the same domain hosts public pages, robots.txt affects whether AI answer engines can reach those pages. The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing those crawlers in robots.txt removes you from that engine.

Training controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

Robots.txt is a stated site policy, not proof of what any bot did. Perplexity-User and Bytespider have been reported to ignore it, so read server logs with care. Only Googlebot documents JavaScript rendering. Client-side-only content may be invisible to other AI crawlers, but that is an undocumented risk, not proof that a named bot cannot run JavaScript. To check this, use the free AI visibility checker.