الخلاصة

  • ينجح DMARC عندما يتحاذى نطاق واحد على الأقل تم توثيقه عبر SPF أو DKIM مع نطاق المؤلف في RFC5322.From. النتيجة تثبت الاستخدام المأذون للنطاق، لا الجزء المحلي أو الاسم المعروض أو الشخص أو المحتوى.
  • لا يعني fail حكماً معاكساً بالاحتيال. فقد يكسر مُعيد توجيه أو قائمة بريدية مشروعة تحاذي SPF أو توقيع DKIM قبل وصول الرسالة.
  • قيم p وsp وnp تفضيلات معالجة مطلوبة عبر DNS. يحتفظ المستقبِل بالسياسة المحلية، وقد يرفض رسالة ناجحة أو يقبل رسالة فاشلة بعد جمع السمعة والمحتوى وسياق الإساءة.

ستة أفعال تبدو فعلاً واحداً

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

نُشرت RFC 9989 في مايو 2026 على مسار معايير الإنترنت، وألغت RFC 7489 وRFC 9091. شارك Todd M. Herr وJohn Levine في تحريرها. وتضع الوثيقة الحد في مقدمتها: نجاح DMARC يدل فقط على أن استخدام نطاق المؤلف قد تم التحقق منه بوصفه مأذوناً من مالك النطاق. لا يحمل هذا الإذن حكماً صريحاً أو ضمنياً على الرسالة أو على المالك، ولا يضمن أن تسليمها إلى صندوق الوارد آمن أو مرغوب.

هذه العبارة تحدد موضوع الإثبات. فإذا سجّل النظام «مرسل موثوق» أو «رسالة آمنة»، فعليه أن يبين الدليل الآخر الذي أنشأ ذلك الحكم.

ما يضيفه التحاذي إلى SPF وDKIM

يختبر SPF هل المضيف المتصل مأذون له باستخدام نطاق في هوية SMTP MAIL FROM أو HELO؛ ويستعمل DMARC نطاق MAIL FROM. أما DKIM فيتحقق من توقيع تشفيري ويربط الأجزاء المغطاة بنطاق التوقيع d=. يمكن لكل منهما النجاح من دون أن يكون نطاقه هو النطاق الذي يراه القارئ في حقل From.

يستخرج DMARC نطاق المؤلف من RFC5322.From ثم يطلب التحاذي. في الوضع الصارم يكون النطاقان متطابقين، وفي الوضع المرن يشتركان في Organizational Domain واحد. يعلن مالك النطاق اختياره بواسطة aspf وadkim، وتذكر RFC 9989 أن الوضع المرن لبّى حاجة معظم المالكين في الممارسة.

يكفي معرّف موثق واحد متحاذٍ. قد تحمل الرسالة عدة توقيعات DKIM، فيفشل أحدها بينما يمنح آخر صالح ومتحاذٍ نتيجة النجاح. وقد ينجح SPF لنطاق وسيط من دون أن يتحاذى مع From الأصلي. لذلك يجب أن يتضمن الإيصال الآلية والنطاق ووضع التحاذي ووقت المراقبة، لا كلمة النجاح وحدها.

الشخص والاسم والمضمون في دفاتر أخرى

في عنوان يجمع الجزء المحلي finance مع النطاق example.com، يعالج DMARC النطاق example.com. لا يثبت وجود صندوق finance أو من يسيطر عليه أو أن موظفاً بعينه كتب الرسالة. وتنص RFC 9989 صراحة على أن آلياتها لا تتحقق من الجزء المحلي للعنوان.

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

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

الاستمرار في الفحص بعد pass لا يقلل الثقة بالبروتوكول؛ بل يمنع تحميله ادعاء لم يقدمه.

لماذا تصل رسالة مشروعة بلا دليلها الأول

تصف RFC 7960 تدفقات البريد غير المباشرة. إذا أبقى معيد التوجيه MAIL FROM الأصلي، فقد يتصل من عنوان IP غير مأذون في SPF الأصلي. وإذا استبدله بنطاقه، فقد ينجح SPF لكن يضيع التحاذي مع RFC5322.From.

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

لهذا تعمدت RFC 9989 القول إن الرسالة الفاشلة ليست «بالضرورة» غير مرتبطة بنطاق المؤلف. الفشل يصف ما استطاع المستقبِل النهائي التحقق منه، لا كل ما حدث في الطريق، ولا نية المؤلف.

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

صاحب النطاق يطلب والمستقبِل يقرر

يبدأ اكتشاف السياسة من نطاق المؤلف، ثم ينتقل إلى Organizational Domain، ثم إلى Public Suffix Domain. يحدد موقع السجل ووجود النطاق الفرعي هل تنطبق p أو sp أو np. ويصف سجل IANA هذه القيم بأنها سياسات مطلوبة، كما يبين أن الوسوم القديمة pct وrf وri أصبحت تاريخية.

لا يمنح الطلب حق الإدارة عن بعد. تترك RFC 9989 المعالجة النهائية دائماً لسياسة Mail Receiver المحلية. يستطيع المستقبِل حجر رسالة ناجحة إن كانت السمعة أو المحتوى سيئاً، وقبول رسالة فاشلة حتى مع p=reject إذا عرف مساراً غير مباشر مشروعاً. وتوصي الوثيقة بألا يكون reject المنشور وحده سبب الرفض، حمايةً للبريد المشروع والقوائم.

إن لم تكتمل استعلامات DNS، فلا تكون النتيجة نجاحاً أو فشلاً ولا تطبق سياسة المالك كما لو اكتشفت. يختار المستقبِل التسليم أو التأجيل أو إجراء آخر ويتحمل نتيجة اختياره.

يطرح Heng Lu في The Policy Mirror اختباراً لنطاق القاعدة: هل تحفظ الحد الأدنى اللازم للتنسيق، أم تستولي على قرار يتحمل أثره مشغل آخر؟ لا تستمد RFC سلطتها من المقال، لكن الاختبار يوضح هندستها. نشر التفضيل يجعله قابلاً للقراءة؛ ولا ينقل مفتاح قائمة الانتظار.

عنوان التقرير ليس دليلاً على اكتمال المشاهدة

يمكن استخدام rua لطلب تقارير مجمعة وruf لطلب معلومات عن حالات فشل منفردة. تساعد التقارير المجمعة على رؤية الانتحال وثغرات المصادقة في المصادر المشروعة. لكن المستقبِل غير ملزم بإرسال كل المطلوب. توصي RFC بالتقارير المجمعة، وتجعل التقارير الفردية اختيارية وغالباً ما تحدها الخصوصية.

إذن يثبت URI المنشور وجود طلب فقط. ويثبت التقرير المستلَم مراقبة جهة واحدة خلال مدة وتحت تطبيق محدد. لا يثبت تغطية عالمية أو تنفيذ reject أو مصير كل رسالة.

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

نسب الفضل إلى Todd Herr من دون اختراع سلطة

في لقطة 1 سبتمبر 2026، تربط صفحة IETF العامة Todd Herr بـRFC 9989 وتعرض عمله مراجعاً في ART Area Review Team. وتثبت الصورة العامة هويته البصرية. تسجل RFC Herr مع Valimail وتسجل المحرر المشارك John Levine مع Standcore LLC، بينما تحفظ الشكر لمساهمي مجموعة DMARC والعمل الأقدم.

يمكن للمقال أن ينسب إلى Herr مساهمة تحريرية محددة: النص الذي شارك في تحريره لم يخف حدود النجاح ولا سيطرة المستقبِل. لكنه ليس المخترع الوحيد ولا مدقق كل نطاق ولا مشغل كل بوابة. تكبير الشخص على حساب بنية المسؤوليات سيهدم المعنى الذي يستحق أن يُنسب إليه.

سلسلة لا تورّث ادعاءاتها

ينبغي للسجل القابل للتدقيق أن يحفظ الرسالة وحقل From، وكل نتيجة SPF وDKIM مع النطاق والـselector والسبب والوقت، ووضع التحاذي والمعرّف الحاسم، ومسار DNS والوسم المطبق، وأخطاء الاستعلام، وتحويلات الوسطاء، والسمعة وفحص المحتوى، والقرار المحلي، ونتيجة المستخدم، والتقارير المرسلة والمستلمة فعلاً.

لا يرث النطاق هوية الشخص. لا يرث التحاذي صدق النص. لا يرث النجاح الأمان. لا يرث التفضيل البعيد التنفيذ. لا يرث قبول SMTP صندوق الوارد، ولا يرث صندوق الوارد غياب الضرر.

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

المصادر