كيفية إضافة DMARC؟ الدليل الشامل لبروتوكول DMARC وسجلات DNS TXT وتحليل تقارير XML ومعيار BIMI

ما هو بروتوكول DMARC ولماذا لا يكفي SPF و DKIM وحدهما لمنع انتحال النطاق؟

من أكثر المفاهيم الخاطئة شيوعاً في هندسة أمن البريد المؤسسي الاعتقاد بأن مجرد نشر سجلات SPF (إطار عمل سياسة المرسل) و DKIM (البريد المعرّف بمفاتيح النطاق) يكفي لحماية اسم النطاق تلقائياً من عمليات الانتحال المباشر (Exact-Domain Spoofing). في الواقع التقني، يتضمن بروتوكول SMTP هويتين مختلفتين تماماً للمرسل: مرسل الغلاف وفق معيار RFC 5321 (MAIL FROM / Return-Path) الذي تستخدمه خوادم البريد لتوجيه رسائل الارتداد، ومرسل الترويسة وفق معيار RFC 5322 (From:) الذي يظهر أمام عين المستخدم النهائي داخل تطبيق البريد الإلكتروني (Gmail أو Outlook أو Apple Mail).

في غياب بروتوكول DMARC (الموثق في المعيار القياسي RFC 7489)، يستطيع المهاجم تسجيل نطاق خارجي رخيص (مثل attacker-mailer.net)، وإعداد سجلات SPF و DKIM صحيحة تماماً لذلك النطاق، ثم إرسال رسالة بريد إلكتروني يحمل غلافها الخفي عنوان MAIL FROM:<bounce@attacker-mailer.net> بينما تعرض ترويستها المرئية للمستلم العنوان From: "الإدارة التنفيذية" <ceo@yourdomain.com>. ونظراً لأن بروتوكولي SPF و DKIM لا يقارنان ترويسة From: المرئية مع النطاق الذي تمت مصادقته، فإن الرسالة تجتاز الفحص بنجاح وتصل إلى صندوق الوارد للضحية. يغلق بروتوكول DMARC هذه الثغرة الخطيرة نهائياً عبر فرض محاذاة المعرفات (Identifier Alignment) بين النطاق الظاهر في حقل From: والنطاقات الموثقة تشفيرياً بواسطة SPF و DKIM.

1. آلية محاذاة المعرفات في DMARC: معامِلا aspf و adkim

لكي تجتاز الرسالة تقييم DMARC بنجاح، لا يكفي حصولها على نتيجة نجاح (Pass) خام في فحص SPF أو DKIM، بل يجب أن يتطابق النطاق الموثق مع النطاق المستخرج من ترويسة From: المرئية. ويوفر DMARC وضعين للمحاذاة لكل من SPF (عبر وسم aspf) و DKIM (عبر وسم adkim):

• المحاذاة المرنة (Relaxed Alignment — r، الوضع الافتراضي): يجب أن يتطابق النطاق التنظيمي الجذري في ترويسة From: المرئية مع النطاق التنظيمي الجذري الموثق في SPF (Return-Path) أو DKIM (d=). على سبيل المثال، إذا كانت الترويسة From: billing@yourdomain.com وكان عنوان الغلاف Return-Path: bounce@ses.yourdomain.com، فإن المحاذاة المرنة تنجح.
• المحاذاة الصارمة (Strict Alignment — s): يجب أن يتطابق اسم النطاق المؤهل بالكامل (FQDN بما في ذلك النطاق الفرعي) في ترويسة From: حرفياً مع نطاق SPF أو DKIM. في الوضع الصارم (adkim=s; aspf=s)، لا يتطابق النطاق yourdomain.com مع ses.yourdomain.com ويفشل التقييم.

2. المرجع الكامل لوسوم سجل DNS TXT لبروتوكول DMARC

يتم نشر سياسة DMARC كسجل نصي قياسي من نوع TXT في نظام أسماء النطاقات (DNS) تحت المضيف _dmarc.yourdomain.com. يوضح الجدول التالي الوظيفة التقنية لكل وسم وتأثيره المعماري:

3. كيفية إضافة DMARC خطوة بخطوة: خطة الانتقال الهندسي من 3 مراحل

إن تفعيل سياسة الحظر القاطع p=reject بشكل مفاجئ على نطاق مؤسسي قائم ينطوي على مخاطرة كبيرة؛ إذ قد يؤدي إلى حظر الرسائل الشرعية الصادرة من أنظمة خارجية (مثل برامج المحاسبة والفوترة، أو منصات الموارد البشرية، أو أنظمة CRM) التي لم يتم ضبط محاذاتها بعد. في Kling Digital، ننفذ انتقال DMARC عبر ثلاث مراحل هندسية محكمة:

المرحلة الأولى: المراقبة واكتشاف مصادر الإرسال (p=none)

نبدأ بوضع المراقبة السلبية دون حظر أي رسالة، مع تفعيل استلام التقارير اليومية المجمعة بصيغة XML على بريد rua المخصص:

_dmarc.yourdomain.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@yourdomain.com; fo=1;"

خلال فترة تتراوح بين أسبوعين إلى أربعة أسابيع، يتم تحليل ملفات XML لحصر جميع الأنظمة الشرعية التي ترسل بريداً باسم النطاق، وتفعيل مفاتيح توقيع DKIM بطول 2048 بت، وإعداد نطاقات ارتداد فرعية مخصصة (Custom Return-Path عبر سجلات CNAME) لكل خدمة.

المرحلة الثانية: الحجر التدريجي والتحكم بالنسبة المئوية (p=quarantine)

بعد التأكد من أن جميع المسارات الشرعية تجتاز محاذاة DMARC بنسبة 100%، يتم رفع السياسة إلى p=quarantine لتوجيه الرسائل المنتحلة إلى مجلد السبام، بدءاً بنسبة pct=25 ثم رفعها إلى pct=100:

_dmarc.yourdomain.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourdomain.com; fo=1;"

المرحلة الثالثة: الإغلاق الكامل وحماية النطاقات الفرعية (p=reject)

بعد التحقق التام من عدم تأثر أي مراسلات شرعية في مرحلة الحجر، يتم تطبيق سياسة الرفض القاطع p=reject للنطاق الرئيسي و sp=reject لجميع النطاقات الفرعية لرفض أي محاولة انتحال مباشرة أثناء اتصال SMTP:

_dmarc.yourdomain.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rua@yourdomain.com; ruf=mailto:dmarc-ruf@yourdomain.com; fo=1;"

4. التحليل التقني لتقارير DMARC المجمعة بصيغة XML (RUA)

ترسل خوادم البريد العالمية أرشيفات مضغوطة (.xml.gz) يومياً إلى عنوان rua تحتوي على إحصاءات المصادقة مصنفة حسب عنوان IP المرسل. وفيما يلي نموذج حقيقي لمقطع من تقرير XML في بيئة الإنتاج:

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>1420</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>yourdomain.com</domain>
      <selector>kling2026</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>notify.yourdomain.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

عند تدقيق هذه التقارير، يجب التمييز بدقة بين قسم <auth_results> (الذي يعرض نتيجة فحص SPF/DKIM الخام) وقسم <policy_evaluated> (الذي يعرض النتيجة النهائية بعد فحص محاذاة النطاق). فإذا ظهر SPF ناجحاً في auth_results ولكنه فاشل في policy_evaluated، فهذا يعني أن مزود البريد الخارجي يستخدم نطاقه الخاص في حقل Return-Path بدلاً من نطاق فرعي متوافق مع نطاقك.

5. تفويض DNS لإرسال التقارير إلى نطاق خارجي (_report._dmarc)

عندما تدير المؤسسة عدة نطاقات وترغب في تجميع تقارير DMARC الخاصة بها في بريد أمني مركزي على نطاق مختلف (مثلاً إرسال تقارير brand-a.com إلى dmarc@security-ops.com)، يشترط معيار RFC 7489 نشر سجل TXT للتفويض في منطقة DNS الخاصة بالنطاق المستقبِل للتقارير:

brand-a.com._report._dmarc.security-ops.com. 3600 IN TXT "v=DMARC1"

6. التكامل مع معيار BIMI وشهادات العلامة التجارية الموثقة (VMC)

يفتح الوصول إلى سياسة تطبيق صارمة في DMARC الباب لتفعيل معيار BIMI (مؤشرات العلامة التجارية لتعريف الرسائل)، والذي يتيح إظهار الشعار الرسمي الموثق لشركتك وعلامة التوثيق الزرقاء بجوار رسائلك في صناديق وارد Gmail و Apple Mail و Yahoo.

يتطلب تفعيل BIMI ثلاثة شروط تقنية أساسية:

1. أن تكون سياسة DMARC للنطاق مضبوطة على الإلزام الكامل: إما p=quarantine; pct=100 أو p=reject (لا يعمل BIMI إطلاقاً مع p=none).
2. تصميم شعار الشركة بصيغة متجهة تتوافق بدقة مع معيار SVG Tiny Portable/Secure (SVG P/S) واستضافته عبر بروتوكول HTTPS.
3. إصدار شهادة علامة تجارية موثقة VMC (Verified Mark Certificate) أو CMC من سلطة تصديق معتمدة (مثل DigiCert أو Entrust) لإظهار شارة التوثيق الرسمية في Gmail و Apple Mail.

default._bimi.yourdomain.com. 3600 IN TXT "v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/vmc.pem;"

7. معالجة إعادة التوجيه التلقائي (Forwarding) وسلسلة ARC (RFC 8617)

عند تطبيق سياسة p=reject، تمثل عمليات إعادة التوجيه التلقائي للبريد حالة تقنية دقيقة؛ فعندما يقوم خادم وسيط بإعادة توجيه الرسالة إلى حساب آخر دون تعديل عنوان الغلاف، يفشل فحص SPF لأن عنوان IP الخاص بالخادم الوسيط غير مدرج في سجل SPF لنطاقك. غير أنه بما أن DMARC يقبل الرسالة إذا نجح أحد المسارين المحاذيين (SPF أو DKIM)، فإن التوقيع الرقمي DKIM بمفتاح 2048 بت يضمن عبور الرسائل المعاد توجيهها بسلام. أما بالنسبة للقوائم البريدية التي تعدل نص الرسالة، فإن بروتوكول ARC (سلسلة الاستلام الموثقة — RFC 8617) يسمح للخوادم الوسيطة بختم نتيجة المصادقة الأصلية تشفيرياً قبل التعديل.