The receiving server found a DKIM signature, looked up the public key named by its selector and domain, and got nothing back, or a key that has been revoked. Check that exact name below: the page follows CNAMEs, reads the key record the way a verifier does, and tells you what to change.
Last verified 1 October 2026.
You’ll see it in the Authentication-Results header of a received message, worded differently by each receiver:
dkim=neutral (no key for signature) header.d=example.com header.s=s1 header.b=AbCdEf12
dkim=permerror (no key for signature) header.d=example.com header.s=s1
dkim=fail (no key) · DKIM key not found · dkim=permerror (key revoked)
Every DKIM signature names a signing domain (d=) and a selector (s=). The verifier joins them into one DNS name, <selector>._domainkey.<domain>, and fetches the TXT record there. RFC 6376 spells out what happens next (§6.1.2):
neutral, permerror or fail; the cause is the same.p=: “this key has been revoked and the Verifier MUST treat this as a failed signature check and return PERMFAIL (key revoked). There is no defined semantic difference between a key that has been revoked and a key record that has been removed.”dkim=temperror. That points at the domain’s DNS servers, not a missing record.A signature without a usable key doesn’t count for DMARC. If it was your only aligned DKIM signature and SPF doesn’t align either, DMARC fails and your policy decides what happens to the message.
Source: RFC 6376 §6.1.2 (key retrieval) and §3.6.1 (key record tags); RFC 8301 §3.2 (key sizes); checked 1 October 2026.
Enter the d= domain and the s= selector from the failing signature (where to find them), or paste the DKIM-Signature header or the Authentication-Results line and the page reads them out. The lookups run in your browser against public DNS.
This shows the record as public DNS answers it now. A key that exists now doesn’t prove it existed when the message was checked, and a receiver’s resolver can hold an older answer for a while. The page can’t verify the signature itself: that needs the whole message (body hash and signed headers).
What this can and can’t tell you: it queries the exact name a verifier uses, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails), follows up to eight CNAMEs, and reads the key record’s tags: v=, k=, p=, t=, h=, s=. A lookup that fails shows as “couldn’t check”, never as missing. The RSA key size is read from the key itself. To find every selector a domain publishes and grade SPF and DMARC too, use the DMARC checker.
Open the message’s source (“Show original” in Gmail, “View message source” in Outlook) and look for either header:
DKIM-Signature, added by the sender: d= is the domain and s= the selector. A message can carry several signatures (yours and your sending service’s); check the one the result names.Authentication-Results, added by the receiver: the same values appear as header.d= and header.s= next to the dkim= result. Older receivers show only header.i=@domain; then take the selector from the DKIM-Signature.DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; t=1759300000; h=from:to:subject:date; bh=...; b=...
key name looked up: s1._domainkey.example.com (TXT)Selectors can contain dots (s=mail.2026 becomes mail.2026._domainkey.example.com), and d= can be a subdomain such as mail.example.com: the key then lives under that subdomain, not the main domain.
Most DNS hosts want only the part before your domain in the name field: s1._domainkey, not s1._domainkey.example.com. Typing the full name often produces s1._domainkey.example.com.example.com. If the key is on a subdomain’s zone or at a different DNS provider than the one your domain’s nameservers point to, receivers won’t see it either. Publish the TXT record exactly as your sending service gives it, then check again here.
The key has to be at the selector the mail is signed with. A key published as default._domainkey doesn’t help mail signed with s=mail. Read s= from a real message, not from setup screens, and check that name.
Many sending services ask for a CNAME at the selector name that points at a key they host. If the target has no TXT record, the lookup ends empty and the result is no key. This is the usual cause when the CNAME is there: the account or domain at the service was removed or not finished, the target was copied with a typo, or the service hasn’t published the key yet. Copy the current target from the service’s domain settings and finish its verification step.
When keys rotate, the old selector’s record is deleted or emptied (p=). Any system still signing with the old private key, such as a second server, an app with its own DKIM settings or a forwarding service, now produces “no key” or “key revoked”. Find what added that signature (the Received: headers show the path) and update its key, or keep the old selector published until it stops.
A 2048-bit key is longer than the 255 characters one TXT string can hold, so it’s stored as several strings that receivers join with nothing between them (RFC 6376 §3.6.2.2). Some DNS hosts split it for you; others need the value entered as quoted parts. Quotes that end up inside the value, a missing piece, or a trailing ... from a truncated copy break the key. The checker flags quotes and keys that don’t decode. If your host can’t hold a 2048-bit key, re-paste it the way its help pages describe; Google Workspace also offers a 1024-bit key for that case.
RFC 6376 says a selector name must hold one TXT record; with more, “the results are undefined”. Delete the old one.
An empty p= is how a sender says “this selector is retired”. Mail shouldn’t be signed with it any more: switch the signer to the current selector, or publish the matching key if the record was emptied by mistake.
Admin console > Apps > Google Workspace > Gmail > Authenticate email. Pick the domain, click Generate new record (the default selector prefix is google; choose 2048-bit unless your DNS host can’t hold it), publish the TXT record at the host name shown (google._domainkey), then click Start authentication. Source: Google, Set up DKIM (checked 1 October 2026).
Microsoft 365 uses two CNAMEs, selector1._domainkey and selector2._domainkey, that point at keys Microsoft hosts. Only one of the two targets may have a key at a time, which is normal. If the one your mail is signed with is missing, see fixing Microsoft 365 DKIM “CnameMissing”, which checks both against Microsoft’s formats.
Services that send for your domain usually list one to three CNAME records in their domain authentication or sender settings. Publish every record exactly as listed, set any CDN proxy option to DNS only, then run the service’s own verification. Check here with the selector from a real message once it says the domain is verified.
After any change, check again here. How soon receivers see it depends on caching at your DNS host and theirs, so send a new test message rather than judging by the old one.
The receiver looked the key up when the message arrived. If the record was added or fixed after that, or the receiver’s resolver still had a cached “doesn’t exist” answer, the result was recorded then and doesn’t change. Check that the message’s s= and d= match the name you checked, then send a new test message.
No, the cause is the same: the key record for the signature’s selector and domain doesn’t exist. RFC 6376 calls it PERMFAIL (no key for signature); receivers map it to neutral, permerror or fail in Authentication-Results. Either way the signature doesn’t count towards DMARC.
The key is revoked. RFC 6376 says an empty p= value means the public key has been revoked, signatures using that selector fail, and there is no defined difference between a revoked key and a removed one. Senders publish it on purpose after rotating to a new selector.
No. It checks the key record a verifier fetches. Verifying the signature needs the full message: the body hash and signed headers. To confirm signing works end to end, send a message to an outside mailbox and read dkim= in its Authentication-Results header.
Yes. Many sending services ask you to publish a CNAME at the selector name that points at a key they host, so they can rotate it. The verifier’s DNS lookup follows the CNAME. If the target has no TXT record, the result is the same as no key: no key for signature.
If you manage sending domains for clients or brands, Email Security Signals runs DKIM, SPF and DMARC checks on a whole list and returns one row per domain with the DKIM selectors found, the DMARC policy, SPF lookup count and an A–F grade, ready to export as CSV. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Check a list on the Apify Store →Related: Microsoft 365 DKIM “CnameMissing”, fixing the 550 5.7.509 DMARC reject bounce and the free DMARC, SPF and DKIM checker.