كيف ينفّذ فريق المنتج إعداد DKIM بأمان؟

ارسم كل مسار إرسال فعلي قبل توليد المفتاح

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

اختر نطاق توقيع يدعم محاذاة DMARC

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

خصّص المحدِّدات بوصفها هويات تشغيلية

يتيح المحدِّد للنطاق نشر مفاتيح متعددة وتغييرها من دون استبدال سجل عالمي واحد. أنشئ سياسة محدِّد حتمية تحدد مزوّدًا أو موقّعًا وجيل تدوير من دون تسريب أسرار. على سبيل المثال، قد يكون product-a-2026q3 أوضح من default، لكن أبق الأسماء ضمن اصطلاحات DNS وحدود أدواتك. لا تعِد استخدام مفتاح خاص واحد عبر مزوّدين أو بيئات أو مستأجرين غير مرتبطين لمجرد تقليل سجلات DNS. حافظ على سجل يتضمن المحدِّد ونطاق d= والغرض وخدمة التوقيع والمالك ووقت الإنشاء والخوارزمية وبصمة المفتاح العام وحالة النشر وموعد التدوير وأدلة الإيقاف. افحص اسم المحدِّد الدقيق قبل النشر: الاستعلام هو `selector._domainkey.signing-domain`. لن يتحقق التوقيع المقصود من سجل عرضي في نطاق From الظاهر أو نطاق return-path أو منطقة DNS الخاطئة. تجنب حذف محدِّد قديم إلى أن تنقضي الرسائل المتأخرة وعمليات إعادة المحاولة الموقعة به.

ولّد المفتاح الخاص واحمِه

ولّد زوج المفاتيح داخل خدمة مفاتيح مُدارة أو نظام توقيع شديد التحكم متى كان المزوّد يدعم ذلك. يجب ألا يدخل المفتاح الخاص أبدًا في DNS العام أو التحكم في المصدر أو شيفرة المتصفح أو مخرجات CI أو التحليلات أو السجلات العادية أو التذاكر أو المستندات أو المطالبات (prompts) أو المحادثات المشتركة. امنح صلاحية التوقيع لمكوّن البريد الذي يحتاج المفتاح فقط، وافصل الإنتاج عن البيئات الأدنى، وسجّل الوصول الإداري. يحدّث RFC 8301 المتطلبات التشفيرية لـ DKIM وينص على أن المُوقِّعين يجب أن يستخدموا مفاتيح RSA بطول 1024 بت على الأقل، وينبغي أن يستخدموا 2048 بت على الأقل؛ كما يشير إلى قيود DNS التشغيلية المتعلقة بالمفاتيح الأكبر. استند إلى القدرات والتوصيات الحالية للمُوقِّع المختار وللمستقبِلين بدلًا من نسخ مثال متقادم. وإذا فكّرت في Ed25519، فإن RFC 8463 يعرّف استخدامه في DKIM، لكن التوافق يجب أن يُختبر وأن تبقى استراتيجية توقيع متوافقة حيث يلزم. ويجب أن يكون التدوير ممكنًا دون تصدير المفتاح الخاص.

انشر المفتاح العام بدقة

انشر سجل TXT عند اسم المالك الدقيق `selector._domainkey.signing-domain`. يحمل سجل مفتاح DKIM علامات مثل v=DKIM1 ونوع مفتاح عند الحاجة وp= التي تحتوي مادة المفتاح العام من دون أغلفة المفاتيح الخاصة. اتبع تنسيق السجل الدقيق للموقّع وسلوك الاقتباس لدى مزوّد DNS لديك. قبل الحفظ، تحقق مما إذا كانت واجهة DNS تُلحق المنطقة تلقائيًا أو تقسم السلاسل الطويلة أو تهرّب الأحرف. استعلم عن خوادم الأسماء الموثوقة مباشرة بعد النشر، ثم استعلم عن محلّلات تكرارية مستقلة وأعد بناء قيمة TXT كاملة. تتصل سلاسل الأحرف المتعددة في سجل TXT واحد من قِبل عملاء DNS، بينما قد تؤدي سجلات الموارد المتنافسة المتعددة إلى غموض. احتفظ بالإجابة السابقة وTTL للتراجع. لا تخفّض الأمان بنشر مفتاح أوسع أو ترك علامة اختبار في بيئة الإنتاج لمجرد إسكات أداة فحص. يثبت السجل الظاهر نشر DNS، لا أن المُرسِل يستخدم المفتاح الخاص المطابق.

اضبط المُوقِّع النهائي والحقول الموقَّعة

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

تحقق من الرسائل الأصلية المستلَمة من البداية إلى النهاية

أرسل رسائل خاضعة للتحكم عبر كل مسار بشكل الإنتاج الفعلي إلى صناديق بريد اختبار خارجية يديرها الفريق. احتفظ بالرسالة الخام الأصلية، لا بمتن منسوخ ولا بمرفق تذكرة أُعيد تسلسله. افحص قيمتي d= وs= في DKIM-Signature وقائمة الترويسات الموقَّعة وتجزئة المتن والخوارزمية والتوحيد المعياري والطابع الزمني وأي انتهاء صلاحية. استعلم عن المفتاح العام من شبكة مستقلة وشغّل متحققًا يفهم المعايير على البايتات الأصلية. وقارن ترويسة Authentication-Results لدى المستقبِل الموثوق بمتحققك، مع احترام حدود الثقة في RFC 8601. اختبر النص العادي وmultipart alternative والمرفقات المتوقعة وعناوين الموضوع بـ Unicode والترويسات الطويلة والقوالب وتحويلات التتبع وإعادات المحاولة ومسارات الترحيل. ويجب أن تشمل الاختبارات السلبية ترويسة موقَّعة غُيّرت عمدًا في بيانات اختبار، ومحدِّدًا مفقودًا، ومحدِّدًا منتهي الصلاحية أو متقاعدًا، ومسارًا يتجاوز التوقيع. ولا تعبث أبدًا ببريد عملاء حقيقي لإنشاء اختبار.

قيّم DKIM وDMARC والتسليم كنتائج منفصلة

يعني نجاح DKIM أن المدقّق عثر على توقيع صالح لنطاق التوقيع المحدد على الحقول الموقعة والمتن. ولا يصادق على كل ترويسة غير موقعة، أو يؤكد كاتبًا بشريًا، أو يثبت موافقة المستلِم، أو يحدد الامتثال القانوني، أو يضمن القبول والوصول إلى صندوق الوارد. يقيّم DMARC بصورة منفصلة ما إذا كان نطاق DKIM أو SPF الناجح متحاذيًا مع نطاق From الظاهر ويطبق سياسة مالك النطاق. سجّل على الأقل نتيجة DKIM وسببها، ونطاق d=، والمحدِّد، ونطاق From الظاهر، ونتيجة المحاذاة، ونتيجة SPF، ونتيجة DMARC، والمستقبِل، والطابع الزمني للاختبارات المضبوطة. أبقِ عناوين المستلِمين الكاملة والمحتوى خارج المقاييس الروتينية. قبول مزوّد SMTP وقبول خادم المستلِم والارتداد اللاحق وموضع مجلد صندوق البريد والتفاعل حالات لاحقة. إذا نجح DKIM لكن البريد رُفض أو رُشّح، فابحث في محاذاة DMARC وSPF وسمعة IP والنطاق ومعدل الشكاوى وسياسة الرسالة ومعدلها وإرشادات المستقبِل، بدلًا من تدوير المفاتيح مرارًا.

دوّر المفاتيح دون خلق فجوة في التحقق

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

شخّص الإخفاقات بدءًا من التوقيع إلى الخارج

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

استخدم وثائق DKIM لنظام الإرسال لديك

أعد DKIM في أنظمة الإرسال الفعلية وسلطة DNS، وتحقق من الرسائل الأصلية المستلمة، واعتمد على معايير IETF الحالية والوثائق الخاصة بالمزوّد.

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

المصادر

• RFC 6376: توقيعات البريد المعرَّف بمفاتيح النطاق (DKIM) — محرّر RFC
• RFC 8301: تحديث الخوارزمية التشفيرية واستخدام المفاتيح في DKIM — RFC Editor
• RFC 8463: طريقة توقيع تشفيرية جديدة لـ DKIM — RFC Editor
• RFC 7489: مصادقة الرسائل والإبلاغ والامتثال على مستوى النطاق (DMARC) — محرّر RFC
• RFC 8601: حقل ترويسة الرسالة للإشارة إلى حالة مصادقة الرسالة — RFC Editor
• RFC 5321: بروتوكول نقل البريد البسيط (SMTP) — محرّر RFC