ما هو DKIM، وكيف يعمل توقيع DKIM؟

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

ما هو DKIM؟

DKIM اختصار DomainKeys Identified Mail (البريد المعرَّف بمفاتيح النطاق). وهو معرَّف في RFC 6376، وهي وثيقة من فئة Standards Track صدرت في سبتمبر 2011. ويقول الـ RFC إن DKIM «يتيح لشخص أو جهة وظيفية أو مؤسسة أن تعلن تحمّلها قدرًا من المسؤولية عن رسالة، من خلال ربط اسم نطاق بها».

وهو يعمل بزوج من المفاتيح:

• تحتفظ منصة البريد لديك بمفتاح خاص وتستخدمه لتوقيع كل رسالة صادرة.
• يُنشر المفتاح العام المقابل في DNS تحت نطاقك.
• يقرأ المستقبِل التوقيع، ويجلب المفتاح العام، ويتحقق من تطابقهما.

ثلاثة أمور لا يقوم بها DKIM:

• ليس تشفيرًا. تظل الرسالة قابلة للقراءة. يثبت DKIM المصدر وسلامة المحتوى فقط.
• ليس فحصًا لعنوان From. يمكن أن يكون النطاق الموقِّع أي نطاق. وربطه بعنوان From الظاهر هو مهمة DMARC.
• ليس سببًا للرفض بمفرده. ينص القسم 6.3 من RFC 6376 على أن المستقبِلين «لا ينبغي (SHOULD NOT)» أن يبنوا قرار قبول الرسالة على مجرد غياب التوقيع أو تعذّر التحقق منه، لأن «هذا الرفض سيسبب مشكلات حادة في التوافق التشغيلي».

كيف يعمل توقيع DKIM؟

عندما يرسل خادمك رسالة، فإنه:

1. يختار الرؤوس التي سيوقّعها ويدرجها في h=. رأس From: «يجب (MUST) أن يُوقَّع» (القسم 5.4 من RFC 6376).
2. يطبّق التوحيد القياسي (canonicalization) على الرؤوس والنص: أي يوحّد صيغتهما وفق القواعد المختارة كي لا تُفسد التغييرات الصغيرة غير الضارة أثناء النقل التوقيع.
3. يحسب تجزئة (hash) النص ويضع النتيجة في bh=.
4. يحسب تجزئة الرؤوس الموقَّعة، بما فيها رأس DKIM-Signature الجديد نفسه مع b= فارغة، ويوقّع تلك التجزئة بالمفتاح الخاص.
5. يكتب التوقيع في b= ويضيف رأس DKIM-Signature إلى أعلى الرسالة.

يبدو التوقيع هكذا (مختصرًا):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s202610;
  h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB...

كيف يتحقق الخادم المستقبِل من توقيع DKIM؟

1. يقرأ رأس DKIM-Signature ويتحقق من الوسوم الإلزامية.
2. يجلب المفتاح العام باستعلام DNS من نوع TXT عن <s>._domainkey.<d>، مثل s202610._domainkey.example.com.
3. يعيد حساب تجزئة النص بالتوحيد القياسي نفسه ويقارنها بـ bh=. وعدم التطابق هو الخطأ المألوف «body hash did not verify» (تعذّر التحقق من تجزئة النص).
4. يتحقق من b= مقابل الرؤوس الموقَّعة باستخدام المفتاح العام.
5. يسجّل النتيجة، مثل dkim=pass header.d=example.com في Authentication-Results.

قد تحمل الرسالة عدة توقيعات، من المرسل وخدمة البريد والقائمة البريدية. ولا يجعل التوقيع المعطوب الرسالة أسوأ من رسالة غير موقَّعة: ينص RFC 6376 على أن أداة التحقق «لا ينبغي (SHOULD NOT) أن تعامل رسالة تحمل توقيعًا معطوبًا واحدًا أو أكثر ولا تحمل توقيعًا سليمًا معاملة مختلفة عن رسالة بلا توقيع إطلاقًا».

ما هو التوحيد القياسي في DKIM؟

يُعاد تحرير البريد تحريرًا طفيفًا أثناء النقل: يُعاد لفّ أسطر الرؤوس، وتُحذف المسافات الزائدة في نهايات الأسطر. ويحدد التوحيد القياسي مقدار ما يتحمله التوقيع من ذلك. يعرّف القسم 3.4 من RFC 6376 خوارزميتين لكل من الرؤوس والنص، وتُكتب بالصيغة c=header/body.

يقول الـ RFC إن الوضع relaxed «يتحمل التعديلات الشائعة مثل استبدال المسافات وإعادة لفّ أسطر حقول الرؤوس». وإذا غابت c=، يُطبَّق simple/simple. ولا يصمد أي من الوضعين أمام تغييرات فعلية في المحتوى، مثل تذييل تضيفه قائمة بريدية أو إخلاء مسؤولية تضيفه بوابة.

ما هي محدِّدات DKIM ومفاتيح DNS؟

المحدِّد (selector) يسمّي مفتاحًا واحدًا من بين عدة مفاتيح للنطاق نفسه. يقدّمها القسم 3.1 من RFC 6376 «لدعم عدة مفاتيح عامة متزامنة لكل نطاق موقِّع». وهذا ما يتيح لكل خدمة إرسال أن يكون لها مفتاحها الخاص، ويتيح لك استبدال مفتاح دون انقطاع.

يقع المفتاح على العنوان <selector>._domainkey.<domain>:

s202610._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

يختلف المزوّدون في طريقة نشر المفاتيح. تستخدم Microsoft 365 سجلَّي CNAME، هما selector1 وselector2، يشيران إلى مفاتيح تستضيفها Microsoft وتدوّرها. أما Google Workspace فتطلب منك نشر سجل TXT واحد، افتراضيًا على google._domainkey (Google). تسرد صفحاتنا عن سجلات DKIM حسب المزوّد السجلات الخاصة بالخدمات الشائعة، ويوضح دليل كيف تعثر على محدِّد DKIM كيفية قراءته من رسالة.

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

حدّث RFC 8301 قواعد التشفير في DKIM عام 2018:

استخدم RSA بطول 2048 بت. المشكلة تكمن في DNS: فالمفتاح العام بطول 2048 بت أطول من أن يتسع في سلسلة TXT واحدة من 255 حرفًا، لذا يُخزَّن في عدة سلاسل يعيد المستقبِلون دمجها. يتعامل معظم مزوّدي DNS مع ذلك؛ أما إذا كان مزوّدك يقتطع المفتاح، فسيفشل التوقيع.

ماذا عن Ed25519؟

يضيف RFC 8463 خوارزمية Ed25519-SHA256، التي «تتميز بمفاتيح أقصر بكثير من RSA لمستويات أمان مماثلة». يستخدم سجل مفتاحها k=ed25519، ولا يتجاوز طول المفتاح العام 44 حرفًا بترميز base64، فيتسع في سلسلة TXT واحدة. ينص الـ RFC على أن أدوات التحقق «يجب (MUST)» أن تدعمها، لكن كبار مزوّدي صناديق البريد لا يوثّقون ما إذا كانوا يفعلون ذلك، ولا توثّق Microsoft 365 لتوقيع DKIM لديها إلا مفاتيح RSA (بطول 1024 أو 2048 بت). ويقدّم القسم 6 من RFC 8463 المسار الآمن: وقّع بالخوارزميتين، كلٌّ تحت محدِّد خاص بها.

ما علاقة DKIM بـ DMARC؟

يجيز DMARC (RFC 9989) الرسالة عندما ينجح SPF أو DKIM لنطاق يتوافق مع نطاق From. وفي حالة DKIM، فإن النطاق المعتبر هو d=. ويشرح RFC 9989 سبب الحاجة إلى التوافق: «يمكن أن تحمل الرسالة توقيعًا صالحًا من أي نطاق، حتى من نطاق تستخدمه جهة خبيثة».

لذا ليس كل نجاح مفيدًا. فإذا كانت أداة النشرات البريدية لديك توقّع بـ d=vendor-mail.net، ينجح DKIM، لكن DMARC للنطاق example.com لا يستفيد منه شيئًا. فعّل التوقيع بالنطاق المخصص في كل خدمة كي تكون d= نطاقك أو نطاقًا فرعيًا منه.

يهم DKIM في DMARC أكثر من SPF، لأنه يصمد عمومًا أمام إعادة التوجيه. ينص القسم 7.4 من RFC 9989 على أن البريد المعاد توجيهه «سيفشل على الأرجح في فحوصات SPF» بينما «تظل توقيعات DKIM صالحة عمومًا»، وعلى أن النطاقات التي تنشر p=reject «يجب (MUST) أن تضع توقيعات DKIM صالحة على رسائلها». وللصورة الكاملة، راجع ما هو DMARC وSPF مقابل DKIM مقابل DMARC.

ما الذي يعطّل DKIM؟

الصف الأول هو الأكثر شيوعًا. ويتناول دليلنا عن خطأ DKIM «body hash did not verify» كل حالة فشل بالتفصيل.

كم مرة ينبغي تدوير مفاتيح DKIM؟

تنص إرشادات M3AAWG لتدوير المفاتيح على أنه «ينبغي تدوير مفاتيح DKIM مرة كل ستة أشهر على الأقل»؛ وقد خففت مراجعتها الصادرة في أبريل 2018 الدورة الربع سنوية السابقة. وتجعل المحدِّدات العملية سهلة، كما يصف القسم 3.1 من RFC 6376: انشر المفتاح الجديد تحت محدِّد جديد، وحوّل التوقيع إليه، وأبقِ المفتاح العام القديم منشورًا ما دام البريد الموقَّع به قد يكون في الطريق. ثم ألغِ المفتاح القديم.

تبدّل Microsoft 365 بين محدِّديها الاثنين عندما تطلب ذلك، وتوثّق Microsoft Learn الخطوات. وتجد الإجراء الكامل للمنصات الأخرى في تدوير مفاتيح DKIM.

كيف أُعدّ DKIM؟

1. أدرج كل خدمة ترسل باسم نطاقك، كما تفعل مع SPF.
2. فعّل التوقيع بالنطاق المخصص في كل منها. تولّد معظم الخدمات المفتاح وتعرض لك سجل TXT أو CNAME لنشره. ويشرح دليل إعداد DKIM في Microsoft 365 وGoogle Workspace المنصتين الكبيرتين خطوة بخطوة.
3. هل تشغّل خادم بريد خاصًا بك؟ أنشئ زوج مفاتيح بطول 2048 بت باستخدام DKIM Key Generator (مولّد مفاتيح DKIM)، الذي ينشئ المفتاح داخل متصفحك، واضبط خادمك ليوقّع به.
4. انشر السجل لدى مزوّد DNS، ثم افحصه باستخدام DKIM Checker (أداة فحص DKIM).
5. أرسل رسالة اختبار إلى صندوق بريد خارجي وتأكد من ظهور dkim=pass مع نطاقك في header.d، مستخدمًا Email Header Analyzer (محلّل رؤوس الرسائل).
6. انشر DMARC كي يتصرف المستقبِلون بناءً على النتيجة.

أدلتنا عن DKIM

الخطوات التالية

1. افحص المحدِّدات وقوة المفاتيح لديك باستخدام DKIM Checker.
2. تأكد من أن كل خدمة إرسال توقّع بنطاقك في d=، لا بنطاق المزوّد.
3. استبدل أي مفتاح بطول 1024 بت بمفتاح بطول 2048 بت عند التدوير التالي، وأدرج التدوير في جدولك الزمني.
4. بعد أن ينجح DKIM في كل مكان، انقل سياسة DMARC تدريجيًا نحو الإنفاذ (enforcement)، وافحصها باستخدام DMARC Checker (أداة فحص DMARC).

يحمي DKIM نطاقك في صناديق بريد الآخرين. أما البريد الذي يصل إلى صندوق بريدك، فإن فلترًا للبريد الوارد مثل iBlockSpam يفحص مصادقة كل مرسل إلى جانب مؤشرات البريد العشوائي والتصيّد الاحتيالي؛ راجع كيف يعمل.

وإذا كانت التطبيقات أو الأجهزة ترسل البريد عبر iBlockSpam، فإن خدمة ترحيل البريد الصادر (outbound relay) توقّع تلك الرسائل بـ DKIM، وتشمل 500 رسالة ترحيل صادر لكل نطاق شهريًا.

تصفّح أدلتنا الأخرى عن SPF وDKIM وDMARC.