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

SPF: أي الخوادم مخوَّلة بالإرسال باسم هذا النطاق

إطار سياسة المرسل (Sender Policy Framework أو SPF) سجل نصي (TXT) في DNS يُدرِج الخوادم المخوَّلة بإرسال بريد إلكتروني باسم نطاق معيّن، مُحدَّدة كمجموعة عناوين IP أو إشارات تضمين لسجل SPF خاص بمزوّد آخر. حين يستلم خادم رسالة تدّعي الانتماء لنطاق معيّن، يتحقق من عنوان IP الخادم المرسِل مقابل سجل SPF المنشور لذلك النطاق. إن لم يكن عنوان IP المرسِل في القائمة، تفشل الرسالة في اختبار SPF — وهذا لا يعني رفضها تلقائيًا، لكنه إشارة قوية تُستخدَم في قرارات تصفية البريد العشوائي. يتحقق SPF من هوية الخادم المرسِل فقط؛ لا يقول شيئًا عن تعديل محتوى الرسالة أثناء النقل، وهذا ما تغطيه DKIM.

DKIM: إثبات أن الرسالة لم تُعدَّل أثناء النقل

يرفق معيار DomainKeys Identified Mail (DKIM) توقيعًا تشفيريًا بالرسائل الصادرة، يُولَّد باستخدام مفتاح خاص يملكه نظام البريد المرسِل، مع نشر المفتاح العام المقابل في سجل TXT في DNS للنطاق المرسِل. يستطيع الخادم المستقبِل استخدام ذلك المفتاح العام المنشور للتحقق من توقيع رسالة واردة — إن تحقق التوقيع بنجاح، فمحتوى الرسالة الأساسي جاء فعليًا من نظام يملك المفتاح الخاص المطابق ولم يُعدَّل بعد التوقيع. تتحقق DKIM من السلامة والمصدر على مستوى الرسالة نفسها، بغض النظر عن الخادم الذي نقلها، وهذا ضمان مختلف جوهريًا عن تحقق SPF على مستوى الخادم.

DMARC: السياسة التي تربط الاثنتين معًا

معيار المصادقة والإبلاغ والتوافق المعتمد على النطاق (DMARC) سجل TXT أيضًا في DNS، ويفعل شيئين لا تفعلهما SPF وDKIM وحدهما: يحدد ماذا يجب أن يفعل الخادم المستقبِل فعليًا برسالة تفشل المصادقة (عزلها، رفضها صراحة، أو عدم اتخاذ أي إجراء سوى المراقبة)، ويتطلب "المحاذاة" — التحقق من أن النطاق الظاهر في حقل "من" يطابق فعليًا النطاق الذي نجح في SPF أو DKIM، لا أي نطاق نجح مصادفة. يمكن لرسالة أن تنجح تقنيًا في SPF باستخدام نطاق معيّن بينما تعرض نطاقًا مختلفًا تمامًا في حقل "من" الذي يراه المستلم؛ محاذاة DMARC هي تحديدًا ما يغلق تلك الثغرة. تأتي المحاذاة بنمطين — صارم، يتطلب تطابقًا دقيقًا بين ترويسة "من" والنطاق الناجح في SPF أو DKIM، ومرن، يسمح بتطابق على مستوى النطاق التنظيمي (بحيث تظل رسالة من نطاق فرعي متوافقة مع مصادقة النطاق الأصل). تبدأ معظم عمليات نشر DMARC بالمحاذاة المرنة، لأنها تستوعب تباينات النطاقات الفرعية المشروعة دون الحاجة لمصادقة كل نطاق فرعي مرسِل على حدة بدقة. تتيح DMARC أيضًا تقارير مجمَّعة، بحيث يستطيع مالك النطاق رؤية، إجمالاً، أي الخوادم ترسل بريدًا باسم نطاقه وهل تلك الرسائل تنجح أم تفشل المصادقة — مفيد لملاحظة استخدام غير مخوَّل لنطاق في رسائل منتحَلة.

كيف تبدو هذه السجلات فعليًا

تُنشَر الثلاثة كسجلات TXT في DNS، ما يجعل إيجادها وقراءتها سهلاً بمجرد معرفة الشكل المطلوب البحث عنه. يبدو سجل SPF نموذجي كالتالي: v=spf1 ip4:203.0.113.10 include:_spf.example-provider.com ~all — يبدأ بإعلان إصدار SPF، ويُدرِج المصادر المخوَّلة (عنوان IP محدَّد، أو إشارة include لسجل SPF خاص بمزوّد خارجي، شائعة عند استخدام منصة بريد أو تسويق خارجية)، وينتهي بمؤهِّل (~all يُعلِّم المصادر غير المدرَجة كفشل لين، بينما -all يُعلِّمها كفشل صارم — إعداد أكثر تشددًا). يُنشَر سجل DKIM تحت نطاق فرعي خاص بمحدِّد (selector)، على شاكلة selector1._domainkey.example.com، ويحتوي المفتاح العام نفسه، وهذا سبب تضمُّن إعداد DKIM دائمًا اسم محدِّد يوفره النظام القائم بالتوقيع. يقع سجل DMARC عند _dmarc.example.com ويبدو كالتالي: v=DMARC1; p=quarantine; rua=mailto:reports@example.com — وسم p هو السياسة (none أو quarantine أو reject)، ووسم rua يحدد وجهة إرسال التقارير المجمَّعة. لا حاجة لحفظ أيٍّ من هذا لاستخدامه بشكل صحيح، لكن التعرّف على الشكل يتيح فحص سجلات نطاق معيّن فعليًا بدلاً من الثقة بملخص نجاح/فشل من أداة ما.

كيف تعمل الثلاث معًا

لا تملك سياسة DMARC ما تُقيِّمه إلا لأن SPF وDKIM أجريا تحققهما بالفعل — تنجح DMARC في رسالة إن نجحت في SPF أو DKIM (الأفضل كلاهما) ونجح فحص محاذاة النطاق، وسجل سياسة DMARC هو ما يحدد ما يحدث لرسالة تفشل ذلك التقييم. نشر سجل DMARC دون وجود سجلات SPF أو DKIM فعلية للنطاق لا يوفر حماية، لأن لا شيء تحاذيه DMARC؛ الحصول على حماية فعلية من الثلاثة يتطلب ضبط ونجاح SPF وDKIM أولاً، مع طبقة DMARC فوقهما تحدد التطبيق.

مثال عملي: تغيير مزوّد البريد الإلكتروني

ينتقل نشاط تجاري من مزوّد بريد إلكتروني إلى آخر، وينقل صناديق البريد خلال عطلة نهاية الأسبوع. صباح الاثنين، يبدأ البريد الصادر بالوصول لمجلد العشوائي لدى المستلمين أو يرتد تمامًا — عرض كلاسيكي لسجل SPF لا يزال يُدرِج خوادم المزوّد القديم فقط، دون تضمين خوادم المزوّد الجديد. الخوادم الجديدة ليست في القائمة المخوَّلة، فتفشل الرسائل المرسَلة عبرها في SPF، وحسب سياسة DMARC للنطاق قد يعني ذلك الفشل رفضًا صريحًا لا مجرد هبوط في مجلد العشوائي. الحل تحديث سجل SPF النصي ليشمل خوادم المزوّد الجديد (عادة عبر آلية "include" يوثقها المزوّد الجديد) وضبط توقيع DKIM بمفاتيح المزوّد الجديد، ويُفضَّل إنجاز ذلك والتحقق منه قبل نقل صناديق البريد نفسها، لا اكتشافه بعد أول رسالة ارتداد.

قائمة تحقق من ضبط الثلاثة

  • سجل SPF موجود ويُدرِج كل مصدر إرسال حالي — بما في ذلك أي خدمة خارجية ترسل باسم النطاق (نظام إدارة علاقات العملاء، خدمة بريد معاملات، منصة تسويق)، لا مزوّد صندوق البريد الأساسي فقط.
  • DKIM مضبوط ويوقِّع البريد الصادر فعليًا — نشر سجل DKIM في DNS نصف المهمة فقط؛ يجب أن يوقِّع النظام المرسِل فعليًا بالمفتاح الخاص المطابق أيضًا.
  • سجل DMARC منشور، مع تأكيد نجاح المحاذاة — لا مجرد وجوده، بل نجاحه فعليًا في تقييم البريد الصادر الشرعي، وهو ما يظهر في تقارير DMARC المجمَّعة.
  • سياسة DMARC تطابق تحمّل النشاط للمخاطرة — البدء بسياسة مراقبة فقط قبل الانتقال لعزل أو رفض يتجنب حجب بريد شرعي عن غير قصد أثناء الإعداد.
  • كل مرسِل خارجي شرعي مُحتسَب — نظام إدارة علاقات عملاء، أداة دعم فني، منصة تسويق، نظام فوترة — كل واحد يرسل باسم النطاق يحتاج إدراجًا في SPF، ويُفضَّل ضبطه للتوقيع بـDKIM، وإلا فإن بريده معرَّض لفشل المصادقة رغم كونه شرعيًا تمامًا.

نقل سياسة DMARC من المراقبة إلى التطبيق الفعلي يستحق القيام به تدريجيًا لا دفعة واحدة: بضعة أسابيع عند p=none تجمع تقارير تكشف أي مصدر إرسال شرعي لم يُوثَّق بعد بشكل صحيح، قبل الانتقال إلى p=quarantine ثم p=reject في النهاية، وإلا خاطر ذلك المصدر بحجب بريده تمامًا.

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