شرح SPF وDKIM وDMARC: كيف تمنع المهاجمين من انتحال نطاقك

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

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

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

SPF: من المسموح له بالإرسال

إطار سياسة المرسل (SPF) سجل TXT في DNS يسرد الخوادم المسموح لها بإرسال البريد باسم نطاقك. يبحث الخادم المستقبِل عن السجل ويتحقق هل الخادم المتصل مدرج فيه.

example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.example-crm.com -all"

بعض التفاصيل مهمة:

• النهاية. -all تطلب من المستقبِلين رفض أي شيء غير مدرج. و~all صيغة أخف تعني "مرفوض على الأرجح". ابدأ بـ ~all أثناء اكتشاف المرسلين، ثم شدّدها.
• حد الاستعلامات العشرة. يسمح SPF بعشرة استعلامات DNS كحد أقصى عند تقييمه. وكل include يُحتسب، والمتداخل منها يُحتسب أيضاً. تجاوز الحد يُفشل السجل للجميع، وهي طريقة شائعة لتعطيل بريدك بنفسك.
• ما الذي يتحقق منه SPF. يتحقق SPF من مرسل الغلاف، أي عنوان الإرجاع المخفي، لا عنوان "من" الذي يراه المستخدمون. فهو وحده لا يمنع تزوير سطر "من" الظاهر. وهذه هي الفجوة التي يسدها DMARC.

DKIM: دليل على أن الرسالة لم تُعدَّل

يضيف DKIM توقيعاً تشفيرياً إلى كل رسالة صادرة. توقّع منصة البريد بمفتاح خاص، وتنشر أنت المفتاح العام المقابل في DNS تحت اسم محدِّد. يجلب المستقبِل المفتاح ويتحقق من التوقيع، فيثبت أن الرسالة أرسلها من يملك مفتاحك وأنها لم تُعدَّل في الطريق.

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

استخدم مفاتيح بطول ٢٠٤٨ بت حيث تدعمها منصتك، وجدّد المفاتيح دورياً. ويجب أن توقّع كل خدمة ترسل باسمك، بما فيها منصة التسويق ونظام التذاكر وأدوات الموارد البشرية، بنطاقك لا بنطاقها. معظمها يدعم ذلك لكنه يبقى معطلاً حتى تضبطه.

DMARC: السياسة التي تربط كل شيء

يؤدي DMARC مهمتين. أولاً يشترط التوافق: يجب أن يطابق النطاق في عنوان "من" الظاهر النطاقَ الذي اجتاز SPF أو DKIM. وهذا ما يمنع المهاجمين أخيراً من انتحال العنوان الذي يقرؤه الناس فعلاً. ثانياً يخبر المستقبِلين بما يفعلونه بالرسائل التي تفشل، ويطلب منهم إرسال تقارير إليك.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

الوسم p هو السياسة. none تعني المراقبة فقط، وquarantine ترسل الرسائل الفاشلة إلى البريد العشوائي، وreject تحظرها كلياً. وحدها reject تحمي نطاقك بالكامل. وسجل DMARC العالق عند p=none لسنوات يعطيك تقارير بلا حماية، وهو من أكثر الملاحظات شيوعاً في تقييماتنا.

خطة تطبيق لا تعطّل البريد

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

1. اجرد كل مرسل. اسرد كل منصة ترسل البريد باسم نطاقك: خدمة البريد الرئيسية، ونظام إدارة العملاء، وأداة التسويق، ومكتب الدعم، والرواتب، والنظام المالي، ونماذج الموقع، وأي تطبيقات داخلية. اسأل كل إدارة، فدائماً هناك من يعرف عن نظام إضافي.
2. انشر SPF وفعّل DKIM لكل مرسل مشروع. وأبقِ SPF ضمن حد الاستعلامات بإزالة الخدمات التي لم تعد تستخدمها.
3. انشر DMARC بسياسة p=none مع عنوان يستقبل التقارير المجمّعة. واستخدم أداة لتقارير DMARC لقراءتها، فملفات XML الخام ليست مصممة للبشر.
4. راقب لمدة أسبوعين إلى أربعة. تُظهر التقارير كل مصدر يرسل باسم نطاقك وهل يجتاز التحقق. أصلح المشروع منها الذي يفشل. وما يتبقى إما نظام منسي أو شخص ينتحل نطاقك.
5. انتقل إلى p=quarantine، ويمكنك استخدام الوسم pct لتطبيقها على نسبة من البريد أولاً. واستمر في قراءة التقارير.
6. انتقل إلى p=reject. عندها يُفترض أن تحظر كبرى منصات البريد أي رسالة مزورة تستخدم نطاقك بالضبط.

النطاقات التي لا تستخدمها للبريد

النطاقات المحجوزة وغير المستخدمة أهداف سهلة، لأن لا أحد يراقبها. أغلقها بسجل SPF لا يسمح بأي مرسل وسياسة رفض في DMARC:

parked-example.com.          TXT  "v=spf1 -all"
_dmarc.parked-example.com.   TXT  "v=DMARC1; p=reject;"

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

لماذا لم يعد الأمر اختيارياً

منذ ٢٠٢٤ تشترط Google وYahoo على المرسلين بكميات كبيرة المصادقة عبر SPF وDKIM ونشر سجل DMARC، واتجهت منصات بريد أخرى في الاتجاه نفسه. فإن كانت مؤسستك ترسل نشرات أو كشوفات أو إشعارات بكميات كبيرة، فإن ضعف المصادقة يؤثر الآن في وصول الرسائل بقدر ما يؤثر في الأمن.

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

ما لن تفعله هذه السجلات

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

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