DKIM "لا مفتاح للتوقيع": إصلاحات المُحدِّد والتدوير (2026)

نُشر 2026-07-08

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

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

الإصلاح: سجل DNS واحد موجود في ترويسة واحدة. اقرأ وسمَي s= وd= من ترويسة DKIM-Signature حقيقية لمعرفة أي مُحدِّد يُوقَّع به بريدك، وانشر (أو أصلح) ذلك السجل تحديداً، وفضّل تفويض CNAME ليتدوّر المزوّد المفاتيح نيابةً عنك. ثم دوّر وفق الإجراء أدناه — هذا الخطأ يعني عادةً أن أحدهم حذف مُحدِّداً قديماً مبكراً.

ماذا يعني “dkim no key for signature”؟

يحمل كل توقيع DKIM وسمَين يُخبران المستقبِل أين يجلب المفتاح العام: d= (نطاق التوقيع) وs= (المُحدِّد). يستعلم المستقبِل عن اسم DNS واحد مبني منهما — s._domainkey.d — للحصول على المفتاح. “لا مفتاح للتوقيع” يعني أن الاستعلام عاد فارغاً: التوقيع موجود لكن المفتاح الذي يُسمّيه غائب.

تظهر الصياغة في ترويسات Authentication-Results وتقارير DMARC المجمَّعة — الصياغة الدقيقة تختلف بحسب المستقبِل، لكن صيغتَين مهمتان:

سلسلة النتيجة (مقطع كما يُلاحظ على نطاق واسع)	ما حدث فعلاً	مؤقت؟
`dkim=temperror (no key for signature)`	استعلام DNS فشل أو انتهت مهلته — المستقبِل لم يحصل على إجابة أصلاً	نعم — الإعادة كثيراً ما تنجح؛ حقّق فقط إن تكرر
`dkim=permerror (no key for signature)`	الاستعلام نجح والإجابة “لا يوجد سجل” — المُحدِّد غائب فعلاً	لا — السجل مفقود حتى تنشره

خطأ temperror لمرة واحدة هو “طقس DNS”. خطأ permerror — أو temperror يتكرر عبر أيام ومستقبِلين — يعني أن السجل الذي يشير إليه التوقيع ليس في منطقتك. هذا ما يُعالجه هذا الدليل.

النتيجة: التوقيع غير القابل للتحقق يُعامَل كأنه لا DKIM أصلاً، فيعتمد DMARC على SPF وحده — وSPF ينكسر تحت التوجيه. إن كان التوقيع موجوداً لكن غير صالح لا مفقوداً (hash الجسم، مفتاح مشوَّه)، فتلك حالة مختلفة — انظر “توقيع DKIM غير صالح”.

كيف أجد أي مُحدِّد يُوقَّع به بريدي؟

لا تخمّن من وثائق مزوّدك — اقرأه من رسالة حقيقية:

أرسل رسالة من النظام المتأثر إلى صندوق بريد تتحكم فيه (عنوان Gmail مناسب).
افتح المصدر الخام (“عرض الأصل” في Gmail، “عرض مصدر الرسالة” في Outlook).
ابحث عن ترويسة DKIM-Signature: واقرأ وسمَين: s= هو المُحدِّد، d= هو نطاق التوقيع. مثال توضيحي: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
السجل الذي يستعلمه المستقبِل هو s._domainkey.d — هنا mail2026._domainkey.yourdomain.com. تحقق بنفسك: dig TXT mail2026._domainkey.yourdomain.com +short. إجابة فارغة = الخطأ حقيقي لكل مستقبِل.
كرر لكل نظام إرسال. الرسالة قد تحمل توقيعات DKIM متعددة — مزوّد صندوق البريد، أداة النشرة، مكتب المساعدة — لكل منها زوج s=/d= وسجل خاص. أصلح الفاشل منها، ولاحظ d= خاصته: التوقيع الذي يُساعد DMARC هو الذي يتوافق d= فيه مع نطاق From.

لماذا سجل المُحدِّد مفقود؟

أربعة أسباب تُفسر معظم هذه الأخطاء — افحصها بهذا الترتيب:

لم يُنشر قط. شُغِّل الموقِّع (أو فُعِّل بالإعداد الافتراضي) بمُحدِّد لم يُضفه أحد إلى DNS. شائع مع الأدوات والبوابات الجديدة التي تُوقِّع دون توقع.
حُذف في منتصف التدوير. “نظَّف” أحدهم المُحدِّد القديم فيما الرسائل الموقَّعة به لا تزال في المسار أو طابور الإعادة أو تنتظر التوجيه. تلك الرسائل مُوقَّعة بالفعل بـ s=old؛ حذف old._domainkey يُعطل جميعها بأثر رجعي.
لوحة DNS شوَّهت هدف CNAME. كثير من المزوّدين يُفوِّضون عبر CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com)، وكثير من لوحات DNS تُلصق منطقتك بالهدف بصمت — فيصير s1.domainkey.u123.esp.com.yourdomain.com، الذي لا يُحلّ إلى شيء. تحقق من الهدف: dig CNAME s1._domainkey.yourdomain.com +short. الفخ نفسه يلدغ عند ترحيل الأدوات — انظر DKIM الفاشل بعد التبديل.
دوَّر المزوّد ومنطقتك لم تتابع. مفتاح المزوّد الملصوق كسجل TXT ثابت (بدلاً من CNAMEs) يُصبح يتيماً بتدوير المزوّد المجدول — ينتقل الموقِّع إلى مُحدِّد لم تنشره قط. 51.84% فقط من 261 مليون نطاق في الإحصاء يُقدِّم مفتاح DKIM قابلاً للاكتشاف وقت الفحص (البيانات بتاريخ 2026-06-29).

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

شغّل الفحص المجاني على defaults.exposed قبل أن تلمس DNS. يقرأ سجلات DKIM وSPF وDMARC الحية ويُظهر ما يراه المستقبِلون فعلاً — بما في ذلك هل يُحلّ المُحدِّد وهل تشوَّه هدف CNAME.
انشر المُحدِّد الذي يستخدمه الموقِّع فعلاً — قيمة s= من الترويسة لا من إجراء عمل قديم. احصل على السجل من لوحة إدارة مزوّدك (إعداد Google Workspace DKIM · إعداد Microsoft 365 DKIM) وأضفه بالضبط على s._domainkey.yourdomain.com.
فضّل تفويض CNAME على لصق مفتاح TXT. إن كان مزوّدك يقدم CNAME لـ DKIM، استخدمه: المفتاح يقيم في منطقتهم فيُدوِّرونه دون أن تلمس DNS مجدداً — السبب 4 يصبح مستحيلاً. معظم منصات النشرات تعمل هكذا؛ انظر رسائل Mailchimp/Brevo/Klaviyo الفاشلة في DMARC.
تحقق من خارج لوحتك. dig TXT s._domainkey.yourdomain.com +short (أو dig CNAME … للمُحدِّدات المُفوَّضة) من جهاز خارج شبكتك. اللوحة التي تُظهر السجل لا تُثبت شيئاً إن كانت المنطقة تخدم شيئاً آخر.
أعد الفحص وأعد إرسال رسالة اختبار. يجب أن تقرأ Authentication-Results الآن dkim=pass. ثم اعمل على أي شيء آخر يُشير إليه الفحص في صفحة إصلاح DKIM — توقيع ناجح لا يتوافق مع نطاق From لا يزال يُخفق في DMARC.

كيف أُدوِّر مفاتيح DKIM دون أن أتسبب في هذا الخطأ؟

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

الخطوة	الإجراء	الشرط قبل الخطوة التالية
1. أضف	انشر المُحدِّد الجديد (`s2._domainkey…`) جانباً للقديم	`dig` يُؤكد حله من الخارج
2. بدِّل	وجِّه الموقِّع إلى المُحدِّد الجديد	رسالة اختبار تُظهر `s=s2` و`dkim=pass`
3. انتظر	ابقِ المُحدِّد القديم منشوراً حتى يستنزف المرور المعلَّق والمُعاد توجيهه	≥ 7 أيام؛ راقب تقارير DMARC المجمَّعة حتى يتوقف ظهور المُحدِّد القديم
4. أبطل	احذف المفتاح القديم — أو الأفضل أعد نشره بوسم `p=` فارغ: “مُبطَل” لا “غير موجود أبداً”	لا تبدأ هذا عند الإطلاق — الحذف المبكر هو السبب الأول لـ “لا مفتاح للتوقيع”

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

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

هل “لا مفتاح للتوقيع” temperror أم permerror؟ كلا الصيغتين موجودتان: temperror هو استعلام DNS فشل أو انتهت مهلته — مؤقت يختفي كثيراً عند الإعادة — بينما permerror يعني أن DNS أجاب بـ “لا يوجد سجل”. temperror يتكرر عبر مستقبِلين عادةً ما يكون سجلاً مفقوداً فعلاً. تحقق بـ dig وثق الإجابة لا التسمية.

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

هل يمكنني حذف المُحدِّد القديم بمجرد نجاح الجديد؟ ليس فوراً. الرسائل الموقَّعة به لا تزال في طوابير الإعادة ومسارات التوجيه؛ حذف المفتاح يُعطلها بأثر رجعي. ابقِ السجل القديم أسبوعاً على الأقل، راقب تقارير DMARC حتى يتوقف ظهور المُحدِّد القديم، ثم أبطله — مثالياً بـ p= فارغ لا بالحذف.

أداة التحقق لدى مزوّدي تقول DKIM مُهيَّأ، لكن المستقبِلين لا يزالون يُبلِّغون عن غياب مفتاح. كيف؟ في كل الأحوال تقريباً فخ هدف CNAME: لوحة DNS الخاصة بك ألصقت منطقتك بالهدف (…esp.com.yourdomain.com) فالسجل موجود لكنه لا يُشير لشيء. dig CNAME selector._domainkey.yourdomain.com +short يُظهر الهدف المُخزَّن كما هو — قارنه حرفاً بحرف بما طلبه المزوّد.

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

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

افحص DKIM مجاناً

اعرف هل يُحلّ مُحدِّدك — وما الذي يجب إصلاحه بالضبط — بخصوصية تامة ومقتصرة على المالك.

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