مصطلح · فحص DMARC

كيف تُجري فحص DMARC لبريد التطبيق؟

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

تعامل مع فحص DMARC على أنه أربعة اختبارات وليس استعلامًا واحدًا

للفحص المفيد أربع طبقات. الأولى: اكتشاف السياسة المنطبقة على نطاق مؤلف الرسالة. الثانية: التحقق من أن سجل TXT سياسة DMARC فعلًا بدلًا من قبول أي نص يعيده DNS. الثالثة: اختبار محاذاة المعرّفات على رسالة فعلية: يجب أن يحاذي نطاق MAIL FROM المصادَق عليه بـ SPF أو نطاق توقيع DKIM الموثَّق النطاقَ الوارد في ترويسة From الظاهرة. الرابعة: تأكيد التغطية التشغيلية بالإرسال عبر كل تطبيق ومزوّد ومنطقة وفئة رسائل مشروعة تستخدم النطاق. لا يغطي استعلام DNS الناجح إلا جزءًا من الطبقتين الأوليين. فهو لا يبيّن أن المزوّد يوقّع بالنطاق المقصود، ولا أن Return-Path المخصص فعّال، ولا أن إعادة التوجيه غيّرت سلوك SPF، ولا أن نظامًا أُغفل سيصمد أمام سياسة تطبيق صارمة.

استعلم عن اسم DNS الصحيح واتبع اكتشاف السياسة

ابدأ بالنطاق الدقيق في ترويسة RFC5322 From، وهو ما يُسمى غالبًا نطاق المؤلف. استعلم عن TXT عند _dmarc متبوعًا بذلك النطاق. فبالنسبة إلى رسالة من alerts@notify.example.test، ابدأ من _dmarc.notify.example.test لا من مضيف الموقع أو مضيف MX أو نطاق Return-Path. يحدد RFC 9989 اكتشاف السياسة بما يتجاوز استعلامًا واحدًا: إذا لم يكن لدى نطاق المؤلف سجل صالح، يمكن للجهة المستقبِلة السير في شجرة DNS للعثور على سياسة النطاق التنظيمي أو نطاق اللاحقة العامة المنطبقة. وقد تأتي معاملة النطاقات الفرعية من الوسم sp أو np أو p بحسب ما هو موجود ومكان العثور على السياسة. وهذا يعني أن أداة الفحص ينبغي أن تُبلغ عن الاسم الذي استُعلم عنه ونطاق السياسة الذي اختارته فعلًا. فالنتيجة التي تقول فقط «تم العثور على سجل» قد تخفي أخطاء في الوراثة أو سياسة صريحة للنطاق الفرعي تغيّر المعاملة المتوقعة.

تحقق من بنية السجل قبل تفسير السياسة

يستخدم سجل سياسة DMARC صياغة قيمة العلامة. بموجب RFC 9989، تكون v=DMARC1 مطلوبة وحساسة لحالة الأحرف ويجب أن تظهر أولًا؛ وتوفر علامة p صالحة سياسة التقييم المطلوبة. قيم السياسة الشائعة هي none وquarantine وreject. تصف العلامات الاختيارية وجهات إعداد التقارير وسلوك النطاقات الفرعية ومحاذاة SPF وDKIM الصارمة أو المرنة. لا تصلح بصمت العلامات المكتوبة خطأ أو قيمة p المفقودة أو السجلات المكررة أو المتعارضة أو الفواصل غير الصالحة أو قيمة منسوخة مع آثار اقتباس مزوّد DNS. تعامل مع خطأ تقييم دائم بوصفه نتيجة تحتاج إلى تصحيح، لا بوصفه نجاحًا أو فشلًا لـ DMARC. وميّز أيضًا خطأ استعلام DNS عابرًا من سجل مشوّه. أعد محاولة فشل محلل عابر عبر مسار مضبوط، لكن لا تدعِ أن النطاق بلا سياسة حتى يمكن الاستعلام عن DNS الموثوق بصورة موثوقة.

افحص محاذاة SPF وDKIM على رسالة حقيقية

يُقيَّم DMARC بناءً على مصادقة الرسالة، لا على إعدادات DNS بمعزل عنها. بالنسبة إلى SPF، قارن نطاق MAIL FROM المصادَق عليه بنطاق From الظاهر. وبالنسبة إلى DKIM، قارن نطاق d= لكل توقيع تم التحقق منه بنجاح بنطاق From الظاهر. تقبل المحاذاة المرنة النطاقات التي تشترك في النطاق التنظيمي نفسه؛ بينما تتطلب المحاذاة الصارمة نطاقات متطابقة. تنجح الرسالة عندما ينجح معرّف مصادَق عليه واحد على الأقل في آليته الأساسية ويكون محاذيًا. فعلى سبيل المثال، قد يجعل Return-Path الخاص بالمزوّد SPF ينجح لنطاق المزوّد لكنه يبقى غير محاذٍ لـ billing.example.test. وإذا تم التحقق من DKIM بـ d=example.test تحت المحاذاة المرنة، فقد تنجح الرسالة في DMARC رغم ذلك. التقط ترويسة Authentication-Results الخام من حسابات مستلِمين خاضعة للتحكم، لكن فسّرها في سياقها لأنها تعرض نتيجة الجهة المستقبِلة المقيِّمة وقد تحتوي على عدة قفزات أو توقيعات.

اقرأ نتائج pass وfail وnone وerror بدقة

يعني نجاح DMARC أن سجل سياسة ينطبق وأن معرّف SPF أو DKIM مصادَق عليه متحاذٍ مع نطاق From الظاهر. ويعني الفشل أن سياسة تنطبق لكن لا يوجد معرّف مصادَق عليه ومتحاذٍ. وتعني none أنه لم يُكتشف أي سياسة منطبقة. يشير permerror وtemperror إلى أخطاء أثناء تقييم DMARC؛ ولا يمكن اعتبار رسالة ذات خطأ DNS ناجحة أو فاشلة في DMARC. لا تحدد هذه النتائج موضع الرسالة في صندوق البريد لدى مزوّد صندوق البريد. يحصر RFC 9989 النجاح صراحةً في التحقق من أن استخدام مالك النطاق كان مصرحًا به؛ ولا يؤكد أن الرسالة آمنة أو مرغوبة أو حسنة السمعة أو جديرة بصندوق الوارد. أبقِ قبول المزوّد وقبول الخادم المستقبِل ونتيجة DMARC وإشارات الشكاوى وموضع الرسالة المرصود حقولًا منفصلة في التشخيصات ولوحات التحكم.

ارسم خريطة لكل مُرسِل مشروع قبل التطبيق

اجرد كل الأنظمة التي تضع النطاق في From: تطبيقات الإنتاج ورسائل المصادقة وإشعارات الفوترة وأدوات الدعم ومنصات التسويق وتنبيهات المراقبة وسير عمل CRM والحسابات الإقليمية وأنظمة الطوارئ. لكل مسار، سجّل نطاق From الظاهر ونطاق MAIL FROM ونطاق DKIM d= والمحدِّد وحساب المزوّد والمالك وفئة الرسالة والحجم المتوقع. أرسل رسائل خاضعة للتحكم عبر مسار الإنتاج المعتاد وتحقق من المصادقة والمحاذاة معًا. يمكن لتقارير DMARC المجمّعة أن تكشف المصادر التي تستخدم النطاق، لكنها تحتاج إلى تفسير وقد تتضمن حركة معاد توجيهها أو غير مصرّح بها. ابدأ بالمراقبة ما دام الجرد غير مكتمل، ثم عالج المسارات المشروعة غير المحاذية قبل طلب معاملة أشد من الجهات المستقبِلة. لا تغيّر سياسة تنظيمية مشتركة لمجرد جعل تطبيق واحد أخضر، ولا تنتقل إلى التطبيق الصارم استنادًا إلى رسالة اختبار واحدة.

شخّص إخفاقات بريد التطبيقات الشائعة

إذا لم تُعثر على سياسة، فتحقق من منطقة DNS واسم السجل قبل تعديل القيمة. وإذا كان في السجل خطأ دائم، فاختزله إلى سياسة صالحة واحدة وافحص ترتيب الوسوم وصيغتها. وإذا فشل DKIM، فافحص هل المحدِّد المتوقع موجود، وهل وقّع المزوّد الرسالة المختبَرة فعلًا، وهل تغيّر المتن أو الترويسات الموقّعة أثناء النقل، وهل نطاق d= الموثَّق محاذٍ. وإذا نجح SPF وفشل DMARC، فقارن نطاق MAIL FROM بنطاق From الظاهر بدلًا من اعتبار أي نجاح في SPF كافيًا. وإذا فشل البريد المعاد توجيهه فقط، فتذكّر أن إعادة التوجيه كثيرًا ما تغيّر مسار الظرف (envelope) وقد تكسر SPF بينما قد يبقى توقيع DKIM صالحًا ومحاذيًا. وإذا تسبب الطرح في رفض، فاحتفظ بالترويسات الفاشلة واستجابة الجهة المستقبِلة، وأوقف مزيدًا من رفع مستوى السياسة، وأصلح المسار المسؤول بدلًا من إضعاف ضوابط مصادقة لا علاقة لها بالمشكلة.

طبّق قواعد المحاذاة الخاصة بكل مزوّد عن قصد

يحتاج المُرسِلون من الأطراف الثالثة إلى إعداد يربط معرّفاتهم المصادَق عليها بنطاق تتحكم فيه المؤسسة. توثّق Amazon SES مسارين: نطاق MAIL FROM مخصصًا ومحاذيًا لـ SPF، ونطاق توقيع DKIM محاذيًا. وقد يصادق Return-Path الافتراضي المملوك للمزوّد عبر SPF دون أن يحاذي نطاق From الظاهر، لذلك يكون DKIM غالبًا الآلية المحاذية العملية ما لم يُضبط نطاق MAIL FROM مخصص. ويستخدم مزوّدون آخرون أسماء مختلفة لمسارات الإرجاع ونطاقات الارتداد ومصادقة النطاق وهويات التوقيع. تحقق من الرسالة الصادرة الفعلية بدلًا من افتراض أن شارة التوثيق في لوحة التحكم تثبت DMARC. كما تشترط إرشادات Gmail الحالية للمُرسِلين المصادقة والمحاذاة للحركة المنطبقة وتوصي بإبلاغ DMARC. قد تتغير متطلبات الجهات المستقبِلة وميزات المزوّدين، لذلك أعد مراجعة وثائقهم الرسمية عند الإطلاق وأثناء مراجعة الحوادث.

استخدم أدلة المزوّد من دون معاملتها بوصفها نتيجة حاسمة لـ DMARC

يدعم SendHQ إرسال النطاقات الموثقة وأحداث التسليم وقوائم المنع ولوحة تحكم على الويب. استخدم معلومات نطاق الإرسال والتسليم لديه للتحقيق في تدفق رسائل، ثم تحقق من DMARC من ترويسة Authentication-Results لدى المستقبِل وافصل أدلة SPF وDKIM والمحاذاة. لا يثبت قبول المزوّد وأحداث التسليم الوصول إلى صندوق الوارد.

سجّل نتيجة فحص DMARC قابلة للتدقيق

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

الأسئلة الشائعة

أين ينبغي فحص سجل DMARC؟

ابدأ بـ TXT عند _dmarc مضافًا إليه النطاق الدقيق في عنوان From الظاهر. حدد أيضًا نطاق السياسة المختار عبر قواعد اكتشاف DMARC الحالية، لأن سياسة النطاق التنظيمي أو النطاق الفرعي قد تنطبق عندما لا يحتوي الاسم الأول المستعلَم عنه على سجل صالح.

هل يعني العثور على v=DMARC1 أن DMARC ينجح؟

لا. إنه يسهم فقط في تكوين سجل سياسة صالح. تنجح الرسالة بعد أن يصادق SPF أو DKIM بنطاق محاذٍ لنطاق From الظاهر. اختبر رسالة حقيقية وافحص نتائج المصادقة لدى الجهة المستقبِلة.

هل يمكن أن ينجح DMARC عندما يكون SPF غير محاذٍ؟

نعم. يمكن لتوقيع DKIM تم التحقق منه بنجاح أن يوفّر المعرّف المصادَق عليه والمحاذي المطلوب لـ DMARC. والعكس ممكن أيضًا: يمكن لـ SPF محاذٍ أن يدعم النجاح عندما لا ينجح DKIM، مع أن الاعتماد على آلية واحدة فقط يقلل المرونة.

هل يثبت نجاح DMARC الوصول إلى صندوق الوارد؟

لا. إنه يتحقق من الاستخدام المصرّح به لنطاق المؤلف لتلك الرسالة. ولا يزال بإمكان الجهة المستقبِلة تطبيق إشارات السمعة والمحتوى والمستلِم وإساءة الاستخدام والسياسة المحلية عند قبول الرسالة أو رفضها أو عزلها أو تصنيفها.

هل ينبغي أن ينتقل التطبيق مباشرة إلى p=reject؟

عادةً لا، من دون أدلة الجرد والمراقبة. عيّن كل مُرسِل مشروع، وتحقق من المحاذاة في رسائل مضبوطة، وراجع التقارير المجمعة، وعالج حالات الفشل، ونسّق تغييرات السياسة مع مالك النطاق قبل طلب معالجة أقوى.

ما الذي ينبغي إعادة فحصه بعد تبديل مزوّدي البريد؟

أعد فحص السياسة المكتشفة لكل نطاق From، ونطاقَي MAIL FROM وDKIM لدى المزوّد، وسجلات DNS الخاصة بالمحدِّد، ونتائج SPF وDKIM، والمحاذاة المرنة أو الصارمة، والتقارير المجمّعة، وكل فئة من فئات رسائل التطبيقات الخاضعة للتحكم قبل زيادة حركة الإنتاج.

المصادر