DKIM "No Key for Signature": Selector और Rotation Fixes (2026)

प्रकाशित 2026-07-08

आंकड़े 2026-06-29 तक के · methodology v7. 261 मिलियन ग्रेडेड डोमेन में कुल जनगणना डेटा। देखें हम ग्रेड कैसे करते हैं।

“No key for signature” का मतलब है कि receiver ने DNS record query किया जिसकी ओर आपका DKIM सिग्नेचर points करता है — selector._domainkey.yourdomain — और कोई key नहीं मिली: यह कभी publish नहीं हुई, या mid-rotation में delete हो गई। Publish करें वह selector जो आपका signer actually use करता है। केवल 10,092,481 डोमेन — 3.87% — 261,086,232 ग्रेडेड डोमेन की Defaults.Exposed जनगणना के अनुसार SPF+DKIM+DMARC triad पूरा करते हैं।

Fix एक DNS record है, एक header में मिला। अपने mail को किस selector से sign किया जा रहा है यह जानने के लिए एक real DKIM-Signature header से s= और d= tags पढ़ें, वह exact record publish (या repair) करें, और CNAME delegation prefer करें ताकि आपका provider आपके लिए keys rotate करे। फिर नीचे दिए runbook से rotate करें — यह error आमतौर पर तब होती है जब किसी ने old selector बहुत जल्दी delete कर दिया।

“dkim no key for signature” का क्या मतलब है?

हर DKIM सिग्नेचर में दो tags होते हैं जो receiver को बताते हैं कि public key कहां fetch करें: d= (signing domain) और s= (selector)। Receiver उनसे बना एक DNS name query करता है — s._domainkey.d — key के लिए। “No key for signature” का मतलब है कि वह query खाली आई: सिग्नेचर मौजूद है, लेकिन जिस key का वह नाम लेता है वह नहीं है।

Wording Authentication-Results headers और DMARC aggregate reports में दिखती है — exact phrasing receiver के अनुसार vary करती है, लेकिन दो flavours matter करते हैं:

Result string (fragment, as widely observed)	वास्तव में क्या हुआ	क्षणिक?
`dkim=temperror (no key for signature)`	DNS query fail या timeout हुई — receiver को बिल्कुल जवाब नहीं मिला	हां — retries अक्सर pass; persistent होने पर ही investigate
`dkim=permerror (no key for signature)`	DNS query सफल रही और जवाब था “no such record” — selector genuinely absent है	नहीं — record publish करने तक missing रहेगा

एक one-off temperror DNS weather है। एक permerror — या days और receivers में repeat होता temperror — का मतलब है कि सिग्नेचर जिस record की ओर points करता है वह आपके zone में नहीं है। यह इस guide का विषय है।

परिणाम: एक unverifiable signature का मतलब है कोई DKIM नहीं, इसलिए DMARC केवल SPF पर fall back करता है — और SPF forwarding के तहत टूट जाता है। यदि सिग्नेचर present है लेकिन invalid है बजाय missing के (body hash, mangled key), वह अलग failure है — “DKIM signature not valid” देखें।

मुझे कैसे पता चलेगा कि मेरे mail को किस selector से sign किया गया है?

अपने provider की documentation से अनुमान न लगाएं — इसे real message से पढ़ें:

Affected system से एक mailbox पर message भेजें जिसे आप control करते हैं (Gmail address अच्छा काम करता है)।
Raw source open करें (Gmail में “Show original”, Outlook में “View message source”)।
DKIM-Signature: header खोजें और दो tags पढ़ें: s= selector है, d= signing domain है। एक illustrative example: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Receiver जो record query करता है वह है s._domainkey.d — यहां, mail2026._domainkey.yourdomain.com। खुद check करें: dig TXT mail2026._domainkey.yourdomain.com +short। Empty answer = error हर receiver के लिए real है।
प्रति sending system repeat करें। एक message multiple DKIM signatures carry कर सकता है — mailbox provider, newsletter tool, helpdesk — प्रत्येक अपने s=/d= pair और record के साथ। Failing को fix करें, और इसका d= note करें: केवल एक सिग्नेचर जिसका d= आपके From domain से match करता है DMARC की मदद करता है।

Selector record missing क्यों है?

चार कारण लगभग सभी इन errors के लिए जिम्मेदार हैं — इस क्रम में जांचें:

यह कभी publish नहीं हुआ। Signer को switch on किया गया (या default on हुआ) किसी selector के साथ जिसे DNS में किसी ने add नहीं किया। नए tools और gateways के साथ common जो unexpectedly sign करते हैं।
यह mid-rotation में delete हो गया। किसी ने old selector को “clean up” किया जबकि उससे sign किए गए messages अभी भी transit में, retry के लिए queued, या forwarding की प्रतीक्षा में थे। वह mail already s=old से sign है; old._domainkey delete करने से उन सभी messages retroactively टूट जाते हैं।
आपके DNS UI ने CNAME target बिगाड़ दिया। कई providers CNAME के जरिए delegate करते हैं (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), और कई DNS panels चुपचाप target में आपका zone append करते हैं — s1.domainkey.u123.esp.com.yourdomain.com store करते हैं, जो कहीं resolve नहीं होता। Target verify करें: dig CNAME s1._domainkey.yourdomain.com +short। वही trap tool migrations के दौरान काटता है — ईमेल tools switch करने के बाद DKIM failing देखें।
Provider ने rotate किया, आपके zone ने नहीं किया। एक provider key जो static TXT record के रूप में paste की गई (उनके CNAMEs के बजाय) उनके scheduled rotation से orphaned हो जाती है — signer एक selector पर move करता है जिसे आपने कभी publish नहीं किया। जनगणना में 261 मिलियन डोमेन में से केवल 51.84% scan time पर discoverable DKIM key present करते हैं (2026-06-29 तक का डेटा)।

“no key for signature” कैसे ठीक करूं?

DNS छूने से पहले defaults.exposed पर मुफ़्त स्कैन चलाएं। यह आपके live DKIM, SPF और DMARC records पढ़ता है और दिखाता है कि receivers वास्तव में क्या देखते हैं — including whether the selector resolves and whether a CNAME target got mangled।
Signer actually जो selector use करता है वह publish करें — header से s= value, किसी old runbook से नहीं। अपने provider के admin console से record प्राप्त करें (Google Workspace DKIM setup · Microsoft 365 DKIM setup) और ठीक s._domainkey.yourdomain.com पर add करें।
TXT key paste करने के बजाय CNAME delegation prefer करें। यदि आपका provider DKIM CNAMEs offer करता है, उनका उपयोग करें: key उनके zone में रहती है, इसलिए वे इसे rotate करते हैं बिना आपके DNS को फिर से छुए — cause 4 impossible हो जाती है। Newsletter platforms लगभग सभी इस तरह काम करते हैं; Mailchimp/Brevo/Klaviyo emails failing DMARC देखें।
अपने panel के बाहर से verify करें। dig TXT s._domainkey.yourdomain.com +short (या delegated selectors के लिए dig CNAME …) अपने network के बाहर किसी machine से। Panel record दिखाना prove नहीं करता अगर zone कुछ और serve करता है।
Re-scan करें और test message फिर से भेजें। Authentication-Results अब dkim=pass पढ़नी चाहिए। फिर DKIM ठीक करें पेज पर scan द्वारा फ्लैग की गई बाकी चीजें काम करें — एक passing signature जो आपके From domain के साथ align नहीं करती अभी भी DMARC fail करती है।

DKIM keys बिना यह error cause किए कैसे rotate करूं?

Rotation वह जगह है जहां working setups टूटती हैं। नियम जो इसे रोकता है: एक selector तभी delete होता है जब उससे sign किया गया आखिरी message drain हो जाए — cutover पर कभी नहीं। Signed mail आप सोचते हैं उससे अधिक समय तक जीता है: retry queues दिनों तक चलते हैं, और forwarded messages जब भी move होते हैं re-verified होते हैं।

Step	Action	अगले step से पहले Gate
1. Add	New selector (`s2._domainkey…`) को old के साथ publish करें	`dig` confirm करता है यह बाहर से resolve होता है
2. Switch	Signer को new selector पर point करें	Test message `s=s2` और `dkim=pass` दिखाता है
3. Wait	Old selector published रखें जबकि in-flight, queued और forwarded traffic drain होता है	≥ 7 days; DMARC aggregate reports देखें जब तक old selector दिखना बंद न हो
4. Retire	Old key remove करें — या बेहतर, empty `p=` tag के साथ republish: “retired”, “never existed” नहीं	Cutover पर कभी शुरू न करें — premature deletion “no key for signature” का #1 कारण है

CNAME delegation के साथ, आपका provider यह exact runbook अपने zone में run करता है और आप कभी नहीं देखते — delegation के पक्ष में सबसे मजबूत argument।

अक्सर पूछे जाने वाले सवाल

क्या “no key for signature” temperror है या permerror? दोनों strings मौजूद हैं: temperror एक DNS lookup है जो fail या timeout हुई — transient, अक्सर retry पर चली जाती है — जबकि permerror का मतलब है DNS ने “no such record” जवाब दिया। Receivers में repeat होता temperror आमतौर पर genuinely missing record भी निकलता है। dig से check करें और answer trust करें, label नहीं।

क्या यह error मेरे डोमेन को कोई spoof कर रहा है यह बताती है? नहीं — एक spoofer आपके selector से sign नहीं करेगा। इसका मतलब है कि आपका अपना mail एक ऐसा सिग्नेचर carry करता है जिसे receivers verify नहीं कर सकते, इसलिए यह unsigned count होता है और DMARC केवल SPF पर lean करता है। Full, aligned authentication rare है: केवल 10,092,481 of 261,086,232 domains (3.87%) ने Defaults.Exposed जनगणना में SPF+DKIM+DMARC triad complete किया (2026-06-29 तक का डेटा)।

क्या मैं नए के काम करते ही old selector delete कर सकता हूं? तुरंत नहीं। उससे sign किए गए messages अभी भी retry queues और forwarding paths में हैं; key delete करना उन्हें retroactively तोड़ता है। Old record कम से कम एक हफ्ता रखें, जब तक old selector दिखना बंद न हो तब तक अपनी DMARC reports देखें, फिर retire करें — ideally deletion के बजाय empty p= के साथ।

मेरे provider का checker कहता है DKIM configured है, लेकिन receivers अभी भी no key report करते हैं। कैसे? लगभग हमेशा CNAME-target trap: आपके DNS panel ने target में आपका zone append किया (…esp.com.yourdomain.com), इसलिए record मौजूद है लेकिन कहीं point नहीं करता। dig CNAME selector._domainkey.yourdomain.com +short stored target verbatim दिखाता है — इसे character-for-character provider की मांग से compare करें।

मालिक को रिपोर्ट भेजें

यदि आप किसी client या नियोक्ता के लिए यह ठीक कर रहे हैं, evidence के साथ loop close करें। Selector resolve होने के बाद मुफ़्त स्कैन फिर से चलाएं और graded report business owner को forward करें: dated, plain-language, DKIM अब verifying। यह वह artifact है जिसकी उन्हें cyber-insurance renewal और अगली supplier security questionnaire के लिए जरूरत होगी — एक working control का proof, सिर्फ एक closed ticket नहीं।

अपना DKIM मुफ़्त में जांचें

देखें कि आपके selectors resolve होते हैं या नहीं — और ठीक-ठीक क्या fix करना है — privately और owner-only।

अपना डोमेन जांचें → · “DKIM signature not valid” → · DKIM ठीक करें → · Google Workspace पर DKIM सेट करें → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।