'DKIM Signature Not Valid' — कारण, जांचने के क्रम में (2026)

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

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

“DKIM signature not valid” के पांच सामान्य कारण हैं, सबसे अच्छे क्रम में जांचने के लिए: transit में modified content, एक truncated key record, एक published key जो signer से match नहीं करती, गलत selector, और fragile canonicalization। केवल 10,092,481 of 261,086,232 ग्रेडेड domains (3.87%) SPF + DKIM + enforcing-DMARC triad रखते हैं, Defaults.Exposed जनगणना (2026-06-29) के अनुसार।

Fix का क्रम मायने रखता है क्योंकि सबसे सामान्य कारण आपके DNS में बिल्कुल नहीं है। पहले transit में message को क्या बदला जांचें, फिर अंदर की ओर काम करें: key record की integrity, क्या यह आपके mail server actually जिससे sign कर रहा है उससे match करती है, selector, और अंत में signing settings। अधिकांश invalid signatures step एक या दो पर fix होती हैं।

“DKIM signature not valid” का वास्तव में क्या मतलब है?

हर DKIM-signed message एक DKIM-Signature header carry करता है जो domain (d=), selector (s=), message body का hash (bh=), और body hash plus selected headers पर cryptographic signature (b=) नाम देता है। Receiver <selector>._domainkey.<domain> पर DNS से आपकी public key fetch करता है, दोनों hashes recompute करता है, और signature check करता है (RFC 6376)। “Signature not valid” checker और header-speak है: वह verification run हुई और fail हुई — key मिली, लेकिन maths नहीं आई।

वह आखिरी clause diagnostic gold है। एक verifier जो आपकी key नहीं खोज सकता कुछ अलग कहता है — typically dkim=fail (no key for signature) जैसा header — और यह selector problem है, DKIM “no key for signature” — selector और rotation fixes में cover। और एक verifier जो अलग body hash recompute करता है आमतौर पर explicitly कहता है: body hash did not verify — Microsoft इसे dkim=fail (body hash did not verify) रिपोर्ट करता है, जबकि Gmail अक्सर उसी diagnosis को dkim=neutral (body hash did not verify) render करता है। किसी भी तरह, यह content modification की ओर points करता है, “body hash did not verify” — क्या बदला आपके message को में cover। कुछ भी छूने से पहले Authentication-Results header में exact wording पढ़ें: यह बताती है कि आप पांच में से कौन सा कारण पकड़े हैं।

यह सही करना rare है: केवल 51.84% ग्रेडेड domains DNS में discoverable DKIM key publish करते हैं, Defaults.Exposed जनगणना के अनुसार, और केवल 3.87% of 261 मिलियन ग्रेडेड domains SPF, DKIM और enforcing DMARC policy combine करते हैं — वह configuration जो bulk-sender rules अब assume करते हैं। Stage-by-stage picture SPF adoption maturity model में है।

पांच कारण क्या हैं, क्रम में?

#	कारण	Tell	Fix
1	Transit में modified content — gateway footers, legal disclaimers, mailing-list subject tags	Authentication-Results में `body hash did not verify`; external mail fail, direct mail pass	*Modification के बाद* साइन करें, या modify करना बंद करें — body-hash guide देखें**
2	Truncated या mangled long key	Published `p=` visibly shorter है generate की गई key से; हर receiver fail	2048-bit key को properly split TXT strings के रूप में re-publish करें
3	Published key signer से match नहीं करती	Failures rotation, migration या provider change के ठीक बाद शुरू होती हैं	Signer से current public key फिर से copy करें; CNAME delegation prefer करें
4	गलत या missing selector	`no key for signature` — lookup itself fail	Signer जो selector actually use करता है वह publish करें — selector guide देखें
5	Fragile canonicalization या `l=` tag	Trivially reformatted messages पर intermittent failures	`c=relaxed/relaxed`; `l=` completely remove करें

Cause 1 bold है क्योंकि यह उन messages पर signatures तोड़ता है जो perfectly signed थे। एक security gateway disclaimer append करता है, signing के बाद compliance footer stamp होता है, एक mailing list subject में [listname] जोड़ती है — body या signed headers बदलते हैं, hashes match नहीं करते, और signature invalid है आपके DNS में किसी गलती के बिना। यदि failures उन mail से correlate करती हैं जो gateway, list, या archiving hop के जरिए गईं, वहां से शुरू करें।

“DKIM signature not valid” कैसे ठीक करूं?

DNS छूने से पहले defaults.exposed पर मुफ़्त स्कैन चलाएं। यह दिखाता है कि आपका published key record present, well-formed और complete है — “आपका DNS टूटा है” (causes 2–4) को “आपका DNS ठीक है, message बदली जा रही है” (cause 1) से एक step में अलग करता है।
Failing message के Authentication-Results header पढ़ें। body hash did not verify → cause 1, body-hash guide पर जाएं — सामान्य suspects gateway footers और disclaimers हैं, और fix modification के बाद sign करना है। no key for signature → cause 4, selector guide पर जाएं। Plain signature failure → जारी रखें।
Published key में truncation जांचें। <selector>._domainkey.<yourdomain> को TXT के रूप में look up करें (dig TXT selector._domainkey.example.com)। 2048-bit RSA public key एक single TXT string की 255-character limit से longer है, इसलिए इसे multiple quoted strings के रूप में publish किया जाना चाहिए जिन्हें receivers concatenate करते हैं — और DNS-provider web UIs notoriously paste को silently truncate करने, split mangle करने, या p= value में whitespace और quotes inject करने के लिए notorious हैं। Character-for-character आपके signer द्वारा generate की गई key से compare करें; हमारे DKIM setup walkthroughs per-provider quirks cover करते हैं।
Published key signer से match करती है confirm करें। Key rotation, provider migration, या ESP reconnect के बाद, यह common है कि signer नई private key रखे जबकि DNS अभी भी पुरानी public key serve करता है — हर signature गलत key के विरुद्ध verify होती है और fail। Provider के admin console से current record फिर से copy करें। बेहतर: जहां provider CNAME delegation offer करता है, उसका उपयोग करें — provider अपनी side पर keys rotate करता है और failures की यह पूरी class disappear हो जाती है। और पुरानी selector तब तक delete न करें जब तक उससे sign किया गया traffic drain न हो जाए।
Signing settings fix करें, केवल record नहीं। Canonicalization को c=relaxed/relaxed सेट करें, जो whitespace re-wrapping और header re-folding को tolerate करता है जो intermediate servers legitimately करते हैं; simple canonicalization उन changes पर fail जो मानव देख भी नहीं सकता। और l= body-length tag उपयोग न करें: यह footers को through जाने देने के लिए था, लेकिन यह किसी को भी आपके signed message में arbitrary content append करने देता है बिना signature तोड़े — एक real attack vector — और यह gateway modifications से अभी भी नहीं बचता। कोई l= नहीं दोनों safer और more reliable choice है।
Re-scan करें, फिर alignment जांचें। Valid signature केवल DMARC की मदद करती है यदि d= domain आपके From domain के साथ align करे — एक signature जो d=yourcompany.gappssmtp.com के रूप में validate करती है DKIM pass करती है और अभी भी DMARC fail। यदि यह आप हैं, default-signature trap देखें, फिर DKIM ठीक करें पेज पर scan द्वारा फ्लैग की गई बाकी चीजें काम करें।

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

क्या “DKIM signature not valid” वही है जो “body hash did not verify”? Body-hash message एक specific sub-case है: signing के बाद body बदली (footers, disclaimers, list rewrites)। “Signature not valid” किसी भी failed verification के लिए umbrella verdict है, जिसमें bad keys और header changes शामिल हैं — इसीलिए ऊपर step 2 header पढ़ना है, और इसीलिए body-hash case का अपना guide है।

क्या invalid DKIM signature का मतलब है मेरा mail reject हो रहा है? अपने आप में नहीं — receivers broken signature को missing जैसा treat करते हैं। नुकसान DMARC के जरिए होता है: यदि SPF alignment के साथ pass नहीं करता, message DMARC fail करता है और आपकी published policy apply होती है। 2026-06-29 जनगणना तक, केवल 3.87% of 261,086,232 ग्रेडेड domains SPF, DKIM और enforcing DMARC policy एक साथ रखते हैं — लेकिन Gmail और Microsoft अब senders से exactly वही expect करते हैं, इसलिए broken DKIM leg rejection से पहले deliverability cost करती है।

क्या मुझे 1024-bit या 2048-bit DKIM key उपयोग करनी चाहिए? 2048-bit — 1024-bit keys current cryptographic recommendations से नीचे हैं और कुछ receivers उन्हें down score करते हैं। Catch purely operational है: 2048-bit key एक 255-character TXT string में fit नहीं होती, इसलिए इसे correctly split किया जाना चाहिए (ऊपर cause 2)। Provider के लिए CNAME delegation splitting problem को पूरी तरह sidestep करती है।

मेरा DKIM checker पर pass होता है लेकिन DMARC अभी भी fail — कैसे? लगभग निश्चित रूप से alignment: signature validate करती है, लेकिन इसका d= domain (जैसे yourcompany.gappssmtp.com या yourtenant.onmicrosoft.com) आपके From domain से match नहीं करता, इसलिए DMARC इसे उपयोग नहीं कर सकता। अपने provider का custom-domain signing enable करें — full walkthrough default-signature trap guide में है।

क्या मैं DKIM off कर सकता हूं यदि यह fail होती रहे? नहीं — 2024 bulk-sender mandates के बाद से, Gmail और Yahoo volume senders के लिए DKIM require करते हैं, और enforcing DMARC policy practically DKIM चाहती है क्योंकि SPF alone forwarding के तहत टूट जाता है। Signature fix करें; ऊपर के कारण सभी एक दोपहर में fixable हैं।

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

यदि आप किसी client या नियोक्ता के लिए यह ठीक कर रहे हैं, evidence के साथ loop close करें। अपने changes के बाद मुफ़्त स्कैन फिर से चलाएं और graded report business owner को forward करें: dated, plain-language, DKIM green दिखाता है। यह वह artifact है जिसकी उन्हें cyber-insurance renewal और अगली supplier security questionnaire के लिए जरूरत होगी — “मैंने DNS thing fix किया” और documented before-and-after के बीच का अंतर जो कहता है domain अपना mail authenticate करता है।

अपना डोमेन जांचें → · “Body hash did not verify” guide → · DKIM ठीक करें → · हम ग्रेड कैसे करते हैं → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।