الرئيسية›الأدلة›أمن البريد الإلكتروني

أمن البريد الإلكتروني · الفهم

SPF وDKIM وDMARC: ممّ تحمي، وممّ لا تحمي

يحدد SPF الخوادم التي يحق لها الإرسال باسم نطاق ما، ويوقّع DKIM الرسالة، ويتحقق DMARC من أن أحدهما يطابق النطاق المعروض في حقل «من» ويحدد ما يجب فعله عند الفشل. ومعًا تمنع هذه الآليات أي طرف مجهول من استخدام نطاقكم بعينه. لكنها لا تقرأ النص: فالنطاق القريب، أو اسم العرض المضلّل، أو الحساب المخترق، كلها تمر.

آخر تحديث في أكتوبر 20266 دالمصادر الرسمية المعتمدة

SPF: من يحق له الإرسال

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

توضيحان يغيّران كل شيء:

  • يتحقق SPF من عنوان المغلّف (عنوان الحوار بين الخوادم، المعروف بـ «MAIL FROM») ومن الاسم الذي يعلنه الخادم، لا من العنوان الذي يقرؤه المستلم في حقل «من».
  • يحكم SPF على آخر خادم سلّم الرسالة. فحين يُعاد توجيه رسالة عبر خادم آخر، لا يعود الخادم الذي يسلّمها مصرّحًا له من النطاق الأصلي: فقد يفشل التحقق رغم أن الرسالة مشروعة.

لا ينشر النطاق سوى سجل SPF واحد. وترد فيه كل مصادر الإرسال: نظام البريد، وبرنامج الفوترة، وأداة النشرات الإخبارية، ونظام CRM، وآلة النسخ التي ترسل المسح الضوئي بالبريد.

DKIM: الرسالة موقّعة

بحسب RFC 6376، يتيح DKIM لمالك النطاق الموقّع أن يتحمّل جزءًا من المسؤولية عن رسالة، بواسطة توقيع تشفيري. المفتاح العام موجود في DNS. والتحقق من التوقيع يثبت أن الأجزاء الموقّعة لم تتغيّر منذ التوقيع.

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

ما لا يفعله DKIM، بحسب RFC نفسها: فهو لا يشفّر الرسالة، والفشل لا يفرض رفضها، ولا يلزم أن يكون النطاق الموقّع هو النطاق المعروض في حقل «من». وهذه بالضبط الثغرة التي يسدّها DMARC.

DMARC: المطابقة والسياسة

تعرّف RFC 7489 بروتوكول DMARC بأنه وسيلة تتيح لمالك النطاق التعبير عن سياسة على مستوى النطاق. وتقوم الآلية على المطابقة: يجب أن يطابق نطاقُ العنوان المعروض في حقل «من» النطاقَ الذي تحقّق منه SPF أو DKIM. وإذا لم يكن أيٌّ منهما مطابقًا، يفشل DMARC.

ينشر النطاق حينئذ ما يريده:

  • none: لا يُطلب أي إجراء، نكتفي بالمراقبة؛
  • quarantine: معاملة الرسالة على أنها مشبوهة؛
  • reject: رفض الرسالة.

وينص DMARC أيضًا على تقارير: تقارير مجمّعة تلخّص الخوادم التي أرسلت باسم النطاق وبأي نتيجة، وتقارير فشل رسالةً برسالة. وهي التي تتيح اكتشاف أداة منسيّة ترسل باسمكم، أو شخص ينتحل نطاقكم.

الآليةما تتحقق منهما لا تنظر إليه
SPFأن الخادم الذي يسلّم الرسالة مصرّح له لنطاق المغلّفالعنوان المعروض، المحتوى
DKIMأن الرسالة الموقّعة لم تُعدَّل؛ وأن نطاقًا يتحمّل مسؤوليتهاالعنوان المعروض، نزاهة المحتوى
DMARCأن النطاق المعروض مطابق لـ SPF أو DKIM؛ والسياسة عند الفشلالنطاقات المشابهة، اسم العرض، النص

هل يحجب DMARC التصيّد؟

إنه يحجب جزءًا من انتحال النطاق، لا التصيّد عمومًا. وتقول RFC 7489 ذلك صراحة: لا يعالج DMARC أسماء النطاقات المتشابهة بصريًا، ولا إساءة استخدام اسم العرض، وتحليل المحتوى خارج نطاقه. فهو لا يسعى إلى حل كل مشكلات البريد الاحتيالي.

وعمليًا، لا يرى DMARC:

  • النطاق القريب: يصادق المحتال على نطاقه الخاص بشكل مثالي، وهو نطاق يشبه نطاقكم؛
  • اسم العرض المنتحَل: «قسم المحاسبة» مكتوب من عنوان لا صلة له به؛
  • الحساب المخترق الذي يوقّع بشكل سليم، لأن الخادم الحقيقي هو الذي يرسل؛
  • الرسالة التي لا صلة لها بنطاقكم: تنبيه مزيف من شركة شحن يصل من نطاق لا علاقة له بنطاقكم؛
  • النطاق الخالي من السياسة: إذا كان النطاق المقلَّد ينشر «none»، فلا تصل المستلمَ أي تعليمة بالرفض.

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

إعادة التوجيه وقوائم التوزيع: ARC

كثيرًا ما تكسر إعادة التوجيه SPF، وتكسر القائمة التي تعدّل الرسالة DKIM، فيفشل DMARC حينئذ في رسالة مشروعة. يتيح ARC، الموصوف في RFC 8617 (وضع تجريبي)، لكل وسيط أن يشهد بنتيجة التحقق التي لاحظها. ويمكن للخادم النهائي أن يختار أخذها بعين الاعتبار.

حماية نطاقكم وتصفية الوارد

هذان موضوعان كثيرًا ما يُخلط بينهما.

  • حماية النطاق المرسِل: نشر SPF وDKIM وDMARC لنطاقكم، حتى يتمكن الآخرون من رفض الرسائل التي تنتحله. أنتم من ينشر؛ والمستلمون من يطبّق.
  • تصفية الوارد: التحقق من سجلات النطاقات الأخرى في البريد الذي تتلقونه، ثم تطبيق كل التحليلات الأخرى.

التطبيق التدريجي

  1. جرد كل ما يرسل باسم النطاق.
  2. سجل SPF واحد يصرّح لها؛ وتوقيع DKIM لكل خدمة قادرة على التوقيع.
  3. DMARC على «none»، مع عنوان لاستقبال التقارير.
  4. قراءة التقارير طوال عدة أسابيع؛ وتصحيح المصادر المنسيّة.
  5. الانتقال إلى «quarantine»، ثم إلى «reject» حين تصبح كل الإرسالات المشروعة مطابقة.

مثال للتوضيح. ينشر مكتب سياسة DMARC على «none» ويقرأ تقاريره الأولى. فيكتشف ثلاثة مصادر: نظام بريده، المطابق جيدًا؛ وبرنامج الفوترة، الذي يرسل الفواتير بنطاق المكتب دون توقيع DKIM؛ وخادمًا مجهولًا في الخارج يرسل مئات الرسائل باسمه. يصحّح برنامج الفوترة، وينتظر دورة تقارير سليمة، ثم ينتقل إلى «quarantine»: فيصبح المستلمون الذين يطبّقون DMARC يعاملون رسائل الخادم المجهول على أنها مشبوهة.

يوم تغيير نظام البريد، تُحضَّر هذه السجلات قبل تغيير MX. ويصف دليل ترحيل نظام البريد دون انقطاع هذه اللحظة؛ ولا نعيدها هنا.

أسئلة شائعة

هل تحمي سياسة DMARC على «none»؟

لا. فهي تتيح المراقبة بفضل التقارير. وتبدأ الحماية مع «quarantine» أو «reject».

لماذا تفشل رسالة مشروعة في اختبار DMARC؟

في أغلب الأحيان: إعادة توجيه، أو قائمة توزيع، أو خدمة ترسل باسمكم دون أن تكون مصرّحًا بها في SPF ودون أن توقّع بـ DKIM.

نظام بريدنا لا يوقّع بـ DKIM: ما العمل؟

يمكن لبوابة موضوعة على مسار الإرسال أن توقّع بدلًا منه. راجعوا حماية نظام البريد الذي تملكونه أصلًا.

أين تُقرأ نتيجة هذه الفحوص في رسالة واردة؟

في ترويسات الرسالة. بالنسبة إلى Klytic MTA، راجعوا قراءة قرار المرشّح وتصديره.

موقع Klytic

تعالج Klytic MTA الموضوعين، أمام أي نظام بريد:

  • الأساسية والمتقدمة: فحص SPF وDKIM وMX؛ التحقق من DMARC، بما في ذلك للرسائل المُعاد توجيهها بفضل ARC؛ توقيع DKIM للرسائل المرسلة، حتى لو لم يفعل ذلك نظام بريدكم.
  • المتقدمة: لوحة DMARC، مع تقارير نطاقاتكم، وتنبيهات، ومقترحات للتصحيح، لقيادة الانتقال التدريجي نحو «reject».

DMARC ليس سوى طبقة واحدة: تضيف Klytic MTA رصد النطاقات المشابهة واسم العرض وسيناريوهات الاحتيال، الموصوف في انتحال الصفة والاحتيال باسم الرئيس.

إذا كنتم تستخدمون Klytic Mail، فإن SPF وDKIM وDMARC مضبوطة لنطاقكم: وهذه هي حماية النطاق المرسِل. أما Klytic MTA فيُشترك فيها مع Klytic Mail أو بدونه.

المصادر

اطُّلع عليها في أكتوبر 2026.

  • RFC 7208، SPF: ينشر مالك النطاق المضيفات المصرّح لها باستخدام نطاقه في هوية «MAIL FROM» أو «HELO»، ويتحقق المستقبِل من هذا التصريح. rfc-editor.org
  • RFC 6376، DKIM: يتحمّل نطاقٌ مسؤوليةَ رسالة بتوقيع تشفيري؛ لا تشفير، ولا رفض مفروض، ويمكن أن يختلف النطاق الموقّع عن المؤلف المعروض. rfc-editor.org
  • RFC 7489، DMARC: مطابقة نطاق «From» مع SPF أو DKIM، والسياسات none وquarantine وreject، والتقارير المجمّعة وتقارير الفشل؛ والنطاقات المتشابهة بصريًا واسم العرض وتحليل المحتوى خارج النطاق. rfc-editor.org
  • RFC 9989 (مايو 2026)، التي تحل محل RFC 7489: قيم السياسة نفسها والاستثناءات نفسها (النطاقات المشابهة، اسم العرض). rfc-editor.org
  • RFC 8617، ARC (تجريبي): سلسلة نقل موثّقة؛ يمكن لمستقبِل DMARC قبول التقييمات التي تحملها سلسلة ARC صالحة. rfc-editor.org
  • Klytic، صفحة Klytic MTA: فحوص التحقق من الهوية، وتوقيع DKIM للبريد الصادر، ولوحة DMARC في عرضي «الأساسية» و«المتقدمة»، والخيارات الإضافية، وأنماط النشر، وبدء الخدمة عبر سجل MX. klytic.com

التحقق والتوقيع، أمام نظام بريدكم

تتحقق Klytic MTA من SPF وDKIM وDMARC عند الوصول وتوقّع رسائلكم المرسلة.

التحدث مع مستشار →

اكتشاف Klytic MTA

عرض الترحيب

30 يومًا من التجربة المجانية، مع ترحيل بمرافقتنا

عرض تجريبي دون التزام. سيتصل بك مستشار لفهم احتياجاتك وتجهيز مساحة Klytic الخاصة بك.