How to fix “DKIM record published no DKIM record found” errors
Published 12 Jul 2025
Updated 21 May 2026
10 min read
Summarize with
The fix is to make the selector, DNS hostname, and public key match the DKIM signature your mail system uses. The error means a checker queried the expected DKIM location, usually selector._domainkey.yourdomain.com, and did not get a usable DKIM TXT or CNAME response. I start by confirming the selector in the message header, then I publish the record at the exact DNS name, wait for DNS propagation, and send a new signed test email.
Most cases are not cryptographic problems. They are publishing problems. The record is under the wrong host, the DNS provider added the domain twice, the selector is not the one the sender uses, a CNAME points to the wrong target, or the email was never DKIM signed in the first place.
The same process applies whether the wording appears in a mailbox provider admin screen, a DNS checker, or a DMARC report. The important point is simple: DKIM validation starts with a DNS lookup. If that lookup does not return the key for the selector in the email header, the validator has nothing to verify.
What the error means
DKIM has two pieces that must line up. The sending system adds a DKIM-Signature header to the email. That header includes a selector, shown as s=, and a signing domain, shown as d=. The receiving server combines those values to find the public key in DNS.
How the DKIM DNS lookup is builttext
selector + ._domainkey. + signing-domain s=selector1 d=example.com Lookup: selector1._domainkey.example.com
If the lookup returns no answer, the checker reports that a DKIM record was expected but no DKIM record was found. If the lookup returns a malformed key, you get a different error, usually about an invalid public key, bad tag, unsupported key type, or a permerror.
Flowchart showing how a receiver uses the DKIM selector and domain to find the public key.
Fix it in this order
I use this order because it separates DNS publication errors from signing errors. Do not change the key first. First prove that you are checking the same selector and domain that the sender used in the message.
- Selector: Open the original message headers and read the selector value after s=. Do not assume the selector from memory.
- Domain: Read the signing domain after d=. DKIM can sign with a subdomain, a vendor domain, or your organizational domain.
- Hostname: Publish the record at selector._domainkey.domain, not at the root domain and not at _domainkey alone.
- Record type: Use the exact type your sender requires. Some systems require TXT, and some require CNAME.
- Value: Copy the full public key or CNAME target without extra spaces, quotes copied as text, or missing characters.
- Test: After DNS resolves, send a new email. Old messages do not prove that the current signer and DNS are correct.
Do not troubleshoot DKIM only by looking at the DNS dashboard. The DNS dashboard shows what you intended to publish. The receiver only sees the public DNS answer for the exact selector and domain in the message header.
Example TXT DKIM recorddns
Host: selector1._domainkey.example.com Type: TXT Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
Example CNAME DKIM recorddns
Host: selector1._domainkey.example.com Type: CNAME Value: selector1-example-com._domainkey.sender.example.net
Where the lookup usually breaks
The fastest way to fix this error is to map the visible symptom to the likely cause. These are the cases I see most often when a team says the DKIM record is published but a checker still says no DKIM record was found.
|
|
|
|---|---|---|
No answer | Wrong host | Rebuild name |
Old key | DNS cache | Wait TTL |
Wrong target | Bad CNAME | Copy target |
Unsigned mail | DKIM off | Enable signing |
Bad key | Truncated TXT | Republish key |
Common DKIM no-record symptoms and fixes
The host value is the easiest place to make a mistake because DNS dashboards handle zone names differently. Some dashboards ask for only selector._domainkey. Others accept the full selector._domainkey.example.com name. If you enter the full name where the dashboard expects a relative name, it can publish selector._domainkey.example.com.example.com.
Broken publication
- Selector: The checker tests selector1, but the DNS record was created under default.
- Zone name: The DNS host appended the domain again after a full host value was pasted.
- Record type: The sender expects a CNAME, but a TXT record was created instead.
- Mail state: The message has no DKIM-Signature header, so there is no selector to validate.
Correct publication
- Selector: The selector in the email header is the same selector checked in DNS.
- Zone name: The published hostname resolves exactly once under the intended domain.
- Record type: The type matches the sender instructions, either TXT or CNAME.
- Mail state: A fresh test message has a DKIM-Signature header and passes verification.
Check the selector and DNS answer
The most reliable selector is the one in a real email header. Open the message source, search for DKIM-Signature, and read the s= and d= values. If there are multiple DKIM signatures, check each one separately. A message can pass with one signature and fail with another.
If you do not have an email header yet, use the sender's DKIM setup page to find the expected selector, then verify the DNS answer with the DKIM checker. Enter the selector and domain separately so you can catch selector mistakes instead of testing a guessed hostname.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A clean DKIM lookup should return a TXT record that starts with v=DKIM1 or a CNAME that resolves to the provider's key host. If the checker returns no record, test the DNS name directly in your DNS console and confirm that the record is public, not only present in a private DNS zone.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
When the selector looks correct but validation still fails, compare the failing case with other DKIM validation issues. That situation usually means DNS is answering, but the returned key or signing details do not match the message.
Fix DNS publication problems
Once you know the exact selector and domain, focus on the DNS record itself. A DKIM TXT record must be one complete public key. A DKIM CNAME record must point to the exact target the sender gave you. Do not mix the two patterns.
Relative versus full DNS host valuesdns
If your DNS zone is example.com, enter one of these: Relative host: selector1._domainkey Full host: selector1._domainkey.example.com Do not publish: selector1._domainkey.example.com.example.com
TXT formatting also matters. Many DNS providers split long TXT values into quoted chunks behind the scenes, which is normal. The problem happens when copied quote marks, line breaks, or missing characters become part of the key. If the sender provides a copy button, use it. If not, copy into a plain text editor first and remove extra whitespace around the value.
Do not publish two DKIM records with the same selector unless your sender explicitly supports that format. Multiple TXT records at the same DKIM hostname can make receivers treat the key as unusable.
- Duplicate TXT: Remove the old value before adding a replacement key for the same selector.
- TXT plus CNAME: Use one record type at the DKIM hostname, not both.
- Private DNS: Publish the key in public authoritative DNS for the signing domain.
- Short TTL: Use a short TTL during setup, then raise it after validation passes.
If DNS returns a key but the checker complains about the public key itself, treat that as a different problem. The fix is usually to republish the key, remove stray characters, or generate a new key pair. The related guide on invalid RSA keys covers that specific failure.
Confirm the message is signed
A published DKIM record does not sign mail by itself. Your sending platform must apply the DKIM-Signature header when it sends the message. If the message has no DKIM-Signature header, a checker can only validate DNS, not the actual email.
Header fields to inspecttext
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; Authentication-Results: mx.example.net; dkim=pass header.d=example.com
If there is no DKIM-Signature header, enable DKIM signing in the sender, choose the verified domain, and send a fresh message. If the sender signs with a different domain than expected, the DNS lookup must be performed under that signing domain, not the visible From domain.
This is also where DMARC domain matching matters. DKIM can technically pass while DMARC still fails if the signing domain does not match the visible From domain. For that specific case, check whether the header domain and From domain share the same organizational domain before changing DNS.
When the DNS record is correct but the email is not signed, the right fix is in the sending platform, not DNS. The related walkthrough on mail that is not DKIM signed is the better next step.
How Suped fits into the workflow
Manual DKIM checks are useful when fixing one selector. They are less useful when you need to know which sending source caused the problem, whether the issue affected real traffic, and whether DMARC domain matching failed at the same time. That is where Suped's product fits the workflow.
Suped is the best overall practical DMARC platform for most teams because it connects DKIM, SPF, DMARC, source identification, alerts, blocklist (blacklist) monitoring, and deliverability signals in one place. The useful part is the source-level context: which source sent the mail, what DNS record is missing, and which steps fix it.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a broader check of the domain, the domain health check helps confirm DKIM, SPF, and DMARC records together. For ongoing enforcement and reporting, DMARC monitoring turns one-off authentication checks into source-level reporting and alerts.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
I still fix the DNS record the same way: selector, hostname, record type, value, propagation, and fresh test mail. Suped makes the loop shorter by showing the issue, the affected source, and the verification path in the same workflow. Hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, real-time alerts, and MSP multi-tenancy matter when the team manages more than one domain or more than one sender.
When the error persists
If the selector and DNS record are correct but the error still appears, slow down and prove each layer. A checker can cache old DNS. A mailbox provider can show setup status before all authoritative nameservers answer. A message can carry an old selector after a key rotation. These are timing and routing issues, not reasons to keep editing the key.
- Authoritative DNS: Query the authoritative nameservers, not only a local resolver.
- Fresh mail: Send a new message after signing is enabled and DNS is visible.
- Key rotation: Keep the old selector published until all mail signed with it has aged out.
- Provider status: Wait for the sender's admin status to recheck after public DNS starts answering.
The phrase is common in Microsoft 365 setup discussions, and the Microsoft thread is a useful reminder that status checks depend on the exact CNAME records and the domain being verified in the tenant.
If a receiving server reports no key for signature, treat that as the runtime version of the same problem. The email points receivers to a selector, but DNS does not provide the public key they need.
The practical fix
To fix "DKIM record published no DKIM record found", do not keep republishing random DKIM records. Read the selector and signing domain, build the exact DNS hostname, publish the correct TXT or CNAME record there, confirm public DNS returns it, then send a new signed email and check the result.
If the record is visible and mail is signed, DKIM should move from no record to either pass or a more specific validation error. That more specific error is progress because it means DNS lookup is working and the remaining issue is key format, body hash, domain match, or signing configuration.
The clean end state is simple: the DKIM selector in the message header resolves in public DNS, the returned key matches the private key used by the sender, and the visible From domain has DMARC coverage for the authenticated traffic.
