مفتاح DKIM: الطول المناسب ونشر DNS والتدوير

مفتاح DKIM جزء من إعداد DNS الذي يستخدمه المستقبل للتحقق من بريدك. إذا كان ضعيفا أو غير صالح أو قديما، فقد تتأثر المصادقة ومعالجة الرسائل. يطبق Gmail متطلبات التحقق للمرسلين منذ فبراير 2024، ويصف تطبيقات إضافية بدأت في نوفمبر 2025؛ راجع الإرشادات الحالية. إذا كنت ترتب أساسيات DNS، فابدأ بمقال البريد التجاري.

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

عند إعداد نطاق جديد، اجمع ذلك مع إنشاء بريد باستخدام نطاقك وقائمة سجلات DNS المطلوبة من TrekMail لتهيئة DKIM وSPF وDMARC معا.

ما مفتاح DKIM؟

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

DKIM اختصار لـ DomainKeys Identified Mail. يبقى المفتاح الخاص في نظام الإرسال، وينشر العام تحت محدد في DNS مثل s1._domainkey.example.com.

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

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

لا يضمن هذا الوصول إلى صندوق الوارد، لكنه يقدم إشارة تحقق تشفيرية يمكن لأنظمة التصفية الحديثة استخدامها.

ما طول مفتاح DKIM المناسب؟

يعد RSA بطول 2048 بت توصية شائعة لعامي 2025 و2026. يسمح المعيار بـ RSA بطول 1024 بت، لكن 2048 بت يمنح هامشا تشفيريا أكبر ويكون غالبا أكثر عملية من 4096 بت، الذي يزيد حجم ردود DNS وقد يسبب صعوبات توافق. تحقق من دعم أنظمتك.

تحدد RFC 8301 الحد الأساسي: يجب استخدام RSA بطول 1024 بت على الأقل، ويوصى بـ 2048 بت على الأقل. لهذه التوصية وزن في اختيار الإعداد التشغيلي.

إذا تسلمت نظام بريد قديما، فلا تفترض أن المفتاح مناسب. ولدت لوحات وأنظمة قديمة مفاتيح 1024 بت افتراضيا. افحص إمكانية الترقية الآن.

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

لماذا يتعطل نشر مفتاح 2048 بت في DNS؟

قد يفشل نشر مفتاح 2048 بت لأن كل سلسلة TXT منفردة في DNS لا تتجاوز 255 ثمانية. المفتاح العام أطول، وقد ترفض لوحة DNS القيمة الطويلة أو تقتطعها أو تخزنها بطريقة خاطئة.

هنا تتكرر الأخطاء. المشكلة غالبا في واجهة DNS، لا في التشفير.

قيمة p= لمفتاح RSA بطول 2048 بت قد تحتاج إلى عدة سلاسل مقتبسة داخل سجل TXT واحد. يجمع تطبيق التحقق من DKIM هذه السلاسل، وليس من الضروري أن يحولها محلل DNS إلى سلسلة واحدة. قد يفشل التحقق إذا نشرت بصورة غير صحيحة.

أخطاء شائعة:

• تقتطع لوحة DNS القيمة عند 255 ثمانية.
• تضيف اللوحة مسافات أو فواصل أسطر داخل المفتاح.
• تنشر عدة سجلات TXT بدلا من سجل واحد ذي عدة سلاسل.
• تحذف جزءا من البادئة v=DKIM1; k=rsa; p= لمحاولة تقصير القيمة.

لا ينتج عن ذلك مفتاح أضعف، بل نشر غير صالح للمفتاح.

كيف تنشر مفتاح 2048 بت بدقة؟

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

صياغة ملف المنطقة:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

تطلب واجهات ويب كثيرة السجل نفسه على سطر واحد:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

تحقق من الخارج، لا من معاينة الواجهة وحدها.

dig txt s1._domainkey.example.com +short

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

في TrekMail، اتبع دليل SMTP المدار من TrekMail ومعالج DNS. تذكر الخطط المدفوعة SMTP مدارا وقيمة سجل DKIM الخاصة بالنطاق في اللوحة. السعر الابتدائي المذكور لـ Starter هو $3.50 شهريا، مع تجربة مدتها 14 يوما تتطلب بطاقة ائتمان. تعرض Nano كخطة مجانية تستخدم SMTP الخاص بك. تحقق من الشروط الحالية.

مثال: تنشئ مفتاح 2048 بت وتلصقه لدى مسجل يقتطع قيم TXT الطويلة دون تنبيه. تستمر الرسائل بمغادرة خادمك، لكن المستقبل لا يستطيع التحقق من توقيع DKIM. لهذا يلزم الفحص الخارجي.

تدوير مفتاح DKIM مع تقليل مخاطر البريد

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

إجراء حذر:

1. أنشئ زوج مفاتيح DKIM جديدا بطول 2048 بت.
2. خصص محددا جديدا مثل s2.
3. انشر s2._domainkey.example.com في DNS.
4. انقل إعداد توقيع البريد الصادر إلى s2.
5. أبق s1 منشورا عدة أيام على الأقل، وفق طوابيرك وسياساتك.
6. احذف s1 بعد إتاحة وقت كاف للرسائل الموقعة سابقا.

مثال عملي للفترة الانتقالية هو 7 أيام. ليس ذلك ضمانا لانتهاء كل التأخيرات وإعادة المحاولة والذاكرة المؤقتة. إذا كشف المفتاح، فقد يكون إلغاؤه فورا أهم من مهلة الانتقال.

لا تستبدل المفتاح تحت المحدد نفسه إلا إذا فهمت آثار التوقيع والتسليم والتخزين المؤقت. لا تستطيع معظم الفرق التحكم في كل الحالات. استخدم المحددات للغرض الذي صممت له.

مع عدة أنظمة إرسال، وثق النظام المرتبط بكل محدد. يفيد ذلك في تشخيص مشكلات CRM ومنصات الدعم وتطبيقات الويب ومزودي الصناديق الذين يشتركون في النطاق.

متى تدور مفتاح DKIM؟

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

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

أسباب للتدوير المبكر:

• نقلت الإرسال إلى مزود آخر.
• أنهيت التعامل مع مزود امتلك وصولا للتوقيع.
• صدرت المفاتيح عبر إجراء غير آمن.
• وجدت حساب إدارة مشتركا قديما دون مسؤول واضح.

أسباب لا تصلح للتأجيل:

• «سنفعل ذلك لاحقا عندما نجد وقتا».
• «المفتاح الحالي ما زال ينجح، فلا مشكلة».
• «لا نتذكر مكان المفتاح الخاص».

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

هل تستخدم Ed25519 لمفتاح DKIM؟

يوفر Ed25519 مفتاحا أقصر ويتجنب قيم TXT الطويلة المرتبطة بـ RSA-2048. الاعتبار الأساسي هو توافق المستقبل. وحد لاستخدام DKIM في RFC 8463، لكن RSA-2048 يبقى اختيارا افتراضيا شائعا للتوافق الواسع.

الميزة التشغيلية هي الحجم. مفتاح Ed25519 العام أصغر كثيرا من RSA، مما قد يبسط نشره في DNS.

العيب هو تفاوت الدعم. تعالجه بعض الأنظمة والأدوات جيدا، بينما تحتاج بيئات أخرى إلى اختبار. يعد RSA-2048 خيارا شائعا للتوافق الواسع، دون ضمان شامل. إذا دعمت المنصة توقيعا مزدوجا وفهمت مسار البريد، يمكن اختبار Ed25519 إلى جانب RSA.

لمعظم المشغلين:

• استخدم RSA-2048 افتراضيا.
• استخدم Ed25519 عندما تفهم التوافق وتستطيع اختباره.
• لا تنتقل إلى Ed25519 وحده لأن سجل DNS يبدو أقصر.

النهج القديم والجديد لإدارة DKIM على نطاق واسع

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

النهج القديم:

• واجهة DNS مختلفة لكل نطاق.
• تدوير المفتاح يعتمد على تذكير قد يهمله أحد.
• خطأ لدى مسجل يعطل تحقق عميل ولا يكتشف حتى يتراجع الوصول.

النهج الجديد:

• إجراء موحد لنطاقات كثيرة.
• SMTP مدار يوقع وفق الإعداد المعتمد.
• تقليل التشخيص المتكرر لسجلات TXT الطويلة واختلافات التحقق.

يركز TrekMail على استضافة عدة نطاقات بسعر ثابت دون رسوم لكل مستخدم. تشمل الميزات المعلنة تخزينا مشتركا وصناديق IMAP وترحيل IMAP مدمجا وcatch-all والتوجيه وBYO SMTP على Nano وSMTP مدارا على الخطط المدفوعة. يخضع التوفر للشروط. مع قواعد التوجيه قد تختلف نتائج التحقق؛ اقرأ أيضا توجيه بريد النطاق إلى Gmail.

الفائدة للفرق والوكالات ليست جعل DNS سحريا، بل تقليل العمل المتكرر وتحسين الرؤية. السعر الابتدائي المذكور لـ Starter هو $3.50 شهريا؛ تحقق من الأسعار والفوترة الحالية.

الخلاصة حول مفتاح DKIM

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

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