How does a missing DKIM DNS TXT record affect email deliverability?
Updated on 6 Oct 2026: We clarified bulk sender DKIM requirements and added precise DNS checks for missing public keys and cached lookup failures.
A missing DKIM DNS TXT record means the receiving mail server cannot find the public key needed to verify the DKIM signature. RFC 6376 defines an absent key as a permanent failure for that signature. Authentication reports often show dkim=permerror, dkim=fail, or similar wording such as no key for signature, depending on the receiver.
Is that worse than not signing at all? At the DKIM layer, both outcomes fail to provide a validated signature. DKIM guidance does not require receivers to penalize a bad signature more than no signature. A missing key is still more urgent operationally because it proves that the signing and DNS configuration disagree, and it can remove the DKIM path to DMARC pass.
Treat this as a production issue. If the mail is signed, the public key needs to exist at the correct selector name and match the sender's private key before volume is sent.
How a missing DKIM record affects delivery
A missing DKIM TXT record causes the affected signature to fail DKIM verification. That removes a valid authentication signal and can increase spam placement or rejection risk when no other aligned authentication path produces DMARC pass. Inbox placement still depends on the receiver's policy and the sender's other signals.
- DKIM result: The receiver sees a DKIM signature but cannot retrieve the public key, so that signature returns a permanent failure instead of pass.
- DMARC result: DMARC passes when at least one DKIM signature passes with an aligned domain, or SPF passes with an aligned MAIL FROM domain.
- Deliverability risk: The risk is highest for bulk mail, forwarded mail, and streams with no other aligned authentication result.
- Fix priority: Publish the correct selector record, check authoritative DNS and caches, then test a fresh message before resuming volume.
Only pass counts
A failed DKIM signature and no DKIM signature are both non-pass outcomes. The practical difference is diagnostic: a missing key on signed mail identifies a broken authentication setup, while no signature means that sender did not use DKIM for the message.
The fastest way to confirm the DNS side is to check the selector with a DKIM checker. That tells you whether the public key is present, readable, and formatted in a way receivers can use.
Why DKIM verification fails
DKIM works by placing a cryptographic signature in the message header. That signature includes a signing domain and a selector. The receiver combines those values to look up the public key in DNS at a name like selector._domainkey.example.com. If the TXT record is missing, the receiver cannot verify that signature.
Illustrative DKIM signature and receiver resulttext
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; Authentication-Results: mx.example.net; dkim=permerror (no key for signature) header.d=example.com header.s=selector1
The missing TXT record is not the only possible DKIM key problem. The record can exist but contain the wrong key, invalid syntax, a broken split string, or a selector mismatch. Those are separate failure modes, but the affected signature still does not pass. If the record exists and validation still fails, inspect the invalid RSA key next.
One failed signature does not automatically make every DKIM result fail. A message can carry multiple DKIM signatures, and receivers evaluate them independently. Another valid signature can still pass DKIM and satisfy DMARC if its signing domain has DMARC alignment with the visible From domain.
|
|
|
|
|---|---|---|---|
No public key | permerror (no key) | Signature cannot be verified | Depends on SPF fallback and sender requirements |
Wrong public key | fail | Signature does not match the published key | Depends on SPF fallback and sender requirements |
Temporary DNS error | temperror | Key lookup timed out or returned SERVFAIL | A receiver can defer delivery or continue filtering |
No signing | none | No DKIM signature to verify | Depends on SPF and sender requirements |
Matching key and valid signature | pass | Signature verified | Inbox placement still depends on receiver filtering |
Common DKIM DNS outcomes
These examples use the Authentication-Results definitions. A missing key is a permanent verification failure; a timeout or SERVFAIL is a temporary DNS problem, often reported as dkim=temperror. A missing selector does not inherently slow DNS or guarantee repeated retries.
DKIM verification fails when the selector DNS lookup returns no public key.
When delivery risk increases
The deliverability impact starts with the loss of a validated authentication signal. DKIM does not guarantee inbox placement, and a missing key does not create one universal receiver response. It gives the receiver one less verified identity to use alongside DMARC, reputation data, message characteristics, and its filtering policy.
One aligned mechanism can still produce DMARC pass, so a message can pass when SPF validates the aligned MAIL FROM domain. RFC 9989 requires fully participating domain owners to deploy both SPF and DKIM with DMARC alignment. Domains publishing p=reject must apply valid DKIM signatures and must not rely solely on SPF.
DKIM is also the more durable authentication path through many forwarding flows because SPF often breaks when another server resends the message. The DKIM signature can survive forwarding when the signed headers and body remain unchanged.
Signed but missing key
- Signal: The message has a DKIM signature, but that signature cannot be validated.
- DMARC: That signature cannot satisfy DMARC, so another aligned DKIM signature or SPF must carry the result.
- Operations: The selector, DNS zone, signing configuration, or sending service needs correction.
Not signed at all
- Signal: There is no DKIM proof for the receiver to evaluate.
- DMARC: The message depends on SPF for a passing DMARC result.
- Operations: The sender needs DKIM enabled for that mail stream.
Do not assume SPF provides a fallback without checking the exact MAIL FROM domain and receiver result. A message can pass SPF for a vendor bounce domain and still fail DMARC if that domain does not meet the DMARC domain matching rules for the visible From domain.
Worst case
The highest-risk case is mail with no valid aligned DKIM signature, SPF using a non-aligned domain, and DMARC at quarantine or reject. That combination gives the receiver no authenticated path for the visible From domain.
DMARC risk by authentication path
Prioritize missing DKIM TXT records by available DMARC authentication paths. Receiver filtering and bulk sender DKIM requirements also affect delivery.
Low
Pass
An aligned DKIM signature passes for the visible From domain.
Warning
Fallback
DKIM fails, but SPF passes with an aligned MAIL FROM domain.
Critical
No path
No DKIM signature passes with alignment, and SPF has no aligned pass.
Bulk senders still need working DKIM
Google's sender guidelines require bulk senders to use both SPF and DKIM and publish DMARC. Google counts mail across the same primary domain toward its roughly 5,000-message daily threshold for personal Gmail accounts. Its sender requirements FAQ confirms that noncompliant traffic faces temporary or permanent rejection, or spam placement.
Yahoo's sender requirements also require SPF and DKIM for bulk senders, plus DMARC pass with at least p=none. An SPF-based DMARC pass does not repair a missing DKIM public key or satisfy the separate DKIM requirement.
For troubleshooting, inspect SMTP bounce and deferral messages for authentication errors even when DMARC passes through SPF. Check the affected mail stream's DKIM result before resuming bulk volume.
How to diagnose a missing DKIM record
Start with a received message's full headers. The DKIM-Signature header tells you which signing domain and selector the sender actually used. Then check DNS for that exact name. A common mistake is publishing a key for one selector while the mail stream signs with another.
Selector lookup patterntext
Header says: d=example.com; s=selector1 DNS name: selector1._domainkey.example.com Expected: A usable TXT public key, directly or through a CNAME # Replace the selector, domain, and nameserver with actual values. dig selector1._domainkey.example.com TXT +noall +answer +authority +comments dig selector1._domainkey.example.com CNAME +noall +answer +comments dig @ns1.example.net selector1._domainkey.example.com TXT +norecurse +noall +answer +authority +comments
Many DNS editors append the zone name automatically. In an example.com zone, the host field often needs selector1._domainkey; entering the full name can create selector1._domainkey.example.com.example.com. Follow the editor's naming format. If the header uses d=mail.example.com, the lookup is selector1._domainkey.mail.example.com. For a CNAME, also query its target for the TXT public key.
If you manage several mail sources, test each one separately. Invoices, password resets, marketing campaigns, helpdesk replies, and executive mailboxes can use different selectors. One source can pass DKIM while another fails because it uses an old selector.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
For a broader view, run a domain health checker after the DKIM check. A missing DKIM record can appear beside SPF lookup issues, missing DMARC reporting, delegation errors, or other DNS mistakes on the sending domain.
- Header: Find the DKIM-Signature header and copy the d= and s= values.
- DNS: Look up the exact selector record under _domainkey at every authoritative nameserver.
- Fresh test: Send a new message after DNS is visible and confirm that the destination receiver's trusted Authentication-Results header shows DKIM pass.
- DMARC: Confirm that a passing DKIM signing domain or SPF MAIL FROM domain meets the DMARC domain matching rules for the visible From domain.
How to fix the missing DKIM record
Publish the exact DKIM DNS record expected by the signing system. That normally means adding a TXT record at the selector name, although some senders provide a CNAME that resolves to their hosted key. The receiver needs the selector lookup to return a usable DKIM public key. If the sender supplies a CNAME, preserve that delegation and confirm its target returns the TXT public key. Do not add a competing TXT record at the same CNAME name.
Illustrative DKIM TXT record with an abbreviated keydns
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
The p= value above is shortened and cannot validate mail. Use the complete public key supplied by the signing system, never its private key. Long keys can span adjacent quoted strings within one TXT record; do not split them into separate TXT records. The v=DKIM1 tag is recommended rather than required, and must be first if included.
RFC 8301 requires RSA signing keys of at least 1024 bits and recommends at least 2048 bits. Use 2048-bit keys where supported; a 1024-bit key is not automatically a missing-key error.
Use the selector and public key supplied by the signing system; the published public key must match its private key. During a planned rotation, publish the new key under a new selector before the sender starts using it and keep the old selector live long enough for delayed mail signed with the old key to arrive.
Safe repair sequence
- Pause: Slow or pause the affected mail stream if volume is large.
- Publish: Add the exact TXT or CNAME record provided by the sender.
- Verify: Check authoritative DNS, allow relevant caches to expire, and send a fresh test email.
- Resume: Return volume gradually while watching DKIM, DMARC, bounce, and complaint results.
If the DNS record is present but messages still show no DKIM signature, the problem is in the sender configuration rather than the DNS key. That is a different failure path, and the right fix starts with confirming why the mail is not DKIM signed.
Repair a missing DKIM DNS record: copy the selector, publish the key, send a test, and confirm DKIM pass.
Why the fix can appear delayed
Publishing the key does not force every recursive DNS resolver to forget an earlier missing-record answer. Resolvers can cache NXDOMAIN, which means the selector name did not exist, or NODATA, which means the name existed without a TXT answer. This negative cache can remain until its TTL expires.
The TXT TTL is not the whole wait
When the record was previously absent, the relevant wait can be the zone's negative-cache TTL. RFC 2308 derives that TTL from the smaller of the SOA record's TTL and its MINIMUM field. The new TXT record's TTL does not erase a negative answer that a resolver already cached.
Intermittent DKIM results need a wider DNS check. If one authoritative nameserver returns the key and another returns no record, different receivers can get different answers. If every authoritative server is correct but public recursive resolvers disagree, wait for negative caches to expire and keep the affected volume low.
- Query every authoritative nameserver for the exact selector name and record type.
- Compare answers through more than one public recursive resolver to detect stale caches.
- Send a fresh message after the DNS answer is visible, because an old message header will keep its original Authentication-Results.
- Resume normal volume only after representative receivers report DKIM pass for the affected selector.
Track DKIM recovery with Suped
Suped's product connects selector checks with authentication results reported by receiving systems. A one-off DKIM lookup tells you whether one record exists now. Ongoing DMARC monitoring shows which sending sources are affected, their reported message volume, and whether another aligned authentication path still passes.
The practical workflow is to identify the affected source, record the signing domain and selector used in real mail, assign the DNS correction to the right owner, then watch the DKIM and DMARC pass rates recover. Suped keeps those steps in one issue workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
A selector can validate while one sending source still uses an old selector, and DNS answers can differ during a faulty change. Suped uses DMARC report data to identify sources with authentication failures and track recovery after the repair. Aggregate reports arrive after the reporting period, so use fresh message headers for the immediate check. Reports do not measure inbox placement, and a failed result alone does not establish that a DNS key is missing.
- Issue detection: Suped groups DKIM failures by reported sending source; selector DNS checks establish whether a key is missing or broken.
- Fix ownership: The issue record gives the DNS owner or sending-platform owner a concrete task.
- Change alerts: Suped can flag a DKIM or DMARC failure spike after a selector change.
- Recovery check: DMARC data confirms whether the affected source returns to aligned pass.
Views from the trenches
Best practices
Publish the selector before sending signed mail, then confirm real headers show DKIM pass.
Keep old selectors live during rotation so delayed mail can still verify after delivery.
Monitor DMARC reports daily during changes so missing keys are caught before volume grows.
Common pitfalls
Turning on signing before DNS propagation finishes creates visible DKIM failures at receivers.
Assuming SPF saves every send ignores forwarding, shared bounce domains, and domain matching.
Deleting a selector right after rotation breaks verification for mail still in transit.
Expert tips
Test one message per source after every DNS change, using the exact production path.
Use selector names that identify the sending system so failures reach the right owner.
Alert on DKIM fail spikes, not only DMARC fail spikes, because SPF can hide early issues.
Marketer view
Marketer from Email Geeks says a missing public key makes the DKIM signature fail, and that non-pass result is what receivers act on.
2024-04-12 - Email Geeks
Expert view
Expert from Email Geeks says failed DKIM and absent DKIM both lack a validated signature, but filters can still treat a visible failure as useful evidence.
2024-04-12 - Email Geeks
Confirm recovery before resuming volume
Publish the exact selector record, check every authoritative nameserver, allow negative caches to expire, and test a fresh message. Keep the affected stream paused or reduced until representative receivers report consistent DKIM and DMARC pass results.
Frequently asked questions
Neither produces DKIM pass, and DKIM guidance does not require receivers to treat a bad signature more harshly than no signature. A missing key on signed mail is still an urgent configuration fault because it can remove an aligned DKIM path that the sender intended to use.
SPF can still produce DMARC pass when the MAIL FROM domain passes SPF and meets the DMARC domain matching rules for the visible From domain. Forwarding often breaks SPF, bulk sender requirements still require DKIM, and RFC 9989 requires domains using p=reject to apply valid DKIM signatures rather than rely solely on SPF.
Use the selector and signing domain in the DKIM-Signature header. A common pattern is selector1._domainkey.example.com, but the exact selector comes from the signing system.
The fix works for a receiver after its resolver can see the new record. If it previously cached NXDOMAIN or NODATA, the zone's negative-cache TTL can control the wait rather than the new TXT record's TTL. Test authoritative DNS, multiple public recursive resolvers, the negative TTL, and a fresh message.
Yes. Receivers evaluate multiple DKIM signatures independently. Another valid signature can pass, and it can satisfy DMARC when its signing domain has DMARC alignment with the visible From domain.
Publish the correct key quickly when possible. If DNS access is blocked and the affected stream has high volume, pause or reduce that stream while the signing and DNS configuration are brought back into sync.
