كيف تفحص DKIM لبريد التطبيقات؟

عامل فحص DKIM على أنه أربعة اختبارات منفصلة

استعلام DNS وحده لا يكفي لفحص DKIM كاملًا. أولًا، تأكد من أن الرسالة تحتوي على حقل DKIM-Signature وحدّد التوقيع الذي تنوي اختباره. ثانيًا، اجلب سجل المفتاح العام الذي يسميه ذلك التوقيع وحلّله. ثالثًا، تحقق من أن الترويسات الموقَّعة والمتن المعياري ما زالا مطابقين للتوقيع التشفيري. رابعًا، قرّر هل يحاذي نطاق التوقيع الناجح نطاق From الظاهر لأغراض DMARC. تجيب هذه الطبقات عن أسئلة مختلفة. فقد يكون السجل المنشور غير مستخدم، وقد تشير الرسالة إلى محدِّد غير موجود، وقد يفشل التوقيع بعد تعديل المحتوى، وقد ينجح التحقق التشفيري ويبقى غير محاذٍ لنطاق المؤلف. سجّل كل نتيجة على حدة بدلًا من عرض شارة خضراء واحدة. وأبقِ كذلك حالات النقل وصندوق البريد منفصلة: قبول المزوّد وقبول الخادم المستقبِل والوصول إلى صندوق الوارد ليست نتائج تحقق من DKIM.

ابدأ من التوقيع في رسالة حقيقية

احصل على الرسالة الخام من مستلِم خاضع للتحكم وصلته عبر مسار التطبيق المعتاد. وفي كل حقل DKIM-Signature سجّل نطاق التوقيع `d=` والمحدِّد `s=` والخوارزمية `a=` وأنماط التوحيد المعياري `c=` وقائمة الترويسات الموقَّعة `h=` وتجزئة المتن `bh=` وبيانات التوقيع `b=` والطوابع الزمنية إن وُجدت. يعرّف RFC 6376 وسمَي نطاق التوقيع والمحدِّد ويستخدمهما لتحديد موقع المفتاح العام. لا تخمّن المحدِّد من لوحة تحكم المزوّد ولا تستعلم عن `_domainkey` بدونه. وقد تحمل الرسالة توقيعات متعددة من المُرسِل أو من وسيط أو من نظام قوائم بريدية، لذا احفظ النتيجة لكل توقيع. وتجنّب لصق الرسائل الفعلية في أدوات فحص عامة: فالترويسات والمتن الخام قد تكشف المستلِمين ومعرّفات الرسائل وتفاصيل التوجيه ورموز إلغاء الاشتراك ومحتوى التطبيق. استخدم تخزينًا مقيّد الوصول ونسخة تشخيصية منقّحة عندما لا يلزم المحتوى الكامل.

استعلم عن المحدِّد ونطاق التوقيع بدقة

كوّن اسم DNS من التوقيع بالشكل `<selector>._domainkey.<signing-domain>`. فإذا كانت الترويسة تحتوي على `s=app2026` و`d=notify.example.test`، فاستعلم عن TXT في `app2026._domainkey.notify.example.test`. سجّل الاسم الأصلي والمحلّل والاستجابة وTTL وأي سلسلة CNAME. حلّل سجل الوسوم والقيم الناتج بدلًا من البحث عن جزء نصي. فقد يعلن السجل عن إصداره ونوع المفتاح وتقييد الخدمة والأعلام وخوارزميات التجزئة وبيانات المفتاح العام. وقيمة المفتاح العام الفارغة تعني إلغاء المفتاح. ميّز بين NXDOMAIN والإجابة الفارغة والمحتوى المشوّه والخوارزمية غير المدعومة والمفتاح غير الصالح للاستخدام وفشل المحلّل المؤقت. أعد الاستعلام بعد أي تغيير عند انتهاء TTL عبر محلّل مستقل، لكن لا تفترض أن جميع المستقبِلين قد حدّثوا بياناتهم فورًا. ونجاح DNS لا يثبت سوى أن سجلًا أُعيد في تلك اللحظة، ولا يثبت أن الرسالة المختبَرة تجتاز التحقق ولا أن المزوّد يوقّع الحركة الحالية بهذا المحدِّد.

تحقق من الترويسات وتجزئة المتن والتوقيع

يتبع التحقق من DKIM قواعد التوحيد المعياري التي يعلنها التوقيع. يوحّد المتحقق المتن معياريًا، ويحسب تجزئته، ويقارنها بـ `bh=`. ثم يوحّد معياريًا الترويسات الموقَّعة المذكورة في `h=`، ويضم حقل DKIM-Signature كما هو محدد، ويتحقق من `b=` بالمفتاح العام. استخدم مكتبة تحقق مُصانة أو نتيجة مصادقة موثوقة من المستقبِل بدلًا من إعادة إنتاج هذه التحويلات بعمليات على النصوص. غالبًا ما يعني عدم تطابق تجزئة المتن أن المتن تغيّر بعد التوقيع، بينما قد يدل فشل توقيع الترويسات على تعديل في ترويسة موقَّعة أو مفتاح خاطئ أو بيانات توقيع تالفة أو خطأ في التنفيذ. دوّن أي مرحلة فشلت. وافحص هل وُقّعت الحقول المهمة مثل From وSubject وDate وMessage-ID، لكن لا تخترع سياسة عامة موحّدة للترويسات الموقَّعة. يتسامح التوحيد المعياري مع تغييرات تنسيق محددة، لكنه لا يجعل حقن التذييلات العشوائي أو إعادة كتابة MIME أو تلف نهايات الأسطر أو تعديل النقل آمنًا.

اقرأ نتائج المستقبِل داخل حدود الثقة الخاصة بها

يعرّف RFC 8601 ترويسة Authentication-Results ونتائج DKIM ومنها none وpass وfail وpolicy وneutral وtemperror وpermerror. ويعني pass أن المستقبِل وجد توقيعًا مقبولًا اجتاز اختبارات التحقق. وقد يعكس temperror حالة يُرجَّح أن تتغير، مثل فشل مؤقت في جلب المفتاح، أما permerror فمن غير المرجّح أن ينجح في محاولة لاحقة دون تصحيح. سجّل خدمة المصادقة المبلِّغة ونطاق التوقيع والمحدِّد والخوارزمية حيثما توفرت. ولا تثق إلا بالنتائج التي أُدرجت داخل حدود النظام المستقبِل الموثّقة، لأن المُرسِل يستطيع إضافة حقل Authentication-Results مزوّر قبل الإرسال. افحص أعلى نتيجة موثوقة في بيئة الاستقبال النهائية وضع في الحسبان المحطات الوسيطة. وإذا اختلف المستقبِلون، فقارن نسخة الرسالة نفسها ومنظور DNS ووقت التقييم والخوارزميات المدعومة والسياسة المحلية. ولا تحوّل `dkim=pass` إلى ادعاء بأن مزوّد صندوق البريد أقرّ المحتوى أو وضعه في صندوق الوارد.

افحص محاذاة DMARC بمعزل عن نجاح DKIM

نجاح DKIM يصادق على نطاق التوقيع في `d=`، ولا يشترط أن يساوي ذلك النطاق نطاق From الظاهر في RFC 5322. ويستخدم RFC 9989 معرّفًا ناجحًا مصادَقًا عليه بـ DKIM في DMARC فقط عندما يحاذي نطاق المؤلف وفق نمط المحاذاة الصارمة أو المرنة المطبَّق. فمثلًا، الرسالة الصادرة من `billing.example.test` والموقَّعة بـ `d=provider.test` قد تنجح في DKIM وتبقى غير محاذية. أما التوقيع الصالح من `d=example.test` فقد يحاذي في النمط المرن، بحسب حساب النطاق التنظيمي والسياسة. أبلِغ عن ثلاثة حقول: نتيجة DKIM ونطاق التوقيع وقرار المحاذاة. وقد تنجح الرسالة في DMARC عبر SPF محاذٍ عندما يفشل DKIM أو لا يحاذي، لذا فنجاح DMARC لا يثبت أن توقيع DKIM المعيّن قد نجح. وتتضمن إرشادات المُرسِلين الحالية في Gmail متطلبات مصادقة ومحاذاة للحركة المشمولة، لكن استيفاءها لا يضمن قبول الخادم المستقبِل ولا الوصول إلى صندوق البريد.

افحص الخوارزميات الحالية وتدوير المفاتيح

يحدّث RFC 8301 المتطلبات التشفيرية لـ DKIM: يجب على المُوقِّعين استخدام `rsa-sha256`، وعلى المتحققين دعمها، ويجب عدم استخدام `rsa-sha1`. كما يشترط مفاتيح توقيع RSA لا تقل عن 1024 بت، مع شرح سبب تفضيل المفاتيح الأكبر متى أمكن ذلك تشغيليًا. ينبغي للأداة الفاحصة أن تحدد الخوارزمية وأن تنبّه إلى المواد المتقادمة أو غير الصالحة للاستخدام، دون أن تدّعي أن طول المفتاح وحده يجعل تدفق البريد موثوقًا. وتختلف سير عمل المزوّدين. فتوثّق Amazon SES أن Easy DKIM يستخدم مفاتيح 2048 بت افتراضيًا، وتحذّر من أن تغيير طرق التوقيع دون خطوة وسيطة قد يخلق فترة لا تُوقَّع فيها الرسائل بـ DKIM. خطّط للتدوير بمحدِّدين صالحين أو بآلية التداخل الموثّقة لدى المزوّد، وتأكد من أن الرسائل الجديدة تستخدم المحدِّد الجديد، واحتفظ بالمفتاح العام القديم ما دام بإمكان رسائل متأخرة الوصول، ولا تزله إلا بعد انتهاء فترة التداخل. ولا تنشر مفتاح التوقيع الخاص أبدًا في DNS أو السجلات أو التذاكر أو المطالبات (prompts).

شخّص الإخفاقات بدءًا من الرسالة نفسها

عند فشل الفحص، احفظ الرسالة الخام ونتيجة المستقبِل قبل تغيير DNS. تأكد من أن التطبيق والمزوّد المتوقعين هما من أنتج الرسالة فعلًا. فإذا لم يوجد توقيع، فافحص هل كان التوقيع مفعّلًا لتلك الهوية أو المنطقة أو المستأجر أو فئة الرسائل. وإذا فشل استعلام المحدِّد، فقارن قيمتي `d=` و`s=` بدقة مع منطقة DNS وهدف CNAME وTTL وأي تدوير حديث. وإذا حُلّل المفتاح لكن تجزئة المتن فشلت، فافحص البوابات وتذييلات القوائم وإعادة كتابة روابط التتبع وتحويلات MIME ونهايات الأسطر ومنتجات الأمان التي قد تعدّل المحتوى بعد التوقيع. وإذا فشل التوقيع التشفيري مع تطابق تجزئة المتن، فافحص تغيّرات الترويسات الموقَّعة وعدم تطابق المفتاح وتنفيذ التوقيع. وإذا نجح DKIM وفشل DMARC، فاختبر المحاذاة بدلًا من إعادة نشر المفتاح نفسه. أعد الاختبار عبر مستلِمين خاضعين للتحكم بعد انقضاء TTL المعني أو انتشار الإعدادات، وسجّل الأدلة لكل فئة رسائل بدلًا من إعلان إصلاح النطاق كله من عينة ناجحة واحدة.

احتفظ بسجل قابل للتدقيق لفحوص DKIM

لكل رسالة خاضعة للتحكم، احتفظ بمعرّف ربط غير حساس، والنظام المُرسِل، وحساب المزوّد أو مساحة العمل، ونطاق From الظاهر، والنظام المستقبِل، ووقت الرسالة، والنتيجة الكاملة لكل توقيع. ضمّن `d=` و`s=` و`a=` والتوحيد المعياري والترويسات الموقَّعة واسم استعلام DNS ووقت استجابة DNS وTTL وحالة سجل المفتاح ونتيجة تجزئة المتن ونتيجة التوقيع وقيمة Authentication-Results الموثوقة وقرار محاذاة DMARC ومالك المعالجة. وخزّن الرسائل الخام فقط حيث تتوفر ضوابط وصول واحتفاظ مناسبة. وأضف سيناريو الاختبار: إرسال عادي من التطبيق، أو ترحيل مزوّد، أو تدوير مفاتيح، أو مسار بوابة، أو حالة إعادة توجيه. يجعل هذا حالات التراجع قابلة للمقارنة ويمنع أن تصبح لقطة شاشة دليلًا دائمًا بعد تغيّر المحدِّدات أو معالجة الرسائل. أعد الفحص بعد تغييرات إعداد المزوّد أو DNS أو طريقة التوقيع أو التوجيه، أو عند إضافة فئة رسائل جديدة. وينبغي أن تُظهر لوحة التشغيل الحالات المجهولة وغير المتاحة صراحةً بدلًا من معاملتها بصمت على أنها نجاح أو فشل.

افهم موقع SendHQ من هذا الفحص

يتطلب SendHQ نطاق From موثَّقًا ويوفر أحداث التسليم. لإجراء فحص DKIM، أرسل رسالة مضبوطة عبر مسار التطبيق المقصود، وافحص التوقيع المستلم، واستعلم عن قيم `d=` و`s=` الفعلية، وسجّل المحاذاة بشكل منفصل. لا تستنتج محدِّدًا أو طول مفتاح أو خوارزمية توقيع أو الوصول إلى صندوق الوارد أو ضمان التسليم من وثائق المنتج وحدها.

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

المصادر

• RFC 6376: تواقيع DomainKeys Identified Mail ‏(DKIM) — RFC Editor
• RFC 8301: تحديث خوارزمية التشفير وحجم المفتاح لـ DomainKeys Identified Mail ‏(DKIM) — RFC Editor
• RFC 8601: حقل ترويسة Authentication-Results — RFC Editor
• RFC 9989: مصادقة الرسائل وإعداد التقارير والتوافق المستندة إلى النطاق (DMARC) — RFC Editor
• إرشادات Gmail للمُرسِلين — Google
• Easy DKIM في Amazon SES — Amazon Web Services
• عقد OpenAPI الخاص بـ SendHQ — SendHQ