DKIM 'Body Hash Did Not Verify' — क्या बदला आपके संदेश को, और इसे कैसे ठीक करें (2026)

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

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

“Body hash did not verify” का मतलब है कि आपका DKIM सिग्नेचर आपसे जाते समय valid था — और किसी चीज ने बाद में message body को फिर से लिखा। सिग्नेचर टूटा नहीं है; संदेश ट्रांजिट में modified हुआ। केवल 3.87% डोमेन — 10,092,481 — 261,086,232 डोमेन की Defaults.Exposed जनगणना (2026-06-29) के अनुसार पूरा SPF-DKIM-DMARC triad पूरा करते हैं।

फिक्स एक खोज है, फिर एक निर्णय। वह hop खोजें जो आपका मेल modify करता है — एक gateway जो disclaimer जोड़ता है, एक appliance जो links को rewrite करता है, एक mailing list जो footer जोड़ती है। फिर उस hop के बाद साइन करें, modification रोकें, या सिग्नेचर को इसे tolerate करने योग्य बनाएं — इसी क्रम में।

“Body hash did not verify” का वास्तव में क्या मतलब है?

एक DKIM सिग्नेचर (RFC 6376) दो hashes ले जाता है: bh=, message body का hash जैसा साइन किया गया था, और b=, जो body hash plus चुने गए headers को साइन करता है। Verifier received message से body hash को recompute करता है; यदि यह bh= से मेल नहीं खाता, verification उस string के साथ रुकती है जिसे हर कोई सर्च बॉक्स में पेस्ट करता है — एक receiver header जैसे:

Authentication-Results: …; dkim=fail (body hash did not verify)

यह Microsoft की documented reason string है; Gmail अक्सर उसी diagnosis को dkim=neutral (body hash did not verify) के रूप में render करता है। किसी भी तरह, verdict समस्या को काफी narrow कर देता है। आपकी DNS key, selector, और signing configuration सभी ठीक हैं। cryptography ने अपना काम किया: signing और verification के बीच body बदल गई — एक appended line, एक rewritten URL, एक re-encoded character काफी है। (एक अलग message — signature did not verify, no key for signature — एक अलग failure का मतलब है; “DKIM signature not valid” से शुरू करें।) और यह urgent है क्योंकि एक failed signature DMARC को aligned pass नहीं दे सकता: जब तक उसी संदेश पर SPF alignment के साथ pass नहीं करता, mail DMARC outright fail करता है।

क्या बदला आपका संदेश? सामान्य संदिग्ध

delivery path में कुछ ने body को आपके signer द्वारा seal करने के बाद edit किया। व्यवहार में यह चार में से एक चीज है:

किसने modify किया	वे क्या बदलते हैं	Typical tell
Outbound gateway / smart host (Exchange transport rules, Mimecast, Proofpoint, Barracuda…)	Mail server के already sign करने के बाद legal disclaimer, marketing footer, या “EXTERNAL:” banner जोड़ता है	उस route पर हर message fail; gateway bypass करने वाले direct sends pass
Security appliance / link protection	URLs को scanning redirects पर rewrite करता है, tracking wrappers जोड़ता है	केवल links वाले messages fail
Mailing list (Google Groups, Mailman…)	Subject tag और list footer जोड़ती है, कभी-कभी body reflows	केवल list के जरिए भेजा गया mail fail
Forwarder / relay re-encoding MIME	Charset transcode करता है, lines re-wrap करता है — मानव को invisible, hash के लिए fatal	Failures एक recipient या forwarding address पर cluster होते हैं

Bold row पहले जांचें — mail server साइन करता है, edge device edit करता है, और हर message एक सिग्नेचर के साथ जाता है जो तीस milliseconds के लिए सही था।

मैं वह hop कैसे खोजूं जो मेरा mail modify कर रहा है?

Differential diagnosis — एक working path की एक failing path से तुलना करें:

एक mailbox पर एक direct test message भेजें जिसे आप नियंत्रित करते हैं एक major receiver पर (Gmail अच्छा काम करता है), अपनी outbound chain के जितना हो सके bypass करते हुए।
Failing path के साथ एक दूसरा message भेजें — gateway के जरिए, list के जरिए, affected recipient के डोमेन पर।
दोनों full headers में Authentication-Results lines की तुलना करें। Direct send dkim=pass, failing path dkim=fail (या dkim=neutral) with body hash did not verify: modifier उन दो routes के बीच रहता है।
Received body देखें: एक disclaimer, banner, या footer जो आपने type नहीं की? Links किसी scanning domain पर rewrite? वह आपका hop है, नामित — और Received: chain दिखाती है कि कौन सा relay केवल failing path में दिखता है।

आपकी DMARC aggregate reports बड़े पैमाने पर वही कहानी बताती हैं: एक source लगातार SPF pass के साथ DKIM fail report करता है आमतौर पर modification-in-transit है आपके अपने route पर, कोई attacker नहीं।

मैं इसे कैसे ठीक करूं?

कुछ भी छूने से पहले defaults.exposed पर मुफ़्त स्कैन चलाएं। यह पुष्टि करता है कि आपके published DKIM keys और DMARC policy सही हैं, ताकि आप एक असली समस्या — modification — debug कर रहे हों, DNS में ghosts का पीछा नहीं। DKIM ठीक करें पेज record-side checks कवर करता है।
Modifying hop के बाद साइन करें। Architecturally सही fix: DKIM signing को उस सबसे बाहरी डिवाइस पर ले जाएं जो संदेश को छूता है। Exchange-plus-gateway shops को gateway पर साइन करना चाहिए (Mimecast, Proofpoint और peers सभी इसे support करते हैं) और upstream signing बंद करना चाहिए। यदि Google Workspace या Microsoft 365 आपका last hop है, वहां साइन करें और कुछ भी मेल edit न करें — Google Workspace पर DKIM सेट करें या Microsoft 365 देखें।
या modification रोकें। Edit को transport path से हटाएं: disclaimer client signature या template में, transport rule में नहीं; “EXTERNAL:” banner केवल inbound mail के लिए scoped (अपने outbound mail को external tag करना दो बार misconfiguration है); authenticated outbound mail link-rewriting से exempt।
relaxed/relaxed canonicalization (c=relaxed/relaxed) उपयोग करें। simple body canonicalization एक single re-wrapped line पर fail; relaxed whitespace और line-ending changes को tolerate करता है। limit के बारे में honest रहें: relaxed formatting को forgive करता है, कभी content को नहीं — एक appended footer अभी भी fail, जैसा होना चाहिए।
दोनों paths को re-test करें, फिर re-scan करें। दोनों routes अब dkim=pass दिखाने चाहिए आपके डोमेन के साथ d= में, और scan report clean होनी चाहिए।

क्या मुझे l= tag का उपयोग करना चाहिए ताकि DKIM appended content को ignore करे?

नहीं — और किसी भी guide से सावधान रहें जो इसका सुझाव देती है। l= tag केवल body के पहले N bytes को hash करता है, इसलिए एक appended footer अब signature को नहीं तोड़ता। यह “काम करता है” आपके message के अंत को unsigned छोड़कर: कोई भी व्यक्ति जो एक legitimate signed message रखता है arbitrary content append कर सकता है और आपका valid signature अभी भी result पर verify होता है। यह spoofing hole है जो fix के कपड़े पहने है — practical abuse demonstrate किया गया है, और कुछ receivers बिल्कुल इसी कारण l= को penalize या ignore करते हैं। Modification solve करें; अपने mail के किसी हिस्से को unsigned न करें।

Mailing lists के बारे में क्या — क्या मैं उन्हें ठीक कर सकता हूं?

अधिकतर, नहीं — और यह जानना आपके हफ्ते बचाता है। एक list जो subject tag या footer जोड़ती है आपके body hash को design से तोड़ती है, और आप list को नियंत्रित नहीं करते। दो चीजें मदद करती हैं:

यही वह है जिसके लिए DMARC rollout staged है। p=none से p=quarantine की ओर pct= ramp के साथ, aggregate reports पढ़ते हुए, मतलब list-mangled messages quarantine में जाते हैं बजाय destroy होने के जबकि आप impact assess करते हैं — p=none से p=reject बिना legitimate email खोए का विषय।
ARC receiver का mechanism है, आपका नहीं। Authenticated Received Chain list को बताने देता है कि arrival पर authentication कैसा दिखा और receiver decide करने देता है कि इस पर trust करे या नहीं। आपके लिए, sender के रूप में, configure करने के लिए कुछ नहीं है। अच्छी तरह से चलाई जाने वाली lists From header rewriting करके mitigate करती हैं; खराब चलाई जाने वाली बस आपका mail तोड़ती हैं।

Forwarding adjacent case है — यह reliably SPF तोड़ता है लेकिन केवल कभी-कभी DKIM, यही कारण है कि aligned DKIM आपका forwarding-proof leg है जब body survive करती है: forwarded email SPF fail करता है — आप इसे क्यों नहीं ठीक कर सकते देखें।

DKIM इतनी बार क्यों टूटता है जबकि बहुत कम डोमेन के पास पूरा stack है?

क्योंकि DKIM triad का fragile middle child है: SPF एक static DNS record है, DMARC एक policy statement, लेकिन DKIM को journey survive करनी होती है। केवल 51.84% ग्रेडेड डोमेन scan time पर DNS में एक discoverable DKIM key publish करते हैं, Defaults.Exposed जनगणना के अनुसार, और केवल 10,092,481 डोमेन — 3.87% of 261,086,232 graded — SPF, DKIM और एक enforcing DMARC policy एक साथ रखते हैं (SPF adoption maturity model सीढ़ी को break down करता है)। इस fix को सही करना उस 3.87% में शामिल होने का सबसे कठिन हिस्सा है।

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

क्या “body hash did not verify” कोई मेरे डोमेन को spoof कर रहा है इसका संकेत है? आमतौर पर नहीं — एक spoofer आमतौर पर आपका DKIM सिग्नेचर बिल्कुल नहीं बना सकता, इसलिए उनके mail में कोई सिग्नेचर या no key नहीं दिखता। एक failed body hash का मतलब है कि आपके infrastructure द्वारा genuinely signed एक message को बाद में edit किया गया। किसी attacker का अनुमान लगाने से पहले अपना gateway check करें।

इन messages पर SPF pass होता है — क्या मैं अभी भी OK हूं? अभी के लिए, शायद: DMARC को केवल एक aligned pass चाहिए। लेकिन SPF का pass उस क्षण वाष्पित हो जाता है जब कोई message forward करता है, और यदि यह आपके From domain के साथ aligned नहीं है तो यह कभी भी DMARC के लिए count नहीं हुआ। केवल 3.87% डोमेन के पास पूरा triad है (2026-06-29 जनगणना of 261,086,232 domains), “एक leg limping” सामान्य अवस्था है — और fixable।

क्या relaxed/relaxed canonicalization पर switch करने से मेरी disclaimer समस्या ठीक होगी? नहीं। Relaxed केवल whitespace और line-wrapping changes को tolerate करता है। एक appended disclaimer एक content change है, और hash को इस पर fail करना चाहिए — वह DKIM सही तरीके से काम कर रहा है। Signing point या disclaimer move करें।

Failure केवल एक customer के डोमेन पर होती है। क्यों? उनकी side लगभग निश्चित रूप से inbound mail modify करती है — एक security appliance links rewrite करता है या banners stamp करता है उनके verifier के run होने से पहले, या एक internal forward body को re-encode करता है। उन्हें इस पेज का diagnosis section भेजें; fix उनके gateway पर है, आपके DNS में नहीं।

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

यदि आप किसी client या नियोक्ता के लिए यह ठीक कर रहे हैं, evidence के साथ loop close करें। एक बार modifying hop fix हो जाए, मुफ़्त स्कैन फिर से चलाएं और graded report business owner को forward करें: dated, plain-language, DKIM और DMARC एक पेज पर standing। यह वह artifact है जिसकी उन्हें cyber-insurance renewal और अगली supplier questionnaire के लिए जरूरत होगी — proof कि company छोड़ने वाला mail वही mail है जो arrive होता है।

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