فشل DKIM: تشخيص تجزئة المتن والمفاتيح وDNS

فشل DKIM ليس تنبيها شكليا، بل إخفاق في التحقق من توقيع. يعني أن خادم الاستقبال لم يتمكن من التحقق من توقيع DKIM، لا أنه حكم حتما على الرسالة كلها بأنها غير موثوقة. لكنه قد يؤثر في التصفية والاستقبال. لاستكمال إعداد بيئتك، ابدأ بدليل البريد الإلكتروني للأعمال حتى تتوافق إعدادات SPF وDKIM وDMARC والتوجيه والصناديق.

قد تبدو الرسالة طبيعية لديك، بينما يعرض Gmail أو Microsoft أو Yahoo نتيجة dkim=fail. وبحسب نتائج المصادقة الأخرى وسياسة المستقبل، قد تصنف الرسالة كمزعجة أو تخضع لقيود مؤقتة أو ترفض. وقد تتراجع الاستجابة وتزداد طلبات الدعم. يمكن أن يكون السبب في DNS أو نظام الإرسال أو جهاز يعدل البريد أثناء النقل.

تعامل مع المشكلة كحادث يحتاج إلى أدلة: اقرأ نتيجة المصادقة، وحدد نوع الخطأ، وافحص المحدد والمفتاح، ثم تتبع ما عدل الرسالة بعد توقيعها. أصلح السبب الذي تثبته الفحوص.

ما المعنى الدقيق لفشل dkim؟

يعني فشل DKIM تعذر التحقق من التوقيع التشفيري المرفق بالرسالة. قد يكون السبب تغيير البيانات الموقعة أو عدم تطابق المفتاح. أما غياب المفتاح العام في DNS أو تعذر الاستعلام فقد ينتج خطأ دائما أو مؤقتا؛ ميز هذه النتائج عن فشل التحقق نفسه.

يعرف RFC 6376 تجزئة المتن في bh= وتوقيع الترويسات في b=. وقد يؤدي عدم التطابق إلى فشل التحقق. لا يثبت ذلك وحده انتحال المرسل، فقد تكون البنية نفسها توقع مبكرا أو تنشر مفتاحا خاطئا أو تسمح لمرحلة لاحقة بتعديل الرسالة.

يمكن تشبيه DKIM بختم على طرد. اختلاف الختم يعني أن الفحص لم ينجح، لكنه لا يحدد وحده من أحدث التغيير أو مدى موثوقية المحتوى كله.

ابدأ بترويسة Authentication-Results في الرسالة الأصلية. تساعدك على معرفة النتيجة وتصنيف المشكلة. يعرض المثال التالي طريقة كتابة النتائج، لكنه يجمع نتائج لا يتوقع اجتماعها عادة: نجاح SPF المتوافق مع نطاق From نفسه يؤدي عادة إلى نجاح DMARC رغم فشل DKIM. لا تعتبره توقعا طبيعيا للنتيجة.

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
  spf=pass smtp.mailfrom=example.com;
  dmarc=fail header.from=example.com

للتحقق من سجلات النطاق قبل تغيير المرسل، قارنها مع سجلات DNS المطلوبة في TrekMail.

أنواع مشكلات DKIM الشائعة

يساعد تقسيم المشكلات إلى اختلاف تجزئة المتن، وعدم تطابق المحدد أو المفتاح، وسجل DNS غير صالح أو مبتور، وتعديلات إعادة التوجيه أو الترحيل. التصنيف الصحيح يقلل تبديل مفاتيح لم تكن سبب المشكلة.

هذا تصنيف أولي. أثبت السبب الفعلي بفحوص إضافية.

نوع الخطأ 1: اختلاف تجزئة المتن

يعني اختلاف التجزئة أن الجزء الموقع من المتن المستلم، بعد تطبيق التسوية، لا يطابق ما حسبت تجزئته عند التوقيع. ليس الفحص مقارنة لكل بايت في الرسالة كاملة، ولا يمكن استنتاج سلامة DNS من هذه النتيجة.

ينص RFC 6376 على إخفاق تحقق دائم إذا لم تطابق التجزئة المعاد حسابها قيمة bh=. افحص تغييرات الجزء الموقع وكذلك حسابه ومعالجته لدى المرسل والمستقبل.

أسباب محتملة:

• إضافة Microsoft 365 أو Exchange أو بوابة أمنية تنويها قانونيا بعد التوقيع.
• إعادة كتابة الروابط بواسطة Mimecast أو Barracuda أو Proofpoint أو مرشحات مشابهة.
• تغيير خادم ترحيل للمسافات أو نهايات الأسطر بطريقة لا تستوعبها التسوية المختارة.
• توقيع التطبيق أولا ثم تعديل بوابة لاحقة لحدود MIME أو إضافة لافتة مثل [External].

راجع قيمة c= في التوقيع. الوضع c=simple/simple أكثر حساسية لبعض تغييرات التنسيق. تتجاهل تسوية المتن المرنة في RFC 6376 المسافات النهائية وتختزل المسافات المتكررة داخل الأسطر، ضمن قواعدها. لكنها لا تصلح تغييرا جوهريا مثل إضافة نص أو تعديل رابط.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=tm1; h=from:to:subject:date:mime-version;
 bh=...; b=...

يفضل التوقيع بعد انتهاء التعديلات التي تتحكم فيها على التذييلات والروابط والتوجيه ومتطلبات الامتثال. غالبا تناسب آخر مرحلة إرسال تديرها هذا الدور، لكنها لا تمنع تعديلات الأنظمة الخارجية لاحقا.

إذا كنت تستخدم إعادة التوجيه، فراجع إعادة توجيه البريد وإعادة توجيه بريد النطاق إلى Gmail. قد تختلف نتائج المسار الفعلي عن اختبار الإرسال المباشر.

نوع الخطأ 2: عدم تطابق المحدد أو المفتاح

تحدث المشكلة عندما تستخدم الرسالة المحدد X ولا يحتوي DNS في موضعه على مفتاح قابل للاستخدام، أو يحتوي على مفتاح عام لا يقابل المفتاح الخاص المستخدم. غياب المفتاح قد يظهر كخطأ دائم، وعدم مطابقته قد يسبب فشل التحقق.

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

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...

ثم استعلم عن المحدد نفسه:

dig txt k1._domainkey.example.com +short

قد تعني الإجابة الفارغة سجلا مفقودا أو موضعا خاطئا، لكنها قد تنتج أيضا عن التخزين المؤقت أو مشكلة استعلام أخرى. افحص الاستجابة الكاملة. وإذا ظهر سجل، فقارنه بمفتاح المرسل الحالي. أثناء الترحيل أو استخدام منصات متعددة، قد تتحول منصة إلى مفتاح جديد وتستمر أخرى بالتوقيع بالمفتاح القديم.

مثال ذلك إرسال التطبيقات عبر SES والدعم عبر Microsoft 365 والحملات عبر مزود آخر. يمكن لتغيير DNS أن يؤثر في مسار واحد فقط. استخدم محددات منفصلة للمرسلين حين يلائم ذلك البنية.

في مسار TrekMail المدار، راجع TrekMail SMTP المدار وتحقق من موضع التوقيع. أما في Nano أو مع مرسل خارجي، فراجع SMTP خاص بك (BYO): يعمل TrekMail كعميل، ويجب ضبط DKIM في نظام الإرسال الفعلي.

نوع الخطأ 3: نشر المفاتيح الطويلة في DNS

قد تنشر قيمة مفتاح 2048 بت بشكل خاطئ إذا أساءت لوحة DNS معالجة TXT. وقد ينتج عن ذلك permerror أو صيغة غير صالحة أو مفتاح ناقص.

يشترط RFC 8301 مفاتيح RSA لا تقل عن 1024 بت، ويوصي بما لا يقل عن 2048 بت. تحقق أيضا من حفظ لوحة DNS للقيم الطويلة دون إفسادها.

قد يؤدي قص المفتاح أو خطأ الاقتباس إلى إخفاق حتى مع صحة المفتاح الخاص. النمط التالي توضيحي؛ استخدم مفتاحك العام الكامل مقسما إلى سلاسل داخل سجل TXT نفسه.

; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
  "restOfThePublicKeyContinuesHere..."
)

استعلم عن السجل وافحص الاستجابة كاملة، لا أول جزء فقط:

dig txt k1._domainkey.example.com +short

راجع ذلك خصوصا بعد تغيير مزود DNS أو نقل المنطقة أو نسخ السجلات يدويا. يجمع التطبيق سلاسل السجل الواحد دون مسافات إضافية.

نوع الخطأ 4: إعادة التوجيه والترحيل وفجوات التوافق

قد تفشل DKIM عندما يعدل نظام وسيط البيانات الموقعة أثناء إعادة التوجيه. وقد يفشل SPF للمرسل الأصلي أيضا. يفشل DMARC عند غياب أي مصادقة ناجحة ومتوافقة أخرى، بينما يعتمد رفض الرسالة على سياسة المستقبل.

لنفترض إرسال رسالة من example.com إلى جامعة تعيد توجيهها إلى Gmail. قد يفشل SPF لأن خادم الجامعة ليس المرسل الأصلي. يمكن أن يبقى DKIM صالحا إذا ظلت البيانات الموقعة سليمة بما يسمح بالتحقق. لكن تذييلا جديدا أو رابطا معدلا أو تغييرا في موضوع موقع قد يفسده. وقد يفشل DMARC إذا لم توجد مصادقة متوافقة بديلة.

تطلب Google من المرسلين عموما إلى حسابات Gmail الشخصية SPF أو DKIM، وتطلب من مرسلي البريد الجماعي كليهما مع DMARC وشروط التوافق المطبقة. كما توصي بـ ARC في مسارات إعادة التوجيه والقوائم حين ينطبق ذلك. يقرر المستقبل ما إذا كان يثق بـ ARC ويستفيد منه. لذلك لا يثبت فشل DKIM أثناء التوجيه أن الإعداد الأساسي خاطئ.

يمكن أن يساعد SRS والتوجيه المدروس. تحقق من وظائف SRS المتاحة في إعداد TrekMail لديك. يعيد SRS كتابة مرسل المغلف وقد يساعد SPF للمرسل الجديد على النجاح، لكنه لا يحقق تلقائيا التوافق مع نطاق From الأصلي، ولا يستبدل DKIM.

في البيئات كثيرة الأسماء المستعارة، اقرأ أيضا إعادة توجيه الاسم المستعار وإنشاء بريد بنطاقك. افحص المسار الفعلي، لا إعداد الاسم المستعار وحده.

مواضع الفحص عند ظهور dkim fail

اتبع ترتيبا ثابتا: نتيجة المصادقة، ثم استعلام المحدد، ثم مسار التوقيع، ثم التوافق. يساعد ذلك على تجنب تغيير DNS حين تكون المشكلة تعديلا بعد التوقيع.

1. افتح الرسالة الأصلية وابحث عن Authentication-Results. سجل نتيجة DKIM بدقة.
2. ابحث عن d= وs= وc= في ترويسة DKIM-Signature.
3. استعلم عن المحدد باستخدام dig وتأكد من اسم المضيف selector._domainkey.example.com.
4. حدد المنصة التي توقع فعليا. قد تفسر المنصات المتعددة اختلاف النتائج.
5. افحص تعديلات المتن أو الترويسات الموقعة بواسطة البوابات والمرشحات وخوادم إعادة التوجيه.
6. تحقق من توافق نطاق d= مع نطاق From: الظاهر حتى يحقق DKIM شرط DMARC.

قد ينتج لصق أجزاء من الرسالة في مدقق خارجي أخطاء تجزئة مضللة بسبب نقص البيانات. افحص المصدر الكامل أو ملفا مصدرا بصيغة .eml.

معالجة مترابطة باستخدام TrekMail

قد يخفي تعديل DNS وخوادم الترحيل والتذييلات لدى مزودين مختلفين موضع التوقيع الحقيقي. اجعل التوقيع بعد آخر تعديل تتحكم فيه، وتحقق من DNS، وافصل بين الإرسال المدار وSMTP الخاص بك.

في البنية الموصوفة هنا، تستخدم Nano المجانية SMTP خاصا بك. تبدأ الخطط المدفوعة من $3.50 شهريا وتتضمن SMTP مدارا؛ تحقق من الأسعار والميزات الحالية. إذا أردت توقيع TrekMail فاستخدم المسار المدار المدعوم. وإذا وقع SES أو SendGrid أو Mailgun، فشخص DKIM لدى ذلك المرسل. قد تتاح تجربة مجانية لمدة 14 يوما تتطلب بطاقة ائتمان. راجع الشروط في أسعار TrekMail.

يساعد هذا الفصل على تحديد نطاق الفحص. في BYO SMTP، تحقق من المحدد والمفتاح والتعديلات في مسار الإرسال الخارجي، ولا تفترض دون دليل أن صندوق TrekMail هو السبب.

قائمة فحص أخيرة لحوادث DKIM

تعامل مع DKIM fail كخطأ تحقق محدد، لا كمشكلة وصول مبهمة. اقرأ النتيجة وافحص المحدد ومسار التوقيع قبل تغيير الإعدادات، لتكون المعالجة مبنية على أدلة.

قبل تعديل الإنتاج، راجع ما يلي:

• اقرأ ترويسة المصادقة كاملة، لا ملخص الارتداد فقط.
• ميز خطأ تجزئة المتن وفشل التوقيع وpermerror وtemperror.
• استعلم عن المحدد الصحيح في DNS.
• تأكد من اكتمال المفتاح وصحة الاقتباس.
• انقل التوقيع إلى ما بعد آخر تعديل تتحكم فيه عند الحاجة.
• فكر في c=relaxed/relaxed إذا دعمته البيئة، مع إدراك أنه لا يعالج التغييرات الجوهرية.
• افحص توافق DMARC بين d= ونطاق From: الظاهر.

إذا تكرر dkim fail، فاجمع الأدلة بدلا من الانتظار وحده. افحص موضع التوقيع والمحدد والمفتاح والتعديلات اللاحقة، ثم أصلح السبب المثبت.