"توقيع DKIM غير صالح" — الأسباب بترتيب الفحص (2026)

نُشر 2026-07-08

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

“توقيع DKIM غير صالح” له خمسة أسباب شائعة، يُستحسن فحصها بالترتيب: محتوى مُعدَّل في العبور، سجل مفتاح مبتور، مفتاح منشور لا يتطابق مع الموقِّع، مُحدِّد خاطئ، وcanonicalization هش. 10,092,481 فقط من 261,086,232 نطاقاً مُصنَّفاً (3.87%) يحمل ثلاثية SPF+DKIM+DMARC المُطبَّقة الكاملة، وفقاً لإحصاء Defaults.Exposed (2026-06-29).

ترتيب الإصلاح مهم لأن السبب الأشيع ليس في DNS أصلاً. افحص أولاً ما عدَّل الرسالة في العبور، ثم اعمل للداخل: سلامة سجل المفتاح، هل يتطابق مع ما يُوقِّع به خادم البريد فعلاً، المُحدِّد، وأخيراً إعدادات التوقيع. معظم التواقيع غير الصالحة تُصلَح في الخطوة الأولى أو الثانية.

ماذا يعني “توقيع DKIM غير صالح” فعلاً؟

كل رسالة موقَّعة بـ DKIM تحمل ترويسة DKIM-Signature تُسمِّي نطاقاً (d=) ومُحدِّداً (s=) وhash لجسم الرسالة (bh=) وتوقيعاً تشفيرياً على hash الجسم بالإضافة إلى ترويسات مختارة (b=). يجلب المستقبِل مفتاحك العام من DNS على <selector>._domainkey.<domain>، يُعيد حساب كلا الـ hash، ويتحقق من التوقيع (RFC 6376). “التوقيع غير صالح” هو صياغة المدقِّق والترويسة لـ: ذلك التحقق جرى وفشل — المفتاح وُجد لكن الرياضيات لم تنجح.

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

إتقان هذا نادر: 51.84% فقط من النطاقات المُصنَّفة تنشر مفتاح DKIM قابلاً للاكتشاف في DNS أصلاً، وفقاً لإحصاء Defaults.Exposed، و3.87% فقط من 261 مليون نطاق مُصنَّف يجمع SPF وDKIM وسياسة DMARC مُطبَّقة — الإعداد الذي تفترضه قواعد المرسلين بالجملة الآن. الصورة المرحلية موجودة في نموذج نضج اعتماد SPF.

ما الأسباب الخمسة بالترتيب؟

#	السبب	الدليل	الإصلاح
1	محتوى مُعدَّل في العبور — تذييلات البوابة، إخلاءات المسؤولية القانونية، وسوم موضوع القوائم	`body hash did not verify` في Authentication-Results؛ البريد الخارجي يفشل، المباشر ينجح	*وقِّع بعد* التعديل، أو أوقف التعديل — انظر دليل body-hash**
2	مفتاح طويل مبتور أو مشوَّه	`p=` المنشور أقصر بوضوح من المفتاح الذي أنشأته؛ كل مستقبِل يفشل	أعد نشر مفتاح RSA 2048-bit بصورة صحيحة كسلاسل TXT مقسَّمة
3	المفتاح المنشور لا يتطابق مع الموقِّع	تبدأ الأخطاء فور تدوير أو ترحيل أو تغيير مزوّد	أعد نسخ السجل الحالي من لوحة إدارة موقِّعك؛ فضّل تفويض CNAME
4	مُحدِّد خاطئ أو مفقود	`no key for signature` — الاستعلام نفسه يفشل	انشر المُحدِّد الذي يستخدمه الموقِّع فعلاً — انظر دليل المُحدِّد
5	canonicalization هش أو وسم `l=`	أخطاء متقطعة على رسائل مُعاد تنسيقها بشكل تافه	`c=relaxed/relaxed`؛ أزل `l=` كلياً

السبب 1 بالخط العريض لأنه يكسر التواقيع على رسائل وُقِّعت بشكل مثالي. بوابة أمان تُلصق إخلاءاً، تذييل امتثال يُختم بعد التوقيع، قائمة بريدية تُضيف [listname] إلى الموضوع — الجسم أو الترويسات الموقَّعة تتغير، الـ hashes لم تعد تتطابق، والتوقيع غير صالح دون خطأ في DNS. إن ارتبطت الأخطاء ببريد مرَّ عبر بوابة أو قائمة أو وقفة أرشفة، ابدأ هناك.

كيف أُصلح “توقيع DKIM غير صالح”؟

شغّل الفحص المجاني على defaults.exposed قبل أن تلمس DNS. يُظهر هل سجل مفتاحك المنشور موجود وصحيح التنسيق ومكتمل — يفصل “DNS لديك معطوب” (الأسباب 2-4) من “DNS سليم لكن الرسالة تتغير” (السبب 1) في خطوة واحدة.
اقرأ ترويسة Authentication-Results لرسالة فاشلة. body hash did not verify ← السبب 1، اذهب إلى دليل body-hash — المشتبه بهم المعتادون هم تذييلات البوابة وإخلاءات المسؤولية، والإصلاح هو التوقيع بعد التعديل. no key for signature ← السبب 4، اذهب إلى دليل المُحدِّد. فشل توقيع عادي ← تابع.
تحقق من المفتاح المنشور من حيث الاقتطاع. ابحث عن <selector>._domainkey.<yourdomain> كـ TXT (dig TXT selector._domainkey.example.com). مفتاح RSA عام 2048-bit أطول من الحد البالغ 255 حرفاً لسلسلة TXT واحدة، لذا يجب نشره كسلاسل منقّطة متعددة يجمعها المستقبِلون — وواجهات مزوّدي DNS على الويب مشهورة بقطع اللصق بصمت وتشويه التقسيم وإدراج مسافات بيضاء وعلامات اقتباس في قيمة p=. قارن حرفاً بحرف مع المفتاح الذي أنشأه موقِّعك؛ أدلة إعداد DKIM تُغطي تفاصيل كل مزوّد.
تأكد أن المفتاح المنشور يتطابق مع الموقِّع. بعد تدوير مفتاح أو ترحيل مزوّد أو إعادة ربط ESP، من الشائع أن يحمل الموقِّع مفتاحاً خاصاً جديداً بينما DNS لا يزال يخدم المفتاح العام القديم — كل توقيع يتحقق مقابل المفتاح الخاطئ ويفشل. أعد نسخ السجل الحالي من لوحة إدارة مزوّدك. الأفضل: حيث يقدم المزوّد تفويض CNAME، استخدمه — المزوّد يُدوِّر المفاتيح من جانبه وتختفي هذه الفئة كلها من الأخطاء. ولا تحذف مُحدِّداً قديماً حتى يستنزف المرور الموقَّع به.
أصلح إعدادات التوقيع، لا السجل وحده. اضبط canonicalization على c=relaxed/relaxed، الذي يتسامح مع إعادة تغليف المسافات البيضاء وإعادة طي الترويسة التي تقوم بها الخوادم الوسيطة بشكل مشروع؛ canonicalization بـ simple يفشل على تغييرات لا يستطيع الإنسان رؤيتها. ولا تستخدم وسم l= لحجم الجسم: كان مقصوداً للسماح بالتذييلات، لكنه يسمح لـ أي أحد بإلحاق محتوى برسالتك الموقَّعة دون كسر التوقيع — ثغرة هجوم حقيقية — ومع ذلك لا يتغلب على معظم تعديلات البوابة. عدم استخدام l= هو الخيار الأكثر أماناً والأكثر موثوقية.
أعد الفحص ثم تحقق من التوافق. التوقيع الصالح يُساعد DMARC فقط إن توافق نطاق d= مع نطاق From — توقيع يتحقق كـ d=yourcompany.gappssmtp.com ينجح في DKIM ويفشل في DMARC. إن كنت في هذا الوضع، انظر فخ التوقيع الافتراضي، ثم اعمل على أي شيء آخر يُشير إليه الفحص في صفحة إصلاح DKIM.

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

هل “توقيع DKIM غير صالح” هو نفسه “body hash did not verify”؟ رسالة body-hash هي حالة فرعية محددة: تغيَّر الجسم بعد التوقيع (تذييلات، إخلاءات مسؤولية، إعادة كتابة القوائم). “التوقيع غير صالح” هو الحكم الشامل لأي تحقق فاشل، بما في ذلك المفاتيح الخاطئة وتغييرات الترويسة — ولهذا الخطوة 2 أعلاه هي قراءة الترويسة، ولهذا الحالة body-hash لها دليل خاص بها.

هل يعني توقيع DKIM غير الصالح أن بريدي مرفوض؟ ليس بذاته — المستقبِلون يُعاملون التوقيع المعطوب كالمفقود. الضرر يقع عبر DMARC: إن لم ينجح SPF مع التوافق أيضاً، تفشل الرسالة في DMARC وتُطبَّق سياستك المنشورة. بتاريخ إحصاء 2026-06-29، 3.87% فقط من 261,086,232 نطاق مُصنَّف يحمل SPF وDKIM وسياسة DMARC مُطبَّقة معاً — لكن Gmail وMicrosoft يتوقعان ذلك بالضبط من المرسلين، فركيزة DKIM المعطوبة تُكلّف التسليم حتى قبل الرفض.

هل أستخدم مفتاح DKIM 1024-bit أم 2048-bit؟ 2048-bit — مفاتيح 1024-bit أدنى من التوصيات التشفيرية الحالية وبعض المستقبِلين يُخفضون تقييمها. العائق عملياتي بحت: مفتاح 2048-bit لا يتسع في سلسلة TXT واحدة بـ 255 حرفاً، فيجب تقسيمه بشكل صحيح (السبب 2 أعلاه). تفويض CNAME إلى مزوّدك يتجاوز مشكلة التقسيم كلياً.

DKIM ينجح في المدقِّق لكن DMARC لا يزال يفشل — لماذا؟ على الأرجح التوافق: التوقيع يتحقق، لكن نطاق d= (مثلاً yourcompany.gappssmtp.com أو yourtenant.onmicrosoft.com) لا يتطابق مع نطاق From، فلا يستطيع DMARC استخدامه. فعّل توقيع النطاق المخصص لمزوّدك — التفصيل الكامل في دليل فخ التوقيع الافتراضي.

هل يمكنني إيقاف DKIM إن ظل يفشل؟ لا — منذ متطلبات المرسلين بالجملة 2024، تشترط Gmail وYahoo DKIM للمرسلين بحجم كبير، وسياسة DMARC المُطبَّقة تحتاج DKIM واقعياً لأن SPF وحده ينكسر تحت التوجيه. أصلح التوقيع؛ الأسباب أعلاه كلها قابلة للإصلاح في فترة ما بعد الظهر.

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

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

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