حين تصل رسالة مزيفة باسم شركتك إلى عميل، لا يكون السؤال الأول عن تصميم الرسالة، بل عن قدرة النطاق على إثبات من يحق له الإرسال. مصادقة البريد ليست زر حماية واحداً. SPF يصف مصادر الإرسال، وDKIM يضع توقيعاً يمكن التحقق منه، وDMARC يحدد كيف تتعامل الجهة المستقبلة مع فشل المصادقة وكيف ترسل تقاريرها. تعمل هذه الآليات مع DNS، ولذلك فإن خطأ صغيراً في سجل TXT قد يؤثر في الفواتير والتنبيهات والرسائل التسويقية معاً. ابدأ بجرد واقعي للمرسلين، ثم طبق السياسة تدريجياً وبقياس واضح.
المصطلحات الإنجليزية شائعة في فرق التقنية العربية، لكن فهم العلاقة بينها أهم من حفظ الاختصارات. SPF يجيب عن سؤال: هل عنوان الإرسال هذا موجود في قائمة المصادر المسموح بها؟ DKIM يجيب: هل الرسالة تحمل توقيعاً صحيحاً لم يتغير محتواها المهم؟ DMARC يضيف سؤالاً ثالثاً: هل النطاق الذي يراه المستلم متوافق مع نطاق SPF أو DKIM، وماذا نفعل إذا لم يكن؟ وفق RFC 7208 وRFC 6376 وRFC 7489، لكل آلية نطاق وحقل وسلوك مختلف. لا تجعل نجاح واحدة منها دليلاً على نجاح البقية.
جرد المرسلين قبل لمس DNS
اكتب قائمة بالمصادر التي ترسل باسم الشركة: صندوق الموظف، نظام الدعم، منصة التسويق، الفواتير، رسائل تسجيل الدخول، نظام الموارد البشرية، تنبيهات المراقبة، وأي تطبيق داخلي. سجل النطاق الظاهر في From، ونطاق Return-Path، وهل يوقع المزود بـ DKIM، ومن يملك إعداداته. لا تعتمد على ذاكرة الفريق أو قائمة قديمة في مستند. أرسل رسائل اختبارية مضبوطة، وراجع سجلات الإرسال، واسأل مالكي المنتجات عن خدمات نُسيت منذ سنوات. الهدف أن تعرف ما الذي يجب أن يمر قبل أن تختار سياسة ترفض ما عداه.
- النطاق الرئيسي ونطاقات الإرسال الفرعية، مع مالك داخلي لكل واحد.
- مزود البريد ومزود التسويق والدعم والفوترة وأي خدمة ترسل باسم العلامة.
- نطاق Return-Path ونطاق DKIM selector لكل مصدر، لا العنوان الظاهر فقط.
- حالة الرسائل الحالية: تصل، تذهب إلى الرسائل غير المرغوبة، أو تفشل المصادقة.
- هل تستخدم النطاقات الفرعية سياسة مستقلة أو ترث سياسة النطاق الأب.
SPF: سجل واحد وقائمة قابلة للصيانة
سجل SPF هو TXT يبدأ عادة بـ v=spf1 ويتبع بمحددات مثل ip4 أو include أو a أو mx ثم سياسة نهائية مثل ~all أو -all. وظيفته إعلان مصادر الإرسال التي يسمح بها صاحب النطاق، لكنه لا يوقع الرسالة ولا يثبت أن المحتوى لم يتغير. التحدي التشغيلي هو أن بعض المحددات تنفذ استعلامات DNS إضافية، وللمواصفة حد عملي مشهور لعدد الاستعلامات أثناء التقييم. كثرة منصات الإرسال قد تجعل السجل طويلاً وهشاً. أزل المصادر غير المستخدمة، وثق سبب كل include، وراجع السجل بعد كل عقد جديد.
لا تنسَ نطاقات Return-Path الخاصة بمزودي البريد. قد ينجح SPF لنطاق فرعي مختلف عن النطاق المرئي، ثم يعتمد DMARC على محاذاة النطاقين. اسأل المزود عن طريقة الإعداد الرسمية، ولا تنسخ سجلاً من مثال عام دون فهم قيمته. تجنب نشر سجلين SPF، لأن المستلم قد يعتبر النتيجة غير صالحة. استخدم مدقق SPF لقراءة البنية والاستعلامات، ثم اختبر رسالة فعلية من كل مصدر. الفحص النصي مفيد، لكنه لا يغني عن معرفة المسار الذي سلكته الرسالة.
DKIM: المفتاح العام ليس التوقيع
ينشر DKIM مفتاحاً عاماً في اسم selector._domainkey، بينما يحتفظ مزود الإرسال بالمفتاح الخاص ويوقع الرسائل. عند التحقق، يعيد المستلم قراءة المفتاح العام ويقارن التوقيع بمحتوى الرسالة. إذا تغيّر جزء موقع أو كان selector غير صحيح أو لم يعد المفتاح المنشور يطابق المزود، تفشل النتيجة. لذلك ضع جدولاً للـ selectors، والمزود المالك، وتاريخ التدوير، وخطة إزالة المفتاح القديم. وجود سجل DKIM لا يعني أن كل رسالة تستخدمه، ونجاح توقيع مزود واحد لا يغطي خدمة أخرى.
التحقق البسيط من TXT قد يكشف غياب المفتاح أو خطأ DNS، لكنه لا يثبت أن الرسالة الفعلية موقعة بشكل صحيح. استخدم فاحص DKIM لاختبار selector المعروف، واطلب من مزود البريد رسالة اختبار من نطاق الإنتاج. راجع ترويسة Authentication-Results عند الجهة المستقبلة، مع إخفاء عناوين العملاء والبيانات الحساسة. إذا غيرت المزود، لا تحذف selector القديم قبل انتهاء الرسائل المعلقة وتأكيد عدم اعتماد أي مسار عليه.
DMARC: سياسة وتوافق وتقارير
ينشر DMARC في _dmarc.example.com ويحدد p مثل none أو quarantine أو reject، مع خيارات pct وrua وadkim وaspf وsp. سياسة none مفيدة للقياس، لكنها لا تمنع الرسائل المزيفة. quarantine يطلب التعامل الحذر، وreject يطلب الرفض، لكن النتيجة الفعلية تعتمد على الجهة المستقبلة. قبل التشديد، تأكد من أن رسائل الموظفين والتطبيقات والموردين تملك SPF أو DKIM ناجحاً ومتوافقاً مع النطاق المرئي. استخدم التقارير لمعرفة المرسلين، ولا تحول نسبة pct إلى شعور زائف بالأمان.
التقارير المجمعة تكشف اتجاهات لا تراها من رسالة واحدة: مصدر جديد، فشل محاذاة، تغير في حجم الإرسال، أو خدمة تابعة تستخدم نطاقاً غير متوقع. احترم الخصوصية عند تخزينها، وحدد من يقرأها وكم تبقى. لا تفسر كل فشل على أنه هجوم، فقد يكون تغييراً مشروعاً لم يوثق. وبالعكس، لا تعتبر كل مصدر معروف آمناً إلى الأبد. اربط النتائج بتذاكر التغيير ومالك الخدمة. يوفر منشئ DMARC بداية عملية لبناء سجل واضح، لكن القرار النهائي يجب أن يستند إلى حركة شركتك الفعلية.
التدرج من المراقبة إلى الرفض
- الأسبوع الأول: اجمع المرسلين وفعّل DMARC على none مع تقرير مناسب.
- الأسبوع الثاني: صنّف النتائج إلى مصادر شرعية ومصادر مجهولة وأخطاء إعداد.
- الأسبوع الثالث: أصلح SPF وDKIM والمحاذاة، ثم اختبر الرسائل الحساسة.
- الأسبوع الرابع: استخدم pct منخفضاً أو quarantine على نطاق فرعي مراقب.
- بعد الاستقرار: ارفع التغطية تدريجياً نحو reject مع خطة رجوع ومراقبة.
التدرج مهم خصوصاً للشركات التي تبيع في أكثر من بلد أو تعتمد على موردين محليين. قد يستخدم فريق في الرياض منصة فواتير مختلفة عن فريق في دبي، وقد تظهر نطاقات فرعية للحملات أو للرسائل العربية. لا تنقل سياسة النطاق الأب إلى كل شيء قبل فهم الحاجة، ولا تستخدم نطاقاً فرعياً كطريقة لإخفاء مصدر غير موثق. حدد معيار نجاحاً مثل انخفاض الرسائل غير المتوافقة مع بقاء الرسائل الحرجة في صندوق الاستقبال، وراجع النتائج بعد كل خطوة. الأمن الجيد قابل للقياس وقابل للرجوع.
أخطاء شائعة في الشركات
من الأخطاء المتكررة إضافة include جديد من دون حساب أثره، نشر أكثر من SPF، نسيان DKIM لنظام التذاكر، استخدام rua غير مصرح به، أو تفعيل reject قبل اختبار رسائل إعادة التوجيه. يخطئ فريق آخر حين يربط DMARC بعنوان From فقط ولا يراجع Return-Path أو التوقيع. وهناك من يضع سياسة قوية ثم يحذف تقاريرها لأنها مزعجة. هذه الأخطاء لا تعالجها أداة واحدة. تحتاج إلى ملكية واضحة، وإدارة تغيير، واختبار من مصدر حقيقي، وتوثيق لكل سجل وقيمته وسبب بقائه.
إذا كان النطاق يستخدم أسماء عربية أو نطاقات دولية، اختبر محاذاة النطاق بالصيغة التي تظهر في الترويسة وبصيغة DNS. لا تخلط بين امتداد العلامة العربي والنسخة اللاتينية، ولا تفترض أن سياسة النطاق الأول تحمي الثاني. اجعل عناوين التقارير قابلة للوصول من الفريق المسؤول، واستخدم أسماء نطاقات فرعية واضحة للمراسلات الآلية. عند التعاقد مع منصة جديدة، أضف متطلبات SPF وDKIM وDMARC إلى قائمة المشتريات، واطلب طريقة إيقاف المصدر عند انتهاء العقد.
يساعدك DomScan في فحص الحالة الحالية عبر فحص أمان البريد، وفي أتمتة التحقق عبر Email Authentication API. سجل النتيجة والوقت والحالة غير المعروفة عندما لا يمكن الحسم. لا تسجل مفاتيح خاصة أو محتوى رسائل، ولا تعرض تقارير الشركات علناً. استخدم المخرجات لإسناد تذاكر إصلاح، ثم أعد الفحص بعد التغيير. إذا كان لديك نطاقات كثيرة، قسمها حسب الأهمية وطبّق السياسة على مجموعات يمكن مراقبتها بدلاً من تغيير الجميع في يوم واحد.
أفضل سياسة DMARC هي التي يستطيع فريق البريد تفسير نتائجها قبل أن يطلب من العالم رفض الرسائل.
مبدأ تشغيل مصادقة البريد
أضف اختباراً يرسل رسالة من كل خدمة حرجة قبل الانتقال إلى سياسة أشد، ثم راقب صندوق الاستقبال ونتيجة Authentication-Results. إذا فشل مصدر واحد، لا تعالج المشكلة بإضافة include عشوائي أو بتخفيف السياسة للجميع. أصلح المحاذاة أو غيّر النطاق الظاهر، وسجل القرار. هذا الاختبار الصغير يربط إعداد DNS بسلوك رسالة حقيقية ويمنح الفريق دليلاً يمكن مراجعته قبل التشديد.
اختبر الرسائل التي لا يتذكرها أحد
أكثر مصادر الفشل إزعاجاً هي الرسائل التي لا تظهر في قائمة المرسلين الرئيسية: إيصال من متجر، دعوة تقويم، رسالة استرداد كلمة مرور، إشعار مراقبة، أو رد آلي من نظام قديم. اطلب من كل مالك منتج أن يصف النطاق الظاهر والموقع الذي يوقّع الرسالة، ثم أرسل اختباراً إلى صندوق مراقب. راجع النتيجة عند مستلم مختلف، لأن بعض الجهات تطبق سياسات إضافية. إذا وجدت مصدراً بلا مالك، أوقفه أو اعزله قبل تشديد DMARC، لكن لا تحذف السجل الذي يعتمد عليه منتج حرج من دون نافذة تغيير.
ضع جدول تدوير للمفاتيح وسجلات SPF. عند انتهاء عقد منصة، أزل include أو selector القديم بعد التحقق من أن لا رسالة إنتاجية تعتمد عليه. إذا كان مزود يطلب نطاقاً فرعياً للمصادقة، افهم هل هو From أو Return-Path، وكيف تتوافق النتيجة مع DMARC. لا تنسخ سياسة شركة أخرى، لأن بنية الإرسال والبلدان والمنتجات تختلف. في الشركات العربية، قد ترسل فروع متعددة عبر مزودين مختلفين، ولذلك اجعل مالك النطاق الفرعي واضحاً. التوثيق الذي يربط السجل بالخدمة يمنع العودة إلى تخمينات كلما غاب مهندس.
قس نتائج DMARC حسب المصدر والنطاق والوقت، واحذر من قراءة عدد الرسائل كأنه عدد مستخدمين. التقارير المجمعة قد تحتوي معلومات حساسة عن حركة البريد، فاحمها وحدد مدة الاحتفاظ. راقب نسبة المحاذاة، ومصادر لم تظهر في الجرد، ورسائل فشلت بعد نشر تغيير. بعد كل تعديل، نفذ فحصاً عبر فاحص DKIM ومدقق SPF ثم اختبر رسالة حقيقية. هذه الحلقة الصغيرة تجعل السياسة قابلة للتحسن وتمنع أن تتحول none إلى وضع دائم بلا قرار.
SPF وDKIM وDMARC ليست مشروع DNS لمرة واحدة، بل دورة حياة مرتبطة بالموردين والمنتجات والهوية التجارية. ابدأ بالجرد، صحح السجلات، راقب التقارير، اختبر المحاذاة، ثم شدد السياسة تدريجياً. بهذه الطريقة تقلل انتحال النطاق من دون تعطيل فاتورة أو رسالة دعم مشروعة، وتستطيع شرح سبب كل قرار لفرق التسويق والأمن والتشغيل. للبدء، شغّل فحص أمان البريد ثم اقرأ توثيق API إذا أردت جعل الفحص جزءاً من عملية الإطلاق.