DKIM يتيح للمجال تحمل المسؤولية عن الرسالة من خلال توقيع التشفير. لفهم ما يعنيه ذلك بالنسبة لرسالة بريد إلكتروني معينة، ابدأ بالأصل المستلم بدلاً من مدقق DNS . سلسلة الأدلة المفيدة هي توقيع الرسالة ومجال التوقيع و محدد، المفتاح العام، نتيجة التحقق من جهاز الاستقبال، ثم أي DMARC تنسيق قرار.
اقرأ الهوية التي تم التوقيع عليها
حدد موقع كل منهما DKIM-Signature العنوان في الرسالة الأصلية. تحدد قيمة d= مجال التوقيع وتعرف s= محدده. بالنسبة لاسترجاع المفاتيح المستندة إلى DNS، قم بدمجها كمحدد. _domainkey.signing-domain. قد ينتمي مجال التوقيع إلى مؤسسة المؤلف، أو جهة ترحيل أو خدمة تعمل نيابة عنها. يفصل DKIM عمدًا مسؤولية التوقيع عن المؤلف الظاهري. RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.
مثال توضيحي: من هو accounts@example.com والتوقيع يحتوي على d=example.com; s=mail2026. يبحث المدقق عن mail2026._domainkey.example.com . يوفر سجل DNS هذا مواد التحقق العامة. يظل مفتاح التوقيع الخاص مع المُوقع المعتمد ويجب عدم نشره. يشرح هذا المثال عملية البحث؛ فهو ليس توقيعًا حقيقيًا أو رسالة مجربة.
حضور منفصل عن التحقق الناجح
يمكن أن يكون رأس DKIM-Signature موجودًا وغير صالح. يمكن أن يوجد مفتاح DNS بينما لا يرسل التطبيق أي توقيعات على الإطلاق. يتحقق التحقق من بنية التوقيع والمفتاح والرؤوس المحددة وتمثيل الجسم. قد تؤدي التغييرات بعد التوقيع إلى كسرها، اعتمادًا على ما تم تغييره والحالة تحديد العنوان القانوني مستخدم. لا تعتبر السلسلة ذات المظهر الملخص دليلاً على اجتياز عمليات التحقق هذه. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.
فحص موثوقية نظام الاستقبال Authentication-Results أو سجلات مماثلة. تعرف على خدمة المصادقة التي أضافت هذه النتيجة وأين تتم إزالة رؤوس النتائج الواردة غير الموثوق بها أو تجاهلها. يمكن للمرسل إدراج نص مرور يبدو معقولاً في الرسالة، لذا فإن محتوى Authentication-Results التعسفية ليس دليلاً. RFC 8601 §1.2, RFC 8601 §7.1.
قم بتوصيل النتيجة إلى المؤلف المرئي
بالنسبة إلى DMARC ، قارن نطاق d= الذي تم التحقق منه بنجاح مع نطاق المؤلف من From. تتطلب محاذاة DKIM الصارمة تطابقًا تامًا ضمن RFC 9989 §3.2.10; تستخدم المحاذاة المريحة اكتشاف المجال التنظيمي في RFC 9989 §4.10.2. المحدد وقيمة i= الاختيارية ليسا النطاقين المستخدمين لمقارنة DMARC هذه. في حالة وجود العديد من توقيعات DKIM ، يمكن لتوقيع واحد محاذٍ أن يوفر مسار DKIM إلى ممر DMARC . RFC 9989 §4.4.1.
في المثال، d=example.com يطابق المجال من. إذا تم التحقق من d=service.example.net بدلاً من ذلك، فسيتم تمرير DKIM الأولي ولكن هذا المجال غير ذي الصلة لا ينشئ التوافق مع example.com . لا تقم "بإصلاح" ذلك عن طريق تحرير الرأس المستلم: قم بتكوين الموقّع الشرعي لاستخدام هوية مدعومة مناسبة.
بناء سجل تحقيق مفيد
تسجيل وقت الرسالة، والمسار، ومن المجال، وكل زوج d/s، ونتيجة وسبب DKIM الموثوق به، ووقت مراقبة DNS ونتائج المحاذاة. حماية الرسالة الأصلية لأنها قد تحتوي على معلومات شخصية أو سرية. يمكن أن يؤدي تنقيح النسخة إلى إبطال توقيعها؛ الاحتفاظ بنسخة أصلية يمكن التحكم في الوصول إليها عند الحاجة إلى إعادة التحقق.
إذا فشل التحقق، فتحقق مما إذا تم تمكين التوقيع، وتوافر المفتاح الصحيح، ودعم الخوارزمية وتغيير الرسالة أثناء النقل. تحل إرشادات التشفير الحالية محل الإعدادات الافتراضية القديمة: RFC 8301 §3.1 يحظر rsa-sha1 للتوقيع والتحقق؛ RFC 8301 §3.2 يقوم بتحديث إرشادات مفتاح RSA. لا تستخدم خيارات التشفير لبرنامج تعليمي قديم لمجرد أن تركيب الجملة الخاص به لا يزال يبدو صالحًا. أنهِ الأمر بدليل على النتيجة المستلمة، وليس فقط دليل على أن DNS يحتوي على مفتاح.
تطبيق التمييز
بالنسبة للرسالة الافتراضية، اكتب صفًا واحدًا لكل توقيع: d، s، مالك البحث، نتيجة التحقق الموثوق به والمحاذاة. إذا فشل توقيع example.com أثناء مرور توقيع service.example.net غير ذي صلة، فلا تقم بدمج المجال الأول مع النتيجة الثانية. التحقيق في التوقيع الفاشل وتقييمه SPF بشكل منفصل قبل تعيين DMARC . لم يتم تنفيذ التحقق من الرسالة لهذه المقالة.