مقدمة

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

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

فهم دور DNS في مصادقة البريد الإلكتروني

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

تُنشر سجلات SPF وDMARC عادة على هيئة سجلات TXT. أما DKIM فيمكن نشر مفتاحه العام في سجل TXT أو، في بعض المنصات السحابية مثل Microsoft 365، عبر سجلات CNAME تشير إلى مفاتيح تديرها المنصة. المهم هو اتباع القيم التي تولدها منصة الإرسال نفسها، لأن أي اختلاف ولو بسيط في اسم المضيف أو المفتاح سيؤدي إلى فشل التحقق.

قبل البدء، ينبغي إعداد جرد كامل لجميع الجهات التي ترسل البريد باسم النطاق، مثل Microsoft 365 أو Google Workspace، وخادم الموقع، ومنصة التسويق، ونظام الفوترة، وأدوات الدعم الفني، وخدمات التنبيهات. كثير من حالات فشل SPF وDMARC لا تنشأ عن خطأ في الصياغة، بل عن نسيان خدمة إرسال شرعية تعمل باسم النطاق.

ومن الممارسات المهمة تقليل قيمة مدة التخزين المؤقت TTL مؤقتاً إلى 300 أو 600 ثانية أثناء مرحلة الاختبار، ثم رفعها لاحقاً إلى قيمة أكثر ملاءمة مثل 3600 ثانية بعد استقرار الإعدادات. كما يجب التأكد من تعديل منطقة DNS الفعلية التي تستخدمها خوادم الأسماء المعتمدة للنطاق، لا لوحة تحكم قديمة أو غير نشطة.

إعداد سجل SPF وتحديد مصادر الإرسال المصرح بها

إطار نهج المرسل SPF هو سجل يحدد عناوين IP والخدمات التي يحق لها إرسال البريد باستخدام نطاق المؤسسة في عنوان ظرف الإرسال، المعروف تقنياً باسم MAIL FROM أو Return-Path. عند استقبال رسالة، يقارن الخادم عنوان IP للخادم المرسل بما هو مسموح به في سجل SPF.

يبدأ سجل SPF دائماً تقريباً بالقيمة v=spf1، ثم تضاف الآليات التي تصف مصادر الإرسال. على سبيل المثال، إذا كانت المؤسسة تستخدم Microsoft 365 فقط لإرسال البريد، فقد يكون السجل على النحو الآتي:

v=spf1 include:spf.protection.outlook.com -all

تشير الآلية include إلى أن البنية التحتية لخدمة Microsoft 365 مسموح لها بالإرسال. وتعني النهاية -all أن أي مصدر غير مذكور يجب أن يفشل بشكل صريح. لكن لا ينبغي استخدام -all قبل حصر جميع الخدمات الشرعية؛ لأن ذلك قد يسبب رفض رسائل سليمة. خلال مرحلة الجرد يمكن استخدام ~all، الذي يعبر عن فشل مرن، ثم الانتقال إلى الفشل الصريح بعد التحقق.

إذا كانت المؤسسة تستخدم خدمة رسائل تسويقية وخادماً داخلياً بالإضافة إلى Microsoft 365، فيمكن دمج المصادر في سجل واحد فقط:

v=spf1 include:spf.protection.outlook.com include:spf.mailprovider.example ip4:203.0.113.25 -all

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

ولا يحمي SPF وحده عنوان From الذي يراه المستخدم دائماً؛ فقد يستطيع المهاجم استخدام عنوان ظرف مختلفاً مع إظهار نطاق المؤسسة في عنوان المرسل. وهنا تظهر أهمية محاذاة النطاق التي يفرضها DMARC، وأهمية توقيع DKIM.

تفعيل DKIM ونشر المفتاح العام بأمان

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

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

selector1._domainkey.example.com

وقد يبدو سجل TXT الخاص بمفتاح DKIM على النحو التالي، مع استبدال القيمة بمفتاح عام حقيقي طويل توفره منصة الإرسال:

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

في Microsoft 365، غالباً ما تطلب المنصة إضافة سجلين من نوع CNAME لمحددين مثل selector1 وselector2، ثم تفعيل DKIM من مركز إدارة Microsoft 365 أو Microsoft Defender بعد انتشار سجلات DNS. يجب نسخ أسماء السجلات ووجهاتها كما تعرضها المنصة تحديداً، لأن الوجهة تختلف حسب اسم النطاق المستأجر وإعدادات المستأجر.

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

تزداد فائدة DKIM عندما تمر الرسائل عبر قوائم بريدية أو بوابات تضيف ترويسات؛ إذ يمكن أن يبقى التوقيع صالحاً ما دامت الأجزاء الموقعة من الرسالة لم تتغير. ولهذا يعد DKIM مكملاً مهماً لـ SPF، لا بديلاً عنه.

بناء سياسة DMARC وربط نتائج المصادقة بالنطاق

مصادقة الرسائل المستندة إلى المجال وإعداد التقارير والتوافق، أو DMARC، هي الطبقة التي تحدد كيفية استخدام نتائج SPF وDKIM. وهي لا تكتفي بسؤال: هل نجح التحقق؟ بل تسأل أيضاً: هل النطاق الذي نجح في SPF أو DKIM متوافق مع النطاق الظاهر في عنوان From؟ تسمى هذه العلاقة المحاذاة، وهي ما يمنع كثيراً من أساليب الانتحال التي تتجاوز SPF منفرداً.

ينشر سجل DMARC في المضيف التالي:

_dmarc.example.com TXT

وتبدأ أفضل عملية نشر بسياسة مراقبة لا تؤثر في تسليم الرسائل، كما في المثال التالي:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100

تعني p=none جمع التقارير من دون طلب رفض أو حجر الرسائل. ويحدد الوسم rua عنوان استقبال التقارير التجميعية، وهي ملفات دورية بصيغة XML توضح مصادر الإرسال ونتائج SPF وDKIM وDMARC. أما adkim=s وaspf=s فيفرضان محاذاة صارمة؛ أي يجب أن يتطابق النطاق تماماً، وليس مجرد نطاق فرعي متصل به.

بعد تحليل التقارير ومعالجة مصادر الإرسال غير المعروفة، يمكن الانتقال تدريجياً إلى الحجر:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25

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

خطة عملية للنشر التدريجي في بيئة مؤسسة

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

في المرحلة الثانية، يُنشر سجل SPF موحد بعد مراجعة عدد استعلامات DNS الناتجة عنه. ثم تُفعل مفاتيح DKIM في كل منصة إرسال، مع إرسال رسائل اختبار إلى صناديق بريد خارجية وفحص ترويساتها. يجب ألا تقتصر الاختبارات على Gmail أو Outlook وحدهما؛ فمن المفيد اختبار أكثر من مزود استقبال لأن معالجة الرسائل قد تختلف.

في المرحلة الثالثة، ينشر DMARC بسياسة p=none مدة كافية، غالباً عدة أسابيع أو دورة أعمال كاملة على الأقل، حتى تظهر الرسائل الدورية مثل الفواتير والتقارير الموسمية والتنبيهات الآلية. تحلل المؤسسة تقارير rua لتصنيف كل عنوان IP أو خدمة إلى مصدر شرعي أو غير مصرح به. لا ينبغي إدراج مصدر في SPF لمجرد ظهوره في التقرير؛ بل يجب التحقق من ملكيته ووظيفته أولاً.

بعد معالجة الاستثناءات، تنتقل السياسة إلى quarantine بنسبة منخفضة، ثم ترتفع النسبة تدريجياً. وعند استقرار النتائج، تعتمد المؤسسة reject. وينبغي توثيق ملكية سجلات DNS، ومفاتيح DKIM، وصندوق تقارير DMARC، وإجراءات طلب إضافة مزود جديد، كي لا يؤدي اعتماد أداة تسويقية جديدة إلى كسر المصادقة مستقبلاً.

التحقق من السجلات واستكشاف الأخطاء الشائعة

بعد نشر السجلات، يجب التحقق منها من جانب DNS ومن جانب الرسالة الفعلية. يمكن استعمال أدوات مثل MXToolbox لفحص بنية سجلات SPF وDKIM وDMARC، كما تساعد Google Postmaster Tools في متابعة السمعة ومؤشرات التسليم للنطاقات التي ترسل حجماً مناسباً من الرسائل إلى Gmail. وتوفر منصات البريد، ومنها Microsoft 365، أدوات ورسائل حالة لتأكيد تفعيل توقيع DKIM.

على مستوى الرسالة، يمكن إرسال بريد اختبار إلى صندوق خارجي ثم فحص الرؤوس بحثاً عن نتيجة مثل:

Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

إذا ظهر فشل SPF، فينبغي مراجعة عنوان IP الحقيقي لخادم الإرسال، وسجل SPF الواحد، وحد العشرة استعلامات، ووجود خدمة وسيطة تعيد توجيه البريد. وإذا فشل DKIM، يجب التحقق من المحدد المذكور في ترويسة DKIM-Signature، ومطابقته لاسم سجل DNS، وصحة المفتاح وعدم وجود اقتباسات أو أسطر مكسورة بشكل غير صحيح في لوحة DNS.

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

خاتمة

تأمين البريد الإلكتروني ليس سجلاً واحداً يضاف إلى DNS ثم يُنسى، بل عملية مستمرة تجمع بين ضبط SPF بدقة، وتفعيل DKIM وتدوير مفاتيحه، وبناء سياسة DMARC متدرجة تستند إلى تقارير حقيقية. يوفر SPF تعريفاً بمصادر الإرسال، ويثبت DKIM سلامة الرسالة ونطاق توقيعها، بينما يمنح DMARC المؤسسة القدرة على مراقبة الانتحال ثم حظره بثقة.

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