يعني تدوير مفاتيح DKIM استبدال زوج المفاتيح الذي يوقّع بريدك، وفق جدول زمني أو بعد مخاوف أمنية، دون كسر المصادقة. يبدو الأمر محفوفًا بالمخاطر لأن أي خطوة خاطئة تجعل الرسائل المشروعة تفشل، لكن تصميم DKIM يجعله مباشرًا: تتيح المحددات نشر مفتاح جديد بجانب القديم، وتحويل التوقيع، ثم إنهاء القديم لاحقًا. يشرح هذا الدليل كيف يعمل ذلك ويقدم خطة تدريجية.
كيف يعمل توقيع DKIM والمحددات
عندما ترسل منصتك رسالة، تنشئ توقيعًا باستخدام مفتاح خاص وتضيفه إلى الترويسات. يذكر التوقيع نطاق التوقيع، ويُكتب d=، ومحددًا، ويُكتب s=. يبني المستقبل اسم DNS منهما، selector._domainkey.domain، ويجلب المفتاح العام المنشور هناك ويتحقق من التوقيع. إذا تطابق المفتاح ولم تتغير الأجزاء الموقّعة من الرسالة، ينجح DKIM.
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.com; s=2026a;
h=from:to:subject:date:message-id; bh=...; b=...في هذا المثال المحدد هو 2026a، لذا يبحث المستقبل عن 2026a._domainkey.mail.example.com. ولأن المحدد مجرد تسمية تختارها، يمكنك نشر عدة محددات في وقت واحد. وهذه هي الحيلة كلها وراء التدوير: يستمر المحدد القديم في التحقق من البريد القديم بينما يوقّع المحدد الجديد البريد الجديد.
لماذا ندوّر المفاتيح أصلًا
- الحد من الانكشاف. المفتاح الخاص الذي يعيش سنوات اطّلعت عليه أنظمة وأشخاص أكثر. يقلل التدوير من قيمة أي تسريب سابق.
- الاستجابة لتغيّر الموظفين. إذا غادر مسؤول كان يملك صلاحية الوصول إلى المفتاح، فإن استبداله يزيل خطرًا عالقًا.
- الانتقال إلى مفاتيح أقوى. لا تزال نطاقات قديمة كثيرة تنشر مفاتيح بطول 1024 بت. والتدوير هو اللحظة الطبيعية للترقية.
- تلبية السياسات. تسأل المراجعات الأمنية وبعض استبيانات العملاء عن وتيرة تغيير المفاتيح.
- إبقاء العملية متمرَّنًا عليها. الفريق الذي يدوّر مرتين سنويًا يتعامل بهدوء مع أي تدوير طارئ.
التدوير ليس أداة لقابلية التسليم. تغيير المفاتيح لا يحسّن الوصول إلى صندوق الوارد بحد ذاته. غرضه الأمان والنظافة التشغيلية. نفّذه بعناية كي لا يضر بالتسليم، ولا تتوقع تحسنًا في السمعة.
اختيار طول المفتاح
يحدد معيار DKIM طول 1024 بت كحد أدنى للموقّعين ويوصي بـ 2048 بت. ولا يُطلب من المتحققين قبول أي شيء أقصر من 1024 بت. بالنسبة لمعظم المرسلين، الخيار المعقول اليوم هو RSA بطول 2048 بت، فهو يوفر هامش أمان مريحًا دون كلفة أداء كبيرة.
| طول المفتاح | الوضع | ملاحظة عملية |
|---|---|---|
| 512 بت | غير مقبول | يُعدّ مكسورًا وترفضه جهات الاستقبال الحديثة |
| 1024 بت | الحد الأدنى المسموح، ولا يزال شائعًا | يعمل، لكن قم بالترقية عند التدوير القادم |
| 2048 بت | موصى به | يحتاج إلى قيمة TXT مقسمة إلى عدة سلاسل أو إلى CNAME |
| 4096 بت | يسمح به المعيار | نادرًا ما يلزم، وقد يتجاوز السجل حدود حجم DNS العملية |
حد الـ 255 حرفًا
يمكن للسلسلة الواحدة في سجل TXT أن تحمل 255 حرفًا كحد أقصى، والمفتاح العام بطول 2048 بت أطول من ذلك. لذا يضم السجل عدة سلاسل بين علامتي اقتباس يضمها المستقبل معًا. تتعامل معظم مزوّدات DNS مع ذلك عند لصق قيمة طويلة. فإذا لم يفعل مزوّدك، فقسّمها يدويًا أو اسأل منصة الإرسال عن خيار CNAME.
2026a._domainkey.mail.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
"...rest of the public key..." )قبل أن تبدأ: نموذجان لإدارة المفاتيح
| النموذج | كيف يعمل | ما عليك فعله للتدوير |
|---|---|---|
| تديره المنصة (CNAME) | تنشر سجل CNAME من محددك إلى اسم تتحكم فيه المنصة، وتغيّر المنصة المفتاح خلفه | القليل أو لا شيء؛ تأكد من الجدول الزمني ومن بقاء CNAME في مكانه |
| يديره العميل (TXT) | تنشر المفتاح العام بنفسك، وتوقّع المنصة بالمفتاح الخاص الذي زوّدتها به أو الذي أنشأته | اتبع الخطة الكاملة أدناه |
| توقيع مستضاف ذاتيًا | يوقّع خادم بريدك الخاص، وتحتفظ أنت بالمفتاح الخاص | أنشئ المفاتيح، وحدّث إعدادات الخادم وDNS |
خطة تدوير آمنة
- احصر المحددات. أدرج كل محدد منشور تحت _domainkey للنطاق، وحدّد النظام الذي يستخدم كلًا منها. المحددات المجهولة نتيجة بحد ذاتها؛ لا تحذفها حتى تعرف ما الذي يوقّع بها.
- اختر نظام تسمية. استخدم محددات تتضمن تاريخًا أو رقمًا تسلسليًا، مثل 2026a و2027a، لتميّز المفاتيح بنظرة واحدة.
- أنشئ المفتاح الجديد. أنشئ زوج مفاتيح بطول 2048 بت، أو اطلب من منصتك إصدار واحد. احفظ المفتاح الخاص فقط في المكان الذي يحتاجه نظام التوقيع.
- انشر المفتاح العام الجديد. أضف سجل المحدد الجديد. لا تلمس القديم. تأكد من أنه يُحلّ من خارج شبكتك.
- اختبر قبل التحويل. وقّع رسالة اختبار بالمحدد الجديد وتأكد من نجاح DKIM في الترويسات المستلمة.
- حوّل التوقيع. غيّر إعدادات التوقيع لاستخدام المحدد الجديد لجميع الرسائل الجديدة. ومن هذه اللحظة لا يوقّع المفتاح القديم أي شيء جديد.
- راقب. تابع تقارير DMARC المجمّعة وبيانات الارتداد بحثًا عن ارتفاع في إخفاقات DKIM خلال الأيام التالية.
- انتظر الرسائل المتأخرة. أبقِ السجل القديم منشورًا عدة أيام على الأقل. تُفحص الرسائل المنتظرة والمعاد إرسالها والمعاد توجيهها عند معالجتها لا عند إرسالها.
- أنهِ المفتاح القديم. أزل سجل المحدد القديم واحذف المفتاح الخاص القديم من كل نظام كان يحتفظ به.
- وثّق التدوير. دوّن التاريخ والمحدد الجديد وموعد التدوير القادم في دليل التشغيل لديك.
إلى متى تُبقي المفتاح القديم
يجب أن يبقى المفتاح العام القديم في DNS إلى أن لا تبقى أي رسالة موقّعة به قيد النقل أو بانتظار التحقق. بالنسبة للبريد التعاملي والتسويقي المعتاد، تكفي بضعة أيام. وإذا كنت ترسل عبر قوائم بريدية أو خدمات إعادة توجيه تحتجز الرسائل، أو كان جدول إعادة المحاولة لديك طويلًا، فانتظر أكثر. إبقاء مفتاح قديم منشورًا مدة أطول قليلًا لا يكلّف شيئًا. أما إزالته مبكرًا جدًا فيسبب إخفاقات يصعب تشخيصها.
ما الذي قد يسوء وكيف تكتشفه
| المشكلة | العلامة | الحل |
|---|---|---|
| عدم تطابق المحدد | يفشل DKIM مع رسالة تفيد بأن المفتاح غير موجود | قارن قيمة s= في التوقيع مع اسم DNS |
| مفتاح عام مبتور | يفشل DKIM مع مفتاح غير صالح أو عدم تطابق التوقيع | أعد لصق المفتاح وتأكد من وجود كل أجزاء السلاسل |
| إزالة المفتاح القديم مبكرًا | إخفاقات في الرسائل المتأخرة فقط | أعد السجل القديم وانتظر مدة أطول في المرة القادمة |
| لم يُحوَّل التوقيع | لا يظهر المحدد الجديد أبدًا في الترويسات | افحص إعدادات التوقيع وأي إعدادات مخزنة مؤقتًا |
| نظامان يتشاركان محددًا | إخفاقات متقطعة بعد تدوير أحد النظامين | امنح كل نظام محدده الخاص |
| إزالة CNAME أثناء التنظيف | يفشل DKIM فجأة في كل مكان لمفتاح تديره المنصة | أعد CNAME تمامًا كما قُدِّم لك |
استخدم التقارير لتأكيد النجاح
تبيّن تقارير DMARC المجمّعة، لكل مصدر إرسال، عدد الرسائل التي نجحت أو فشلت في DKIM وSPF. راجعها في الأيام التي تلي التدوير. يظهر في التدوير السليم المحدد الجديد ويبقى عدد الإخفاقات ثابتًا. وإذا ارتفعت الإخفاقات لمصدر واحد، فعلى الأرجح أنه ما زال يوقّع بمفتاح لم يعد منشورًا. يشرح دليلنا حول تقارير DMARC المجمّعة كيفية قراءتها.
التدوير الطارئ
إذا اشتبهت في انكشاف مفتاح خاص، فدوّر فورًا وقصّر فترة التداخل. انشر مفتاحًا جديدًا وحوّل إليه بأسرع ما يمكنك بأمان، ثم أزل المفتاح المخترق حتى لو فشلت بعض الرسائل المتأخرة. يمكن لمهاجم يملك المفتاح الخاص القديم أن يوقّع رسائل مزوّرة تنجح في DKIM لنطاقك طالما بقي المفتاح العام منشورًا، لذا فإن نافذة الانكشاف أهم من خسارة بضع رسائل متأخرة. تحدّ سياسة DMARC المُطبّقة وسياسة الرفض من أثر مثل هذه التزويرات، لكن ينبغي مع ذلك إنهاء المفتاح سريعًا.
اجعل التدوير روتينيًا
- ضع موعد التدوير في تقويم مشترك مع مسؤول محدد بالاسم.
- احتفظ بجدول للمحددات والأنظمة التي تستخدمها وتواريخ إنشائها.
- استخدم محددًا مخصصًا لكل نظام إرسال.
- فعّل تنبيهات على معدلات إخفاق DKIM، لتُكتشف أي عملية تدوير خاطئة خلال ساعات.
- جرّب أولًا على نطاق فرعي منخفض المخاطر إذا كانت العملية جديدة على فريقك.
تحتاج إلى مساعدة في التخطيط للتدوير؟ أخبرنا بالنطاقات وأنظمة الإرسال التي تستخدمها وسنقترح عليك ترتيبًا آمنًا.
قراءات إضافية ومصادر
الأسئلة الشائعة
ما هو محدد DKIM؟
المحدد (selector) هو تسمية تخبر المستقبلين بأي مفتاح عام يجب جلبه. يذكر التوقيع محددًا ونطاقًا، فيبحث المستقبل عن سجل DNS في selector._domainkey.domain. ولأن المحدد جزء من الاسم، يمكن للنطاق الواحد نشر عدة مفاتيح في وقت واحد، وهذا ما يجعل التدوير آمنًا.
كم مرة ينبغي تدوير مفاتيح DKIM؟
لا توجد فترة إلزامية واحدة. تدوّر كثير من المؤسسات المفاتيح مرة أو مرتين سنويًا، أو كلما غادر شخص يملك صلاحية الوصول إلى المفتاح الخاص، أو عند الاشتباه في اختراق. اختر جدولًا ستلتزم به فعلًا، ودوّر مبكرًا إذا اشتبهت يومًا في انكشاف مفتاح.
أي طول لمفتاح DKIM ينبغي أن أستخدم؟
استخدم RSA بطول 2048 بت حيثما يدعمه مزوّد DNS ونظام الإرسال لديك. يشترط معيار DKIM على الموقّعين استخدام 1024 بت على الأقل ويوصي بـ 2048، ويجب ألا يقبل المتحققون مفاتيح أقصر من 1024. وتمنحك المفاتيح الأطول هامش أمان أكبر مع تزايد القدرة الحاسوبية.
لماذا يرفض مزوّد DNS مفتاحي ذا 2048 بت؟
المفتاح العام بطول 2048 بت أطول من 255 حرفًا، وهو الحد الأقصى لسلسلة واحدة في سجل TXT. لذا يجب تقسيمه إلى عدة سلاسل بين علامتي اقتباس يضمها المستقبل معًا. يقسمه كثير من المزوّدين تلقائيًا؛ فإذا لم يفعل مزوّدك، فقسّمه يدويًا أو استخدم CNAME يشير إلى السجل المستضاف لدى المنصة.
هل يمكنني حذف المفتاح القديم فور التحويل؟
ليس بأمان. قد تتأخر الرسائل في الطوابير أو تُعاد محاولة إرسالها لأيام، ويتحقق المستقبلون من التوقيع عند معالجة الرسالة. أبقِ السجل القديم منشورًا عدة أيام على الأقل، وأطول من ذلك إذا كنت ترسل عبر مسارات إعادة توجيه بطيئة.
ماذا يحدث إذا أزلت مفتاحًا ما زال قيد الاستخدام؟
تفشل الرسائل الموقّعة بذلك المحدد في التحقق من DKIM. إذا كان SPF متوافقًا (aligned) فقد يظل DMARC ناجحًا، أما إذا لم يتوافق SPF فقد تُحجر الرسالة أو تُرفض في ظل سياسة DMARC مُطبّقة. ولهذا يُحوَّل التوقيع أولًا ويُزال المفتاح القديم لاحقًا.
هل تدوّر منصة الإرسال لدي المفاتيح نيابة عني؟
تدير بعض المنصات مفاتيح DKIM وتنشرها عبر CNAME توجّهه مرة واحدة، فيتم التدوير من جانبها. وتعطيك منصات أخرى سجلًا ثابتًا عليك استبداله بنفسك. تحقق من النموذج الذي تعتمده منصتك قبل أن تخطط للتدوير.
هل ينبغي أن تستخدم مسارات البريد المختلفة محددات مختلفة؟
نعم، هذه ممارسة جيدة. فالمحددات المنفصلة للرسائل التعاملية والتسويقية والأنظمة الداخلية تسهّل تدوير أحدها أو إلغاءه دون التأثير في البقية، كما تجعل تحليل الترويسات أوضح.
هل يمكنني اختبار مفتاح قبل التحويل إليه؟
نعم. انشر السجل الجديد أولًا وتأكد من أنه يُحلّ، ثم أرسل رسائل اختبار موقّعة بالمحدد الجديد إلى صندوق بريد تتحكم فيه، وتحقق من نجاح DKIM في الترويسات قبل تحويل كامل الحركة.