DKIM "لم يتحقق body hash" — ما الذي غيَّر رسالتك، وكيف تُصلح ذلك (2026)

نُشر 2026-07-08

الأرقام بتاريخ 2026-06-29 · المنهجية v7. بيانات إحصاء مجمّعة عبر 261 مليون نطاق مُصنَّف. اطلع على طريقة التصنيف.

“لم يتحقق body hash” يعني أن توقيع DKIM كان صالحاً حين غادرت الرسالة — وشيء ما أعاد كتابة جسم الرسالة بعد ذلك. التوقيع ليس معطوباً؛ الرسالة عُدِّلت في العبور. 3.87% فقط من النطاقات — 10,092,481 — يُكمل ثلاثية SPF-DKIM-DMARC الكاملة، وفقاً لإحصاء Defaults.Exposed لـ 261,086,232 نطاق (2026-06-29).

الإصلاح: بحث ثم قرار. ابحث عن النقطة التي تُعدِّل بريدك — بوابة تُلصق إخلاءاً، جهاز يُعيد كتابة الروابط، قائمة بريدية تُضيف تذييلاً. ثم وقِّع بعد تلك النقطة، أو أوقف التعديل، أو اجعل التوقيع متسامحاً معه — بهذا الترتيب.

ماذا يعني “body hash did not verify” فعلاً؟

يحمل توقيع DKIM (RFC 6376) hash-ين: bh=، وهو hash جسم الرسالة كما وُقِّع، وb=، الذي يُوقِّع الترويسات بالإضافة إلى hash الجسم. يُعيد المتحقق حساب hash الجسم من الرسالة التي استلمها؛ إن لم يتطابق مع bh=، يتوقف التحقق بالسلسلة التي يلصقها الجميع في محرك بحث — ترويسة مستقبِل مثل:

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

هذه سلسلة السبب الموثَّقة لـ Microsoft؛ Gmail كثيراً ما يعرض نفس التشخيص كـ dkim=neutral (body hash did not verify). في كلتا الحالتَين، الحكم يُضيِّق المشكلة بشكل كبير. مفتاح DNS والمُحدِّد وإعداد التوقيع كلها سليمة. التشفير أدى وظيفته: تغيَّر الجسم بين التوقيع والتحقق — سطر واحد مُلحَق، رابط واحد مُعاد كتابته، حرف واحد مُعاد ترميزه يكفي. (رسالة مختلفة — signature did not verify، no key for signature — تعني فشلاً مختلفاً؛ ابدأ بـ”توقيع DKIM غير صالح”.) وهو عاجل لأن التوقيع الفاشل لا يُعطي DMARC تجاوزاً متوافقاً: ما لم ينجح SPF مع التوافق في نفس الرسالة، تفشل الرسالة في DMARC كلياً.

ما الذي غيَّر رسالتك؟ المشتبه بهم المعتادون

شيء ما في مسار التسليم حرَّر الجسم بعد أن ختمه موقِّعك. في الواقع العملي هو واحد من أربعة:

من عدَّله	ما يغيّره	الدليل الدال
بوابة صادرة / smart host (Exchange transport rules, Mimecast, Proofpoint, Barracuda…)	يُلصق إخلاء المسؤولية القانوني أو تذييل التسويق أو شارة “EXTERNAL:” بعد أن يكون خادم البريد قد وقَّع	كل رسالة في ذلك المسار تفشل؛ الإرسال المباشر متجاوزاً البوابة ينجح
جهاز أمان / حماية الروابط	يُعيد كتابة URLs إلى توجيهات فحص، يُضيف أغلفة تتبع	فقط الرسائل التي تحتوي روابط تفشل
قائمة بريدية (Google Groups, Mailman…)	تُضيف وسم موضوع وتذييل قائمة، أحياناً تُعيد تدفق الجسم	فقط البريد المرسَل عبر القائمة يفشل
مُعيد توجيه / مُرحِّل يُعيد ترميز MIME	يُحوِّل مجموعة الأحرف، يُعيد لفّ الأسطر — غير مرئي للإنسان، قاتل للـ hash	تتمركز الأخطاء على متلقٍّ أو عنوان توجيه واحد

افحص السطر بالخط العريض أولاً — خادم البريد يُوقِّع، الجهاز الطرفي يُحرِّر، وكل رسالة تغادر بتوقيع كان صحيحاً لثلاثين ثانية صغيرة.

كيف أجد النقطة التي تُعدِّل بريدي؟

تشخيص تفاضلي — قارن مساراً ناجحاً مقابل المسار الفاشل:

أرسل رسالة اختبار مباشرة إلى صندوق بريد تتحكم فيه على مستقبِل كبير (Gmail مناسب)، متجاوزاً أكبر قدر ممكن من سلسلتك الصادرة.
أرسل رسالة ثانية عبر المسار الفاشل — عبر البوابة، عبر القائمة، إلى نطاق المتلقي المتأثر.
قارن أسطر Authentication-Results في كلا الترويستَين الكاملتَين. الإرسال المباشر dkim=pass، المسار الفاشل dkim=fail (أو dkim=neutral) مع body hash did not verify: المُعدِّل يقيم بين المسارَين.
انظر إلى الجسم المستلم: إخلاء مسؤولية أو شارة أو تذييل لم تكتبه؟ روابط مُعادة كتابتها إلى نطاق فحص؟ هذه نقطتك، مسمَّاة — وسلسلة Received: تُظهر أي مُرحِّل يظهر فقط في المسار الفاشل.

تقارير DMARC المجمَّعة تحكي القصة ذاتها على نطاق واسع: مصدر يُبلِّغ باستمرار عن فشل DKIM مع نجاح SPF هو عادةً تعديل أثناء العبور على مسارك الخاص، لا مهاجم.

كيف أُصلح ذلك؟

شغّل الفحص المجاني على defaults.exposed قبل أن تلمس أي شيء. يُؤكد سلامة مفاتيح DKIM المنشورة وسياسة DMARC، فتُشخِّص المشكلة الحقيقية الواحدة — التعديل — لا تُطارد أشباحاً في DNS. صفحة إصلاح DKIM تُغطي فحوصات جانب السجل.
وقِّع بعد نقطة التعديل. الإصلاح المعماري الصحيح: انقل توقيع DKIM إلى الجهاز الأبعد الذي يلمس الرسالة. منظومات Exchange-plus-gateway يجب أن تُوقِّع عند البوابة (Mimecast وProofpoint وأقرانها تدعم ذلك) وتُعطّل التوقيع في المراحل السابقة. إن كانت Google Workspace أو Microsoft 365 نقطتك الأخيرة، وقِّع هناك ودع لا شيء يُحرِّر البريد بعدها — انظر إعداد DKIM على Google Workspace أو Microsoft 365.
أو أوقف التعديل. انزع التحرير من مسار النقل: إخلاء المسؤولية في توقيع العميل أو القالب بدلاً من transport rule؛ شارة “EXTERNAL:” مقتصرة على البريد الوارد فقط (وسم بريدك الصادر بـ “خارجي” هو خطأ تهيئة مرتَّين)؛ البريد الصادر الموثَّق مستثنى من إعادة كتابة الروابط.
استخدم canonicalization بـ relaxed/relaxed (c=relaxed/relaxed). canonicalization الجسم بـ simple يفشل على سطر واحد مُعاد لفّه؛ relaxed يتسامح مع المسافات البيضاء وتغييرات نهايات الأسطر. كن صريحاً بشأن الحد: relaxed يتسامح مع التنسيق، لا المحتوى أبداً — تذييل مُلصَق لا يزال يفشل، وهذا صواب.
أعد اختبار كلا المسارَين ثم أعد الفحص. يجب أن يُظهر كلا المسارَين الآن dkim=pass مع نطاقك في d=، وتقرير الفحص يجب أن يكون نظيفاً.

هل أستخدم وسم l= لجعل DKIM يتجاهل المحتوى المُلحَق؟

لا — وكن حذراً من أي دليل يقترح ذلك. يُجزِّئ وسم l= أول N بايت فقط من الجسم، فلا يكسر التذييل المُلصَق التوقيعَ بعد ذلك. “يعمل” بترك نهاية رسالتك غير موقَّعة: أي شخص يحمل رسالة موقَّعة مشروعة يستطيع إلحاق محتوى تعسفي وتوقيعك الصالح لا يزال يتحقق على النتيجة. هذه ثغرة تزوير تلبس لباس إصلاح — ثبُت استغلالها عملياً، وبعض المستقبِلين يعاقبون l= أو يتجاهلونه لهذا السبب بالذات. أصلح التعديل؛ لا تُلغِ توقيع جزء من بريدك.

ماذا عن القوائم البريدية — هل يمكنني إصلاح ذلك؟

في معظم الأحوال، لا — ومعرفة ذلك يوفر عليك أسابيع. قائمة تُضيف وسم موضوع أو تذييلاً تكسر hash الجسم بتصميم، ولا تتحكم في القائمة. شيئان يُساعدان:

هذا البقاء هو بالضبط سبب تدرج نشر DMARC. الانتقال من p=none عبر p=quarantine مع رفع تدريجي لـ pct=، مع قراءة التقارير المجمَّعة، يعني أن الرسائل المُشوَّهة بالقوائم تُعزَل لا تُتلَف بينما تُقيّم الأثر — موضوع من p=none إلى p=reject دون فقدان بريد شرعي.
ARC هو آلية المستقبِل لا آليتك. Authenticated Received Chain يتيح للقائمة الإيصاء بما كانت عليه المصادقة عند الوصول ولـالمستقبِل تقرير الثقة بذلك. لا شيء عليك أنت المُرسِل تهيئته. القوائم المُدارة جيداً تُخفف بإعادة كتابة ترويسة From؛ المُدارة سيئاً تُعطل بريدك ببساطة.

التوجيه هو الحالة المجاورة — يكسر SPF بشكل موثوق لكن DKIM أحياناً فقط، ولهذا DKIM المتوافق هو ركيزتك المقاومة للتوجيه حين يبقى الجسم سليماً: انظر البريد المُوجَّه يفشل في SPF — لماذا لا يمكنك إصلاحه.

لماذا يعطل DKIM كثيراً حين قلة من النطاقات تمتلك الحزمة الكاملة أصلاً؟

لأن DKIM هو الطفل الهش في الثلاثي: SPF سجل DNS ثابت، DMARC بيان سياسة، لكن DKIM يجب أن ينجو من الرحلة. 51.84% فقط من النطاقات المُصنَّفة تنشر مفتاح DKIM قابلاً للاكتشاف في DNS أصلاً، وفقاً لإحصاء Defaults.Exposed، و10,092,481 نطاقاً فقط — 3.87% من 261,086,232 مُصنَّف — يحمل SPF وDKIM وسياسة DMARC مُطبَّقة معاً (نموذج نضج اعتماد SPF يُفصِّل السلّم). إتقان هذا الإصلاح هو أصعب جزء في الانضمام إلى هذه الـ 3.87%.

الأسئلة الشائعة

هل “body hash did not verify” علامة على أن أحدهم يزيف نطاقي؟ في الغالب لا — المزيِّف عادةً لا يستطيع إنتاج توقيع DKIM الخاص بك أصلاً، فبريده يُظهر لا توقيع أو no key. hash جسم فاشل يعني أن رسالةً وقَّعها فعلاً بنيتك التحتية عُدِّلت بعد ذلك. افحص بوابتك الخاصة قبل أن تفترض وجود مهاجم.

SPF ينجح في هذه الرسائل — هل أنا بأمان؟ في الوقت الحالي ربما: DMARC يحتاج تجاوزاً متوافقاً واحداً فقط. لكن نجاح SPF يتبخر لحظة يُوجِّه أحد الرسالة، وإن لم يكن متوافقاً مع نطاق From فلم يُحتسَب لـ DMARC أصلاً. مع 3.87% فقط من النطاقات تحمل الثلاثي الكامل (إحصاء 2026-06-29 لـ 261,086,232 نطاق)، “ساق تعرج” هي الحالة المعتادة — والقابلة للإصلاح.

هل التبديل إلى canonicalization بـ relaxed/relaxed يُصلح مشكلة إخلاء المسؤولية؟ لا. relaxed يتسامح فقط مع تغييرات المسافات البيضاء والتفاف الأسطر. إخلاء مسؤولية مُلصَق هو تغيير محتوى، والـ hash يجب أن يفشل عليه — DKIM يعمل بشكل صحيح. انقل نقطة التوقيع أو انقل إخلاء المسؤولية.

الفشل يحدث فقط مع نطاق عميل واحد. لماذا؟ جانبهم على الأرجح يُعدِّل البريد الوارد — جهاز أمان يُعيد كتابة الروابط أو يُختم شارات قبل تشغيل المتحقق لديهم، أو توجيه داخلي يُعيد ترميز الجسم. أرسل لهم قسم التشخيص في هذه الصفحة؛ الإصلاح على بوابتهم، لا في DNS لديك.

أرسل للمالك التقرير

إن كنت تُصلح هذا لعميل أو صاحب عمل، أغلق الحلقة بالدليل. بمجرد إصلاح نقطة التعديل، أعد الفحص المجاني وأرسل التقرير المُصنَّف لصاحب العمل: مؤرَّخ، لغة بسيطة، DKIM وDMARC على صفحة واحدة. هذه هي الوثيقة التي يحتاجها لتجديد تأمين الإنترنت واستبيان المورد القادم — دليل أن البريد المغادر للشركة هو البريد الذي يصل.

افحص نطاقك ← · دليل “توقيع DKIM غير صالح” ← · إصلاح DKIM ← · طريقة التصنيف ← · بيانات إجمالية فقط. البيانات مخزّنة ومعالَجة في الاتحاد الأوروبي.