سجل DKIM: الإعداد والمحددات وتدوير المفاتيح

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

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

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

هذا دليل تشغيلي لـ سجل DKIM: عمله في DNS، وحد 255 أوكتتا لكل سلسلة TXT، وتشخيص اختلاف شارة التحقق لدى ESP عن نتيجة الإرسال الفعلية.

ما سجل DKIM؟

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

يطلب المفتاح من selector._domainkey.yourdomain.com، حيث يشير selector إلى المفتاح. المثال التالي مختصر وغير قابل للنشر:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

يعرف v=DKIM1 الإصدار، ويحدد k=rsa نوع المفتاح، ويحمل p= المفتاح العام بترميز base64. يحفظ المفتاح الخاص في بنية إرسال آمنة ولا ينشر في DNS. يشرح دليل إنشاء سجل DKIM الحقول والخطوات بالتفصيل.

ما الذي يوقعه DKIM ولماذا يهم؟

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

يختار الخادم رؤوسا مثل From وSubject وDate وTo وMessage-ID مع الجسم المغطى. يجب توقيع From، وتتبع البقية الإعداد. يستخدم عادة SHA-256 ويوقع بـ المفتاح الخاص، ثم يضيف DKIM-Signature. يحدد التوقيع التغطية والتسوية الفعليتين.

يجري Gmail أو Outlook أو غيرهما فحوصا منها:

1. قراءة DKIM-Signature لتحديد النطاق والمحدد.
2. جلب المفتاح العام من selector._domainkey.yourdomain.com في DNS.
3. التحقق تشفيريا من التوقيع بالمفتاح العام، لا فك تشفير الرسالة.
4. إعادة حساب التجزئات للمحتوى المستلم والمغطى بعد التسوية.
5. فحص المطابقة وبقية شروط المفتاح والتوقيع لتحديد النجاح أو الفشل.

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

إعادة التوجيه وشروط بقاء DKIM

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

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

لا تعتمد على SPF وحده. اجمع DKIM مع إعداد SPF مناسب، وراجع SPF للبريد الإلكتروني للأساسيات. يمكن أن ينجح DMARC بإحدى الطريقتين المتوافقتين، دون ضمان للتسليم.

تصف TrekMail التوجيه باستخدام SRS (Sender Rewriting Scheme)، الذي قد يعيد كتابة الظرف ليساعد SPF لخدمة التوجيه، لا مطابقة From الأصلية. تحقق من نشاط توقيع DKIM على مسارات SMTP المدارة أو الخاصة الحالية، ولا تفترض قاعدة مضمونة لكل الإعدادات.

المحددات وإدارة عدة مفاتيح DKIM

يحدد محدد DKIM المفتاح العام المطلوب. أخطاء الاسم أو المحدد سبب مهم محتمل، وليست بالضرورة سبب معظم حالات الفشل.

لـ SPF سياسة واحدة لكل اسم DNS مقيم، بينما يمكن لـ DKIM استخدام محددات مختلفة على selector._domainkey.yourdomain.com. قد تدير عشرة محددات معا، مثلا واحدا لكل خدمة. تظل حدود المزود وDNS العملية قائمة؛ ليس ذلك وعدا بسجلات غير محدودة.

لماذا تفيد المحددات المتعددة؟

مع Google Workspace وMailchimp مثلا، يفضل عادة فصل المفاتيح والمحددات. مشاركة المفتاح الخاص ممكنة تقنيا في بعض البيئات لكنها توسع التعرض وتعقد الإلغاء. اتبع ما تدعمه كل خدمة. الأسماء التالية أمثلة لا قيما حالية عامة:

• Google Workspace: قد يكون المحدد google والمفتاح على google._domainkey.yourdomain.com.
• Mailchimp: قد يستخدم k1 أو k2. افحص TXT أو CNAME المطلوب لـ k1._domainkey.yourdomain.com.
• TrekMail: مثال المحدد tm1 على tm1._domainkey.yourdomain.com. استخدم إعداد TXT أو CNAME المدعوم فعليا.

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

خطأ شائع في الاسم

تقصد google._domainkey.yourdomain.com لكن اللوحة تضيف النطاق مرة أخرى فيصبح google._domainkey.yourdomain.com.yourdomain.com. قد يرجع الاسم المقصود NXDOMAIN وتكون شارة ESP قديمة. افحص الاسم والرد الحقيقيين باستخدام دليل حالة DNS واستعلام موجه.

طول المفتاح وسياسة التدوير

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

تفضيل مفاتيح 2048 بت

كانت RSA بطول 1024 بت شائعة لسنوات. تذكر Google حدا أدنى وتوصي بـ 2048 بت لإعداد أقوى؛ تحقق من إرشادات Yahoo الحالية منفصلة. إعداد cPanel أو Postfix قديم بطول 1024 بت قبل 2019 يستحق الفحص، لا افتراض أن كل توقيع يفشل حتما.

مفتاح 512 بت غير كاف للمتطلبات الحديثة. عند dkim=perm_fail مع "weak key" أو "policy"، اقرأ السبب الكامل. راجع زوجا جديدا بطول 2048 بت وانتقالا مدروسا، مع استجابة عاجلة عند التسريب. راجع إرشادات Google للمرسلين.

متى تدوّر المفاتيح؟

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

عامل المفتاح الخاص كسر حساس. استخدامه خمس سنوات دون تغيير مناسبة لإعادة تقييم السياسة؛ الحفظ الآمن والصلاحيات والاستجابة للحوادث مهمة بقدر الجدول.

حد DNS البالغ 255 أوكتتا ومعالجته

قد يفاجئ الطول من ينتقل إلى 2048 بت. يبلغ المفتاح العام بطول 2048 بت عند ترميزه base64 نحو 400 محرف. الحد لكل سلسلة DNS TXT هو 255 أوكتتا. قد تقسم اللوحات الإدخال أو ترفضه أو تعالجه خطأ، وليس من الدقة افتراض أن معظمها يقتطع بصمت.

يمكن تقسيم القيمة إلى سلاسل مقتبسة داخل سجل TXT نفسه. يتيح RFC 6376 جمعها للتحقق دون إضافة مسافات تلقائيا. لا تختصر المفتاح ولا تنشر نص المثال بدلا منه.

مثال مختصر غير قابل للنشر؛ معالجة الإدخال الطويل تختلف:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...

مثال تخطيطي بسلسلتين؛ استبدل كل العناصر النائبة بالمفتاح الكامل:

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

تختلف صيغة اللوحة حسب المزود؛ قد تخص الأقواس ملفات مناطق DNS لا جميع واجهات الإدخال. راجع إعداد DNS لدى المزودين المعروفين لـ Cloudflare وRoute 53 وGoDaddy وغيرهم، وتحقق من الواجهة الحالية.

قد يفوض CNAME المدعوم نشر المفتاح. يصف النموذج مرجعا قصيرا واحدا بدلا من مفتاح يتجاوز 255 محرفا. يمكن أن يقلل العمل المحلي، لكن افحص الهدف ومفتاحه والتدوير والتخزين المؤقت. لا يتعايش CNAME وTXT بالاسم نفسه، ولا يضمن المرجع الثابت تدويرا خاليا من الأخطاء.

التحقق من الإعداد

قد تستند "Verified" لدى ESP إلى بيانات قبل ساعات أو أيام. افحص DNS الحالي والخوادم الموثوقة والمحللات المعنية، ثم رسالة اختبار موقعة. قد يكون الاستعلام نفسه مخزنا مؤقتا، ولا يثبت DNS وحده صحة توقيع الخادم.

الخطوة 1: فحص وجود الاسم

نفذ في طرفية Linux أو macOS. على Windows استخدم nslookup:

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

استبدل selector بالمحدد الفعلي وyourdomain.com بنطاقك.

قد تبدأ القيمة بـ v=DKIM1، لكن وسم الإصدار ليس إلزاميا في كل سجل مفتاح صحيح. افحص NXDOMAIN عند ظهوره. يدل رد NXDOMAIN على اسم غير موجود في الإجابة المعنية؛ راجع المحدد والنشر والذاكرة المؤقتة. إعادة الاختبار بعد 30 دقيقة مثال لا مدة عالمية ثابتة.

الخطوة 2: فحص محتوى المفتاح

إذا وجد السجل واستمر الفشل، افحص القيمة الخام:

dig txt selector._domainkey.yourdomain.com +short

ركز على نقطتين:

• الاقتطاع: قيمة base64 أقل من 200 محرف لمفتاح مفترض بطول 2048 بت قرينة لفحص المفتاح المفكوك الكامل، لا دليل قاطع أن المزود اقتطعه.
• معالجة المحارف: افحص كيفية معالجة اللوحة للأسطر والمسافات ومحارف الهروب داخل base64. لا يغير كل اختلاف بصري المفتاح؛ قارن القيمة المنشورة والمفكوكة بالمفتاح العام المقصود.

الخطوة 3: اختبار الإرسال وقراءة الرؤوس

أرسل إلى Gmail تملكه وافتح الأصل من قائمة النقاط الثلاث. ابحث عن Authentication-Results وثق فقط بنتائج المستقبل، لا رؤوس أضافها المرسل. هذا مثال توضيحي:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

يؤكد dkim=pass نجاح فحص الاختبار المعني. اقرأ fail وneutral وperm_fail وtemperror مع السبب وصيغة التطبيق؛ neutral ليس خطأ دائما. يشرح دليل الإعداد المزيد، وتساعد قائمة الإعداد الأول في TrekMail في مراجعة المصادقة المرتبطة.

فشل DKIM: ثلاث حالات عملية

السجل الموجود على المحدد الصحيح لا يضمن توقيعا صحيحا. افحص معالجة الرسالة والمفتاح المستخدم وردود DNS عند استمرار الفشل.

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

الحالة 1: "Body Hash Did Not Verify"

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

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

• تنبيه المرسل الخارجي: قد تضيف البوابة "بريد خارجي: يرجى الحذر". إذا تغير الجسم المغطى قبل التحقق خارج التسوية المسموحة فقد يفشل DKIM. افحص قواعد تدفق Microsoft 365.
• تذييل إخلاء المسؤولية: قد يضيف خادم بوابة نصا قانونيا من 15 سطرا بعد توقيع خادم الصندوق فيتغير الجسم. وقع النسخة النهائية في مسارك الصادر.
• إعادة كتابة الروابط: قد تحول Mimecast وProofpoint وDefender for Office 365 الرابط google.com إلى protect.mimecast.com/s/.... قد يبطل تغيير الجسم المغطى التوقيع، بحسب التوقيت والتغطية.

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

الحالة 2: المطابقة

قد يجتمع توقيع صحيح مع فشل DMARC. مثلا:

dkim=pass (signature was valid)

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

يقارن DMARC النطاق في d= بنطاق Header From. تتطلب المطابقة الصارمة التطابق الكامل، وتسمح المرنة بالنطاق التنظيمي المشترك. يكفي توقيع DKIM صحيح ومتوافق واحد، أو SPF ناجح ومتوافق.

مثال توضيحي:

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

التوقيع صحيح لـ sendgrid.net. لكن سياسة DMARC المنشورة تخص نطاق المرسل الظاهر yourcompany.com، لا نطاق المستلم. sendgrid.net != yourcompany.com. هذا التوقيع غير متوافق؛ يفشل DMARC إن لم تنجح طريقة متوافقة أخرى.

افحص مصادقة النطاق أو توقيعه المخصص لدى ESP. قد يتيح مفتاح DKIM خاص ضبط d= إلى yourcompany.com بدل sendgrid.net حيث تدعم الخدمة ذلك. تختلف الميزات والخطط. افهم مطابقة DMARC واختبر المسارات الفعلية.

الحالة 3: مفاتيح قديمة أو ضعيفة

عند dkim=perm_fail مع "policy" أو "weak key" قد تكون مفاتيح 512 أو 768 بت ذات صلة، لكن توجد أسباب أخرى. تحقق من المفتاح والسبب الكامل. قد لا تستوفي الأطوال القديمة المتطلبات الحالية، ولا يثبت الوسم وحده طول المفتاح.

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

تقييم أمان مولدات المفاتيح

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

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

مقارنة طرق التوليد

يمكن توليد المفاتيح محليا بـ OpenSSL لخادم خاص. أمّن الصلاحيات والحفظ قبل تنفيذ الأمثلة:

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

احمِ المفتاح الخاص. ينشر في DNS المحتوى الصحيح للمفتاح العام دون غلاف PEM؛ أمر العرض لا يزيل الرؤوس بنفسه. لا ترسل المفتاح الخاص عبر البريد من أجل "التحقق"، وأكد الطلبات بقناة موثوقة.

قد تكون إدارة المزود أبسط للمؤسسين والمسؤولين والوكالات. تحقق من دعم التوليد والحفظ الآمن والتدوير الفعلي بدلا من افتراضه.

الإدارة اليدوية والآلية

يظهر التدوير تكلفة التشغيل. الجدول السنوي التالي مثال سياسة، وتحتاج كل مفاتيحك تحققا مناسبا حتى إن نفذ المزود العمل.

مثال تدوير سنوي يدوي لكل نطاق

1. أنشئ زوج RSA بمحدد جديد مثل s2026.
2. انشر المفتاح العام على s2026._domainkey.yourdomain.com.
3. يخصص المثال 48 ساعة لـ DNS؛ حدد الانتظار الفعلي من TTL والذاكرة والتحقق.
4. حوّل التوقيع إلى المفتاح الخاص الجديد واختبر.
5. يحتفظ المثال بالمحددين 7 أيام؛ اضبط التداخل حسب الطوابير وصلاحية التوقيع والمخاطر.
6. احذف المحدد العام القديم بعد المدة المناسبة، إلا إذا تطلب حادث إلغاء أسرع.
7. أتلف المفتاح الخاص القديم بأمان وفقا لسياسة الاحتفاظ.

يتضمن المثال 7 خطوات سنويا لكل نطاق. مع 50 نطاقا تكون 350 عملية، لا حجما فعليا ثابتا. تجاوز الخطوة 5 قد يؤثر في رسائل قيد النقل؛ نسيان الخطوة 6 قد يبقي المفتاح أطول من المطلوب. اجمع الأتمتة والتحقق.

قد تكون الإدارة اليدوية مناسبة لنطاق واحد. عند 50 نطاقا تساعد الأتمتة في التكرار والجدولة. لا يصبح أي نهج مستحيلا أو بلا خطأ تلقائيا؛ احتفظ بأدلة النشر والتدوير والاختبار.

إدارة DKIM في TrekMail

تستهدف TrekMail إدارة نطاقات متعددة، من مؤسس له خمسة مشاريع جانبية إلى مزود يدير 800 نطاق عميل. قيّم الإعداد الحالي لمساراتك الفعلية.

تفويض النشر باستخدام CNAME

يصف المصدر CNAME واحدا عند إضافة نطاق. التالي مثال، لا تأكيد للاسم أو الدعم الحالي:

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

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

يقارن مثال Pro بسعر $8 شهريا و100 نطاق النموذج بـ 700 عملية يدوية سنوية. هذه حسابات توضيحية للروتين المختار، لا ضمان توفير أو سعر حالي.

معالج DNS إرشادي

يساعد المعالج الموصوف في MX وSPF وDKIM وDMARC والتحقق. افحص الميزات الحالية وDNS الموثوق وذاكرة المحللات ورسالة موقعة فعلية. الشارة ليست تحقق كل المسارات. راجع سجلات DNS المطلوبة.

تسعير المنصة

يذكر المصدر Starter بسعر $3.50 شهريا مع 50 نطاقا و100 مستخدم لكل نطاق، وPro بسعر $8 مع 100 نطاق و300 مستخدم لكل نطاق، وAgency بـ 1,000+ نطاق. يوصف التخزين بأنه مجمع. تحقق من الأسعار والحدود والميزات الحالية؛ ليست إضافة الصناديق مجانية في كل ظرف.

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

إدارة سجل DKIM: ذاتيا أو بالتفويض

الخلاصة

يعد سجل DKIM الصحيح مهما للمصادقة الحديثة وشروط المرسل المنطبقة في 2025 وما بعدها. لا يعني غيابه فشل DMARC حتما إذا نجح SPF المتوافق، ولا يضر كل توجيه بالسمعة. افحص الطريقتين وسياسة المستقبل.

ابدأ بمفتاح مناسب مثل RSA بطول 2048 بت، ومحدد صحيح ونشر TXT كامل ومطابقة Header From. أضف تدويرا آمنا وسياسة DMARC ومراقبة، مثل Google Postmaster Tools مع مراعاة البيانات المتاحة.

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

قد تؤثر أخطاء المفتاح والنشر والمطابقة في المسارات المعنية عند تعدد النطاقات. يقلل التفويض العمل اليدوي دون إزالة فئات الأخطاء تماما. راجع الخطط وتحقق من الشروط الحالية للعرض الموصوف بـ 10 نطاقات دون بطاقة ائتمان.