كيف تقرأ تقارير DMARC التجميعية (rua): من ملف XML خام إلى قرار

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

ما تقرير rua ومتى يصل

الوسم rua في سجل DMARC يحدّد أين يرسل المستقبِلون التقارير التجميعية. ينصّ RFC 7489 على أن rua اختياري، وأن على المستقبِل دعم عناوين mailto:، وألا يُنشئ تقريرًا تجميعيًا إن غاب الوسم. أما وسم الفاصل ri فقيمته الافتراضية 86400 ثانية، فالإيقاع المعتاد تقرير يومي من كل مستقبِل. وتذكر Google في إرشاد Workspace أنك قد تتلقى تقارير كثيرة كل يوم، وأن المؤسسات الكبيرة قد تصلها مئات أو آلاف التقارير يوميًا.

تصل التقارير رسائل بريد يكون الـXML فيها مرفقًا. يقول RFC 7489 إن الـXML ينبغي أن يُضغط بـgzip، فتوقّع ملفات .xml.gz ونوع وسائط application/gzip. ويذكر أيضًا عشرة ميغابايت كحدّ شائع عند المستقبِلين. توصي Google بصندوق بريد مخصّص أو مجموعة أو خدمة تقارير خارجية بدل صندوقك الشخصي، وتنبّه إلى أن العنوان الواقع في نطاق آخر يحتاج سجل TXT في DNS للتفويض.

هكذا يبدو سجل يؤدي الغرض (بدّل النطاق):

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

بنية الـXML في أربع كتل

يعرّف الملحق C من RFC 7489 المخطط. لكل تقرير عنصر جذر feedback يضم أربعة أنواع من الأبناء:

الكتلة	الحقول التي ستستعملها فعلًا	ما تخبرك به
report_metadata	org_name وreport_id وdate_range (begin وend)	أي مستقبِل أرسل التقرير وعن أي فترة. الأوقات بثواني Unix (epoch).
policy_published	domain وp وsp وpct وadkim وaspf	سجل DMARC كما رآه المستقبِل. افحصه أولًا: خطأ إملائي هنا يعني أن المستقبِل يحاكم سياسة غير التي تظنها.
record / row	source_ip وcount وpolicy_evaluated (disposition وdkim وspf)	مجموعة رسائل من IP واحد، وعددها، وما خلص إليه DMARC.
identifiers وauth_results	header_from وenvelope_from، وفي كل توقيع dkim (domain وselector وresult) وspf (domain وresult)	نتائج المصادقة الخام والنطاقات التي أنتجتها، لترى أي خدمة وقّعت أو نجحت.

يختلط policy_evaluated بـauth_results على كثيرين. الأول حكم DMARC وهو يعتمد على المحاذاة. والثاني نتيجة SPF أو DKIM الخام للنطاق الذي صادق فعلًا، وقد لا يكون نطاقك. قد تظهر رسالة بـspf pass في auth_results لنطاق مزوّد البريد وتظهر spf fail في policy_evaluated، لأن ذلك النطاق لا يتوافق مع نطاق From.

خطوة بخطوة: اقرأ تقريرًا واحدًا

1. افحص البيانات الوصفية. حوّل begin وend من ثواني epoch إلى تواريخ. تقرير لا يغطي اليوم الذي تتوقعه يبقى صحيحًا؛ الفترات تختلف بين المستقبِلين.
2. افحص policy_published. تأكد أن p وsp وpct هي ما قصدت نشره.
3. سرد السجلات حسب IP. كل record مجموعة. دوّن الـIP والعدد ونتيجتي policy_evaluated.
4. علّم كل سجل نجاحًا أو فشلًا. ينجح DMARC حين ينجح SPF أو DKIM مع المحاذاة. الفشل يعني أن كليهما فشل.
5. تعرّف على كل IP. طابقه مع خدمة تستعملها (منصة البريد، نظام العملاء، الدعم، الفوترة) عبر نطاقات المزوّد المنشورة أو اسم reverse DNS. العناوين المجهولة هي قائمة تحقيقك.
6. رجّح بالعدد count. 300 رسالة فاشلة من خادم واحد أهم من 3 من آخر. احسب نسبة الفاشل من الحجم الكلي.
7. دوّن الإصلاحات. لكل مرسل مشروع يفشل، حدّد هل يحتاج SPF أو DKIM أو المحاذاة إلى عمل.

🛡️فاحص SPF وDKIM وDMARCSPF تكراري مع حد الـ 10 استعلامات ومفاتيح DKIM وسياسة DMARCافتح الأداة →

مثال محسوب: تقرير واحد وأربعة مصادر

بنينا تقريرًا صغيرًا للنطاق example.com بأربعة سجلات وحلّلناه بمحلّل XML المضمَّن في بايثون (السكربت أدناه). عناوين IP مأخوذة من النطاقات المخصصة للتوثيق، فليست مرسِلين حقيقيين. يغطي التقرير يومًا واحدًا بتوقيت UTC، من 2026-10-24 00:00:00 إلى 23:59:59 (epoch من 1792800000 إلى 1792886399)، والسياسة المنشورة p=none.

IP المصدر	العدد	DKIM (المقيَّم)	SPF (المقيَّم)	DMARC	المعنى المرجَّح
203.0.113.10	4,200	pass	pass	pass	منصة بريدك الرئيسية، متوافقة بالكامل
198.51.100.25	860	pass	fail	pass	أداة النشرات: DKIM متوافق، لكن SPF فيها ينجح لنطاقها هي لا نطاقك
192.0.2.200	45	fail	pass	pass	SPF متوافق، لكن توقيع DKIM يعود لنطاق آخر
192.0.2.77	310	fail	fail	FAIL	لا محاذاة إطلاقًا: نظام منسيّ أو انتحال

الحساب: إجمالي الرسائل = 4,200 + 860 + 310 + 45 = 5,415. الرسائل الناجحة في DMARC = 4,200 + 860 + 45 = 5,105 أي 94.28%. الفاشلة = 310 أي 5.72%. تحت p=quarantine أو p=reject ستتأثر هذه الـ310. قبل التشديد عليك أن تقرر: هل 192.0.2.77 مرسل مشروع نسيته (أضفه إلى SPF أو فعّل DKIM) أم إساءة (وهذا ما صُممت السياسة لإيقافه)؟

انتبه إلى الـ860 رسالة من أداة النشرات. هي تنجح بـDKIM وحده. يكفي هذا لـDMARC، لكنه يترك لك نقطة فشل واحدة: إن دوّر المزوّد مفاتيحه أو حُذف سجل DKIM الخاص به فسيفشل التدفق كله دفعة واحدة. إصلاح محاذاة SPF عبر نطاق return-path مخصّص يمنح التدفق طريقين مستقلين للنجاح.

سكربت: لخّص التقرير في ثوانٍ

يعمل بالمكتبة القياسية وحدها. احفظ الـXML المفكوك باسم report.xml:

import xml.etree.ElementTree as ET, datetime
root = ET.parse("report.xml").getroot()
dr = root.find("report_metadata/date_range")
for k in ("begin", "end"):
    t = datetime.datetime.fromtimestamp(int(dr.find(k).text), datetime.timezone.utc)
    print(k, t.isoformat())
total = passed = 0
for rec in root.findall("record"):
    row = rec.find("row")
    pe = row.find("policy_evaluated")
    n = int(row.find("count").text)
    ok = "pass" in (pe.find("dkim").text, pe.find("spf").text)
    total += n
    passed += n if ok else 0
    print(row.find("source_ip").text, n, pe.find("dkim").text, pe.find("spf").text, "pass" if ok else "FAIL")
print(total, passed, round(passed / total * 100, 2))

عند تشغيله على مثالنا يطبع الأرقام نفسها: 5,415 رسالة، 5,105 ناجحة، 94.28%. ولنظرة على ترويسات رسالة واحدة من مصدر فاشل، الصق ترويساتها في الأداة التالية.

🔍محلّل رؤوس البريداقرأ SPF وDKIM وDMARC ومسار القفزات وتأخيرها وتوافق النطاقات من رؤوس الرسالةافتح الأداة →

ما الجديد في 2026: RFC 7489 صار منسوخًا

تنصّ وثيقتان جديدتان على أنهما تنسخان RFC 7489: فـRFC 9990 (التقارير التجميعية، Proposed Standard) تقول إنها تنسخه، وRFC 9989 (البروتوكول الأساسي) تنسخ RFC 7489 وRFC 9091. كلتاهما بحقوق نشر 2026، وتذكر RFC 9990 أن RFC 9989 صدرت في مايو 2026. وأهم التغييرات لقراءة التقارير:

• يستعمل الـXML فضاء الأسماء urn:ietf:params:xml:ns:dmarc-2.0 مع version بقيمة 1.0.
• يضيف policy_published الحقول np (سياسة النطاقات الفرعية غير الموجودة) وtesting وdiscovery_method (psl أو treewalk).
• صار selector في DKIM مطلوبًا عند الإبلاغ عن توقيع، فيسهل معرفة المفتاح الذي وقّع.
• يغطي كل تقرير نطاق سياسة DMARC واحدًا، ويصف المعيار فترة تقرير بيوم UTC.
• تحذف RFC 9989 الوسم pct من سجلّ الوسوم لديها، فالمستقبِل الذي يتبعها يتجاهله. أما توثيق Google لـWorkspace فما زال يصف pct للتطبيق التدريجي (حتى أكتوبر 2026)، فتحقق مما يلتزم به مستقبِلوك قبل الاعتماد عليه.

يتبنّى المستقبِلون المعايير الجديدة بسرعات مختلفة ولم نختبر أي صيغة يرسلها كل منهم، فاكتب محلّلك ليتحمل الصيغتين. لا تفترض أسماء الحقول؛ استعمل find() مع بديل بدل الوصول المباشر.

من التقرير إلى قرار السياسة

توصي Google بالبدء بـp=none وتحديث السياسة كلما عرفت كيف يصادق المستقبِلون على بريدك. تسلسل مقبول من هناك:

1. اجمع التقارير أسبوعين على الأقل ليظهر المرسلون الشهريون (الفوترة والنشرات).
2. عالج كل مصدر مشروع يفشل بطريقة الجدول أعلاه.
3. انتقل إلى p=quarantine حين لا يتبقى في نسبة الفشل إلا ما تقبل خسارته؛ الحدود هنا تقديرك وليست قاعدة منشورة.
4. واصل قراءة التقارير بعد كل تغيير. ظهور فشل جديد بعد تبديل مزوّد أمر عادي.

يشرح دليل SPF وDKIM وDMARC المحاذاة بتفصيل أكبر، ويتناول دليل حد استعلامات SPF السبب الأشيع لفشل SPF. وإن كنت ترسل عبر عدة مزوّدين فـشرح دمج سجلات SPF ينطبق على الإصلاحات أعلاه.

أخطاء شائعة عند قراءة التقارير

• اعتبار كل IP فاشل مهاجمًا. المُعيدون وقوائم المراسلة قد يكسرون SPF. بل يعرّف RFC 7489 أسباب تجاوز مثل forwarded وmailing_list وtrusted_forwarder ليشرح بها المستقبِل قراره.
• إهمال الأعداد الصغيرة. مصدر بـ12 رسالة قد يكون نظام فواتير شهريًا مهمًا جدًا.
• الخلط بين النتائج الخام والمقيَّمة. اقرأ policy_evaluated أولًا، واستعمل auth_results لتعرف ما تصلحه.
• جعل صندوقك الشخصي عنوان rua. تحذّر Google صراحة من حجم التقارير الكبير.
• التشديد مبكرًا. أسبوع هادئ من التقارير يفوّته مرسلون يرسلون شهريًا أو فصليًا.

📊حاسبة مقاييس البريدنسب التسليم والفتح والنقر والارتداد والشكاوى مع نطاق ثقة 95% وتنبيهات اتساقافتح الأداة →

أسئلة شائعة

ما تقرير DMARC التجميعي؟

ملخص XML يومي يرسله المستقبِلون إلى العنوان في وسم rua. يسرد عناوين IP المرسِلة لنطاقك وأعداد الرسائل ونتائج SPF وDKIM وDMARC. ولا يحتوي نص الرسائل.

لماذا تصلني رسائل تقارير DMARC كثيرة؟

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

ما الفرق بين rua وruf؟

عناوين rua تتلقى الملخصات التجميعية، وعناوين ruf تتلقى تقارير فشل لكل رسالة. التجميعية هي التي يرسلها أغلب المستقبِلين وهي موضوع هذا الدليل.

هل يحتاج نجاح DMARC إلى SPF وDKIM معًا؟

لا. ينجح DMARC حين ينجح أحدهما على الأقل مع المحاذاة لنطاق From. ولا يفشل إلا حين يفشل الاثنان في المحاذاة.

كيف أجد مرسلًا مجهولًا في تقرير DMARC؟

جمّع السجلات حسب source_ip، ثم ابحث عن اسم reverse DNS للعنوان أو مالكه. وانظر في auth_results إلى النطاقات التي وقّعت أو نجح SPF لها؛ فهي كثيرًا ما تدل على المزوّد حتى حين تفشل المحاذاة.

هل ما زال RFC 7489 معيار DMARC؟

تنصّ RFC 9990 وRFC 9989 كل منهما على أنها تنسخ RFC 7489. غير أن المستقبِلين يتبنّون المعايير بسرعات مختلفة، فقد تصل تقارير بالصيغة القديمة.

المراجع ومزيد من القراءة

1. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
2. RFC 9990 — DMARC Aggregate Reporting
3. RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
4. Google Workspace Admin Help — Set up DMARC