كيف تقرأ تقرير DMARC دون أن تغرق في XML

ما هو تقرير DMARC فعلًا

انشر سجل DMARC بعنوان في rua= وسيبدأ مزوّدو البريد بإرسال تقارير مجمّعة إليك: ملف XML لكل مزوّد في اليوم، يسرد كل عنوان IP أرسل بريدًا باسم نطاقك، وكم رسالة أرسل كل منها، وهل نجح SPF و DKIM واصطفّا.

أمران يُستحسن معرفتهما قبل فتح أول ملف:

• التقارير المجمّعة لا تحتوي محتوى الرسائل. لا موضوعات ولا مستلمين ولا نصوص. إنها إحصاءات مجمّعة بحسب عنوان الإرسال. لذلك يمكن جمعها بأمان، ولذلك لا يمكنها أن تخبرك أي رسالة أخفقت.
• ليست هي تقارير الأدلة الجنائية. فعنوان ruf= يطلب عيّنات إخفاق لكل رسالة، وفيها ترويسات وأحيانًا أكثر. ومعظم المزوّدين لم يعودوا يرسلونها أصلًا لأسباب تتعلق بالخصوصية، فصارت رؤية DMARC عمليًا هي التقارير المجمّعة.

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

كيف تبدأ باستلامها

سجل أدنى يجمع البيانات فقط ولا يغيّر شيئًا في التسليم:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

يوضع على _dmarc.example.com كسجل TXT. ويعني p=none «لا تطبّق أي سياسة، فقط أخبرني» – وهي نقطة البداية الصحيحة ولا يمكنها أن تضرّ تسليمك. وتحقّق من أن السجل منشور ومقروء فعلًا عبر أداة استعلام DNS قبل انتظار تقارير لن تصل أبدًا.

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

قراءة XML: ثلاث كتل

لكل تقرير مجمّع الشكل نفسه. وما إن تراه مرة حتى يكفّ عن الترهيب.

الكتلة 1: من أرسل التقرير

تذكر <report_metadata> اسم الجهة المُبلِّغة ومعرّف التقرير ونطاقًا زمنيًا. والنطاق الزمني هو ما ينبغي ملاحظته: التقارير عادةً نافذة من 24 ساعة، وتصل متأخرة يومًا أو يومين، فالعنوان الذي تنظر إليه أرسل في الماضي.

الكتلة 2: السياسة التي رأوها

الكتلة <policy_published> هي سجل DMARC الخاص بك كما قرأه ذلك المزوّد: p (سياستك)، وsp (سياسة النطاقات الفرعية)، وpct (النسبة التي طلبت تطبيقها)، وأوضاع الاصطفاف. وهذه الكتلة فحص مفيد: فإن لم تطابق ما تظن أنك نشرته، ففي سجلك خطأ صياغة أو أنه لم ينتشر بعد.

الكتلة 3: الصفوف التي تهم

ثم تأتي سلسلة من عناصر <record>. كل عنصر مجموعة من الرسائل من عنوان واحد بنتيجة واحدة، لا رسالة مفردة. ويحتوي كل منها على <row> فيه عنوان المصدر وعدد، و <policy_evaluated> فيه نتيجة DMARC وما فعله المزوّد فعلًا، و <auth_results> فيه نتائج SPF و DKIM الأساسية.

قراءة صف واحد عمليًا

امضِ بهذا الترتيب، وسيجيب الصف عن نفسه:

1. لمن هذا العنوان؟ ابحث عنه. فاسم منصة بريد معروفة يعني أنه خدمة لك؛ أما شبكة غير مألوفة فهي ما ينبغي التحقيق فيه.
2. كم رسالة؟ رسالتان ضجيج. وعشرون ألفًا نظام.
3. ماذا تقول <policy_evaluated><disposition>؟ none أو quarantine أو reject – ما فعله المزوّد.
4. هل نجح SPF و DKIM، وهل اصطفّا؟ هذا الثنائي هو التشخيص كله، وهو القسم التالي.

الاحتمالات الأربعة وما يعنيه كل منها

ينجح DMARC إذا نجح أحدهما، SPF أو DKIM، واصطفّ مع نطاق From: المرئي. ومن ذلك أربع حالات:

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

انتبه لفخّ في XML: قد تقرأ نتيجة pass في <auth_results> ويخفق DMARC رغم ذلك، لأن النطاق الموثَّق لم يصطفّ مع نطاق From:. والمنصة التي توقّع بنطاقها هي التي تنتج ذلك بالضبط. وإن التبس الأمر، فإن لماذا نجاح SPF ليس نجاح DMARC يتناول الاصطفاف بالتفصيل.

تمييز مرسِليك من الانتحال

تبدو التقارير الأولى مقلقة لدى الجميع تقريبًا، وقلّما يكون شيء منها هجومًا. وزّع العناوين المخفقة على ثلاث أكوام:

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

الترتيب مهم. حدّد الكومة الأولى كاملة قبل تشديد السياسة، لأن التطبيق يحوّل مرسِلًا لك بإعداد خاطئ إلى بريد لا يصل.

لماذا يبدو المحوِّلون كمهاجمين

يلتبس هذا على الجميع مرة. فالقائمة البريدية أو الاسم البديل يعيدان إرسال رسالتك من خادمهما، فيُفحص سجل SPF لديك على عنوان لم تصرّح به قطّ، فيخفق – وبحق. ويُظهر التقرير عنوانًا مجهولًا يخفق في SPF بينما يرسل باسمك، وهو ما يُقرأ تمامًا كإساءة استخدام.

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

استخدام التقارير للوصول إلى التطبيق

التقارير موجودة لتجعل هذه الخطوة آمنة. وإليك تسلسلًا عمليًا:

• ابقَ على p=none حتى تصير التقارير مملّة – أسابيع قليلة عادةً. أنت تنتظر حتى يُصرَّح بكل مرسِل مشروع تجده ولا يظهر جديد.
• أصلح المرسِلين أولًا بأول، مفضّلًا DKIM. فالمرسِل الذي لديه DKIM ينجو من التحويل، ومن لديه SPF فقط لا ينجو.
• انتقل إلى p=quarantine، وربما مع pct= للتدرّج. فالبريد المخفق يذهب إلى الرسائل المزعجة بدل أن يختفي، ويبقى الخطأ قابلًا للتدارك.
• ثم p=reject، بعد أن يهدأ الحجر الصحي. وهنا يُرفض فعلًا البريد الذي ينتحل نطاقك.
• واصل قراءة التقارير بعد ذلك. فمزوّد جديد يُضاف بعد ستة أشهر سيظهر كعنوان مخفق، وتريد أن تراه قبل أن يخبرك أحد بأن فواتيره ترتدّ.

لا تضع p=reject في اليوم الأول. فالشيء الوحيد الذي يجعل التطبيق آمنًا هو الجرد الذي تمنحه التقارير، وهو يحتاج أسابيع ليكتمل. ويتناول دليل SPF و DKIM و DMARC السجلات نفسها.

أخطاء شائعة

• القفز إلى p=reject قبل قراءة التقارير. فالنظام المنسي هو عادةً الذي يصدر فواتير عملائك.
• قراءة كل صف كأنه رسالة واحدة. الصف مجموعة رسائل من عنوان واحد بنتيجة واحدة.
• اعتبار كل عنوان مخفق مهاجمًا. فمعظم الإخفاقات المبكرة خدماتك أنت وتحويل عادي.
• افتراض أن pass في auth_results يعني نجاح DMARC. فبلا اصطفاف مع نطاق From: لا يعني ذلك.
• إرسال التقارير إلى صندوق يتابعه إنسان. تصل يوميًا من عشرات المزوّدين. استخدم عنوانًا مخصّصًا.
• نسيان سياسة النطاقات الفرعية. فبلا sp= ترث النطاقات الفرعية p، وقد لا يكون ذلك مرادك أثناء التدرّج.
• إصلاح SPF وحده. فـ SPF ينكسر عند التحويل؛ و DKIM هو ما يعبر بـ DMARC خلاله.
• إيقاف التقارير عند بلوغ reject. فعندها بالذات تصبح نظام إنذار مبكر.

الخلاصة

تقرير DMARC المجمّع قائمة XML يومية بكل عنوان يرسل باسم نطاقك، مع الإحصاءات ونتائج SPF و DKIM – بلا أي محتوى للرسائل. اقرأ كل صف في أربع خطوات: حدّد العنوان، وانظر إلى الحجم، واقرأ القرار، ثم تحقّق هل نجح SPF أو DKIM واصطفّ. وتوقّع أن تكون معظم الإخفاقات المبكرة خدماتك غير المضبوطة وتحويلًا عاديًا لا انتحالًا، وأصلح المرسِلين بـ DKIM حيثما أمكن، ولا تنتقل من p=none إلى الحجر ثم الرفض إلا بعد أن تهدأ التقارير. تحقّق من أن سجل _dmarc لديك منشور ومقروء عبر أداة البحث في DNS المجانية، وإن بدت نتيجة SPF في تقرير متناقضة فإن دليل معالجة SPF يوضّح السبب.

أدوات وأدلة ذات صلة:

• بحث DNS — استعلم عن سجلات A وAAAA وMX وTXT وNS والمزيد بالقيم وTTL، بالإضافة إلى DNS العكسي.
• لماذا يفشل سجل SPF لديك مرارًا، وكيف تُصلحه — كيف تقرأ سجل SPF

أسئلة شائعة