تقارير DMARC المجمّعة هي ملفات XML ترسلها لك مزوّدات صناديق البريد، عادةً مرة في اليوم، وتسرد كل مصدر أرسل بريدًا يدّعي أنه من نطاقك وهل نجح في SPF وDKIM والتوافق. قراءتها هي الطريقة التي تجد بها كل مرسل مشروع، وتعالج من يفشل منهم، وتكتشف من ينتحل نطاقك، لتنتقل من p=none إلى p=reject دون حجب البريد الحقيقي.
ابدأ من هنا. يفترض هذا الدليل أنك تنشر سجل DMARC بالفعل. إذا لم تفعل، فاتبع أولًا دليل مصادقة نطاق الإرسال، ثم عد إلى هنا حين تبدأ التقارير بالوصول.
الخلاصة السريعة
- اطلب التقارير. أضف عنوان rua إلى سجل DMARC بينما تكون السياسة p=none.
- انتظر واجمع. اجمع تقارير من أسبوعين إلى أربعة أسابيع، بما فيها أي إرسال شهري.
- صنّف المصادر. حدّد كل عنوان IP مصدر على أنه مشروع ومتوافق، أو مشروع لكنه يفشل، أو مجهول.
- أصلح ما يفشل. امنح كل خدمة مشروعة توقيع DKIM متوافقًا أو Return-Path متوافقًا.
- طبّق على مراحل. ابدأ بـ quarantine بنسبة منخفضة، ثم ارفعها، ثم انتقل إلى reject.
سجل DMARC الذي يطلب التقارير
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"| العلامة | المعنى |
|---|---|
p | السياسة المطبقة على البريد الفاشل: none (مراقبة) أو quarantine أو reject |
rua | وجهة إرسال التقارير المجمّعة، بصورة عنوان mailto: واحد أو أكثر |
adkim, aspf | نمط التوافق: r للمرن (يمكن أن يطابق نطاق فرعي)، s للصارم (تطابق تام) |
sp | سياسة النطاقات الفرعية إذا اختلفت عن p |
pct | النسبة المئوية للبريد الفاشل التي تنطبق عليها السياسة |
استخدم صندوق بريد مخصصًا. التقارير كثيرة وكبيرة. أرسلها إلى عنوان مخصص أو إلى خدمة لمعالجة التقارير، وليس إلى شخص.
إرسال التقارير إلى نطاق آخر
إذا كان عنوان rua على نطاق مختلف عن النطاق الذي يُبلَّغ عنه، فيجب أن ينشر ذلك النطاق الآخر سجلًا يسمح بذلك. وإلا فلن ترسل المزوّدات التقارير. بالنسبة لتقارير تخص example.com وتذهب إلى reports.example.net:
example.com._report._dmarc.reports.example.net. 3600 IN TXT "v=DMARC1"ما بداخل التقرير
تصل التقارير كمرفق، عادةً مضغوط بصيغة gzip أو zip. افتح أحدها وستجد ثلاثة أجزاء: معلومات عن مرسل التقرير، والسياسة التي وجدها المزوّد، وقائمة صفوف، صف لكل مزيج من عنوان IP المصدر والنتيجة.
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<report_id>1234567890</report_id>
<date_range><begin>1759708800</begin><end>1759795199</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain><adkim>r</adkim><aspf>r</aspf><p>none</p><pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>1250</count>
<policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>pass</spf></policy_evaluated>
</row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results>
<dkim><domain>example.com</domain><selector>mail1</selector><result>pass</result></dkim>
<spf><domain>bounce.example.com</domain><result>pass</result></spf>
</auth_results>
</record>
</feedback>| الحقل | ما يخبرك به |
|---|---|
org_name | أي مزوّد صناديق بريد أرسل التقرير |
date_range | الفترة التي يغطيها التقرير، بصيغة طوابع زمنية Unix |
policy_published | سياسة DMARC التي رآها المزوّد، لتتأكد من أن سجلك فعّال |
source_ip وcount | الخادم المرسل وعدد الرسائل التي أرسلها في الفترة |
policy_evaluated | النتيجة المعتبرة في DMARC: تعني dkim وspf هنا النجاح أو الفشل مع التوافق |
auth_results | نتائج SPF وDKIM الخام والنطاقات التي تمت مصادقتها، وقد تختلف عن نطاق From |
header_from | النطاق في عنوان From الظاهر |
نتيجتان مختلفتان. داخل policy_evaluated، تعني pass أن الفحص نجح وأنه متوافق. أما داخل auth_results، فتعني pass أن الفحص نجح للنطاق الذي استخدمه فقط، أيًا كان. قد ينجح مصدر في auth_results ويفشل في policy_evaluated. هذه الفجوة هي مشكلة توافق.
صنّف كل مصدر في إحدى المجموعات الثلاث
| المجموعة | ما تراه | ما عليك فعله |
|---|---|---|
| مشروع ومتوافق | خدمة معروفة، DKIM أو SPF متوافق في policy_evaluated | لا شيء. أبقِ الوضع كما هو |
| مشروع لكنه يفشل | خدمة معروفة تنجح نتائج auth_results لديها بينما تفشل policy_evaluated | أعدّ DKIM متوافقًا أو Return-Path مخصصًا لتلك الخدمة |
| مجهول | عنوان IP لا تعرفه، وغالبًا مع إخفاقات كثيرة | حقّق: قد يكون نظامًا منسيًا أو جهة إعادة توجيه أو منتحلًا. لا تصرّح به حتى تعرف حقيقته |
كيف تحدد هوية مصدر
- DNS العكسي: غالبًا ما يسمّي الأمر
dig -x 203.0.113.10 +shortالمزوّد. - نطاقات المصادقة: عادةً ما تكشف نطاقات SPF وDKIM في auth_results الخدمة.
- قائمة الجرد لديك: أدرج كل أداة ترسل باسم نطاقك: منصة التسويق، ومكتب الدعم، وCRM، ونظام الفوترة، ونماذج الموقع، وأدوات الموارد البشرية، والخوادم.
- الحجم والنمط: العدد الصغير المنتظم من خدمة معروفة أمر طبيعي؛ أما الدفعة المفاجئة من عنوان IP مجهول فمريبة.
لخّص التقارير بسكربت قصير
للنظرة الأولى على مجلد من التقارير بعد فك ضغطها، يجمع هذا السكربت عدد الرسائل بحسب عنوان IP المصدر ونتيجة DMARC:
import glob
import xml.etree.ElementTree as ET
from collections import defaultdict
totals = defaultdict(int)
for path in glob.glob("reports/*.xml"):
for rec in ET.parse(path).getroot().iter("record"):
row = rec.find("row")
ip = row.findtext("source_ip")
ev = row.find("policy_evaluated")
key = (ip, ev.findtext("dkim"), ev.findtext("spf"))
totals[key] += int(row.findtext("count"))
for (ip, dkim, spf), n in sorted(totals.items(), key=lambda x: -x[1]):
print(f"{ip:18} dkim={dkim:5} spf={spf:5} messages={n}")معالجة إخفاقات التوافق
| النمط في التقرير | السبب | الحل |
|---|---|---|
| ينجح SPF ويفشل DMARC | صادق SPF على نطاق المزوّد وليس نطاقك | استخدم Return-Path مخصصًا على نطاقك |
| ينجح DKIM ويفشل DMARC | يستخدم التوقيع نطاق المزوّد في d= | وقّع بنطاقك: انشر محدد DKIM لتلك الخدمة |
| يفشل الاثنان لخدمة معروفة | الخدمة غير معدّة لنطاقك | أكمل مصادقة النطاق فيها |
| يفشل عبر جهة إعادة توجيه فقط | كسر إعادة التوجيه SPF، وعُدّل DKIM | توقع ذيلًا صغيرًا. تأكد من وجود DKIM وأنه يوقّع المحتوى |
| يفشل لنطاق فرعي | ليس للنطاق الفرعي سجلات خاصة به | انشر SPF وDKIM لذلك النطاق الفرعي |
انتقل إلى التطبيق على مراحل
عندما تتوافق المصادر المشروعة ولا يفشل سوى المصادر المجهولة، ارفع السياسة تدريجيًا. انتظر أسبوعًا على الأقل عند كل مرحلة واقرأ التقارير قبل الانتقال.
| المرحلة | السجل | ما يفعله |
|---|---|---|
| 1 | p=none | مراقبة فقط. اجمع التقارير |
| 2 | p=quarantine; pct=10 | البريد الفاشل من 10 بالمئة من الرسائل يذهب إلى البريد المزعج |
| 3 | p=quarantine; pct=50 | يُحجر نصف البريد الفاشل |
| 4 | p=quarantine | يُحجر كل البريد الفاشل |
| 5 | p=reject; pct=25 | يُرفض ربع البريد الفاشل |
| 6 | p=reject | يُرفض كل البريد الفاشل. أبقِ عنوان rua |
لا تتوقف عند p=none. فهو يلبّي الحد الأدنى من قواعد Gmail وYahoo وOutlook.com للمرسلين بكميات كبيرة، لكنه لا يوقف الانتحال. التطبيق هو ما يحمي نطاقك ومستلميك.
واصل المراقبة بعد p=reject
- راجع أسبوعيًا في البداية، ثم شهريًا. ستظهر الأدوات الجديدة التي ترسل باسم نطاقك على هيئة إخفاقات.
- أضف خطوة إلى عملية الإعداد: أي نظام جديد يرسل بريدًا باسم نطاقك تتم مصادقته قبل تشغيله.
- احمِ النطاقات المركونة: انشر p=reject وسجل SPF فارغًا على النطاقات التي لا ترسل منها.
- راقب جاهزية BIMI: سياسة DMARC المُطبّقة شرط مسبق إذا أردت لاحقًا أن يظهر شعارك في صندوق الوارد.
تريد رأيًا ثانيًا في تقاريرك؟ أرسل لنا تقريرًا نموذجيًا وقائمة الخدمات التي ترسل باسم نطاقك وسنساعدك في تحديد ما يجب إصلاحه.
قراءات إضافية ومصادر
الأسئلة الشائعة
ما هو تقرير DMARC المجمّع؟
هو ملف XML، عادةً مضغوط، يرسله مزوّد صناديق البريد إلى عنوان rua في سجل DMARC لديك، وعادةً مرة في اليوم. يلخّص البريد الذي رآه المزوّد وادّعى أنه من نطاقك: عنوان IP المرسل، وعدد الرسائل، وهل نجح SPF وDKIM وDMARC. ولا يحتوي على أي محتوى للرسائل.
لماذا لا أتلقى تقارير DMARC؟
تحقق من أن عنوان rua صحيح ومكتوب بالبادئة mailto:، وأن صندوق البريد يقبل المرفقات الكبيرة، وأنك انتظرت يومًا على الأقل. وإذا كان عنوان التقارير على نطاق مختلف، فيجب أن ينشر ذلك النطاق سجل تفويض. لا يرسل كل مزوّد تقارير، وقد تتلقى النطاقات الصغيرة عددًا قليلًا منها.
ما الفرق بين rua وruf؟
تطلب العلامة rua التقارير المجمّعة، وهي ملخصات. أما العلامة ruf فتطلب تقارير جنائية أو تقارير إخفاق عن رسائل فاشلة بعينها. لا يرسل معظم المزوّدين الكبار تقارير جنائية لأنها قد تحتوي على بيانات شخصية، لذا اعتمد في خطتك على التقارير المجمّعة.
هل يمكنني قراءة تقارير DMARC بدون أداة؟
نعم إذا كان عدد الملفات قليلًا، لأنها XML نصي عادي. وفيما عدا ذلك، استخدم خدمة لمعالجة التقارير أو سكربتًا قصيرًا لجمع النتائج بحسب المصدر، لأن حتى النطاق المتواضع يتلقى عشرات التقارير يوميًا.
ماذا يعني إخفاق التوافق؟
ينجح DMARC فقط عندما ينجح SPF أو DKIM ويطابق النطاق الذي تمت مصادقته نطاق From الظاهر. فإذا نجح مصدر في SPF لنطاق مزوّد الخدمة بينما نطاق From لديك مختلف، يفشل DMARC رغم نجاح SPF. والحل هو المصادقة بنطاقك الخاص، باستخدام Return-Path مخصص أو توقيع DKIM بنطاقك.
كم ينبغي أن أبقى على p=none؟
لمدة كافية لرؤية كل مرسل مشروع، وهي عادةً من أسبوعين إلى أربعة أسابيع، وينبغي أن تشمل دورة نهاية الشهر إذا كنت ترسل بريدًا شهريًا مثل الفواتير. البقاء على p=none إلى الأبد لا يحمي شيئًا، فحدّد موعدًا للانتقال.
ماذا تفعل العلامة pct؟
تطبّق العلامة pct سياستك على نسبة مئوية فقط من الرسائل الفاشلة، مثل pct=25. وتتيح لك طرح quarantine أو reject تدريجيًا. الدعم شائع لكنه ليس شاملًا، لذا تعامل معها كأداة تحكم ليّنة واستمر في مراقبة التقارير.
هل سيعطّل p=reject بريدي الإلكتروني؟
سيحجب أي رسالة تفشل في DMARC، وهذا هو المقصود. ولا يتعطل البريد المشروع إلا إذا كان هناك مرسل حقيقي غير مصادَق عليه أو غير متوافق. ولهذا تجمع التقارير أولًا، وتعالج كل مصدر مشروع، وتنتقل على مراحل.
وماذا عن البريد المُعاد توجيهه والقوائم البريدية؟
غالبًا ما يكسر إعادة التوجيه SPF لأن الجهة المعيدة للتوجيه ليست في سجلك، وقد تعدّل القوائم الرسالة فيتعطل DKIM. ويساعد المستقبلين على اتخاذ القرار بقاء توقيع DKIM سليمًا وترويسات ARC التي تضيفها الجهة المعيدة للتوجيه. توقع ذيلًا صغيرًا من الإخفاقات بسبب إعادة التوجيه حتى في الإعداد السليم.
هل تحتاج النطاقات الفرعية إلى سجل DMARC خاص بها؟
يغطي سجل DMARC في نطاقك الرئيسي النطاقات الفرعية أيضًا ما لم تتجاوزه. تحدد العلامة sp سياسة للنطاقات الفرعية، ويتجاوز السجل الموجود على نطاق فرعي كليهما. النطاقات الفرعية غير المستخدمة هدف للانتحال، لذا فإن سياسة صارمة لها مكسب سريع.