تعرض تقارير DMARC حركة البريد التي رصدها المستقبلون المشاركون باسم نطاقك، وتوافق SPF وDKIM والمعاملة المبلغ عنها. قد تساعد على كشف دلائل الانتحال وأخطاء إعداد المزودين والتحضير لتشديد السياسة. لكنها لا تحصر تلقائيا كل بريدك أو جميع المرسلين.
تنشر فرق كثيرة سجل DMARC وتوجه rua= إلى صندوق ثم تهمل البيانات. تتراكم ملفات XML وتبقى الأخطاء ودلائل الإساءة دون متابعة. لإعداد الأساس اقرأ بريد الأعمال للشركات الصغيرة وإنشاء بريد بنطاقك. ثم استخدم التقارير مع قائمة أنظمتك وسجلاتها لبناء قائمة مصادر الإرسال.
اجمع التقارير وحدد المصادر الشرعية وأصلح التوافق. لا تتجاهل إخفاقات SPF في التوجيه لمجرد نجاح DKIM؛ تحقق من بقاء التوقيع صالحا ومتوافقا. وبعدها قيم تشديد السياسة بالبيانات والاختبارات.
ما هي تقارير DMARC؟
تقارير DMARC رسائل تغذية راجعة من مستقبلين مشاركين بعد تقييم بريد يستخدم نطاقك في From. تعرض المصادقة والتوافق وعناوين الإرسال وإجراءات السياسة، وتفيد في التحقيق الأمني ومشكلات الاستقبال. لا توفر تغطية كاملة.
توجد أنواع مختلفة من التقارير.
التقارير التجميعية تطلب بوسم rua وتصل عادة كملخصات XML. تجمع الحركة بحسب المستقبل وعنوان الإرسال ونتيجة المصادقة والمعاملة. تستخدمها لفحص Google Workspace أو Microsoft 365 أو SendGrid أو Mailchimp أو خادم تطبيقك أو VPS مجهول. لا يثبت عنوان IP وحده هوية الجهة الفعلية.
تقارير الإخفاق تطلب بوسم ruf وقد تحتوي تفاصيل رسالة بعينها. تعتمد دوافع إرسالها على شروط التقرير، ولا تقتصر بالضرورة على فشل DMARC الكامل. الدعم محدود، وقد يرسل مستقبلون كثيرون القليل أو لا شيء لأسباب الخصوصية. اجعل التجميع أساس العمل والإخفاقات معلومات إضافية.
تساعد التقارير عمليا في هذه الأسئلة:
- ما المصادر التي يراها المستقبلون المشاركون باسم نطاقي؟
- هل ينجح SPF أو DKIM مع التوافق المطلوب؟
- هل يبلغ المستقبلون عن quarantine أو reject؟
- ما المخاطر التي ينبغي فحصها قبل تطبيق
p=quarantineأوp=reject؟
كيف تعمل تقارير DMARC؟
يحدد سجل DMARC مكان التغذية الراجعة. انشر TXT عند _dmarc.yourdomain.com واختر سياسة وأضف عناوين التقارير. يمكن للمستقبلين المشاركين إرسال البيانات. قد تتطلب وجهة تقارير في نطاق خارجي تفويضا إضافيا عبر DNS.
مثال لسجل مراقبة:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"يطلب هذا المثال المراقبة دون قيود DMARC وإرسال التجميع إلى dmarc@example.com. يفرض adkim=s وaspf=s تطابق النطاق تماما، وهما اختياريان وليسا أفضل إعداد لكل بيئة. يسمح التوافق المرن الافتراضي عادة بالنطاق التنظيمي نفسه. افحص أثر الاختيار في مرسليك.
الوسوم المهمة:
v=DMARC1: وسم الإصدار الإلزامي.p=: المعاملة المطلوبة عند فشل DMARC.rua=: وجهة التقارير التجميعية.ruf=: وجهة تقارير الإخفاق.pct=: النسبة المطلوبة من البريد الفاشل في DMARC لتطبيق القيود، مع اختلاف الدعم.adkimوaspf: وضعا توافق DKIM وSPF.
يحدد RFC 7489 صيغة التقارير ومنطق السياسة. لذلك تصل التقارير الخام غالبا كمرفقات XML مضغوطة تحتاج إلى تحليل.
ماذا تحتوي التقارير التجميعية؟
تلخص التجميعات الحركة المبلغ عنها بحسب الجهة وعنوان الإرسال وعدد الرسائل وSPF وDKIM والمعاملة. ميز نتائج المصادقة الخام عن تقييم سياسة DMARC الذي يتضمن التوافق. نجاح المصادقة وحده لا يعني نجاح التوافق.
تجد عادة:
- المستقبل المبلغ، مثل Google أو Microsoft.
- الفترة المشمولة.
- عنوان IP الذي سلم البريد إلى ذلك المستقبل.
- عدد الرسائل المرصودة من المصدر.
- نتيجة مصادقة SPF الخام.
- نتيجة مصادقة DKIM الخام.
- تقييم SPF مع توافقه مع From.
- تقييم DKIM مع توافقه مع From.
- معاملة DMARC المبلغ عنها: none أو quarantine أو reject.
ليس كل إخفاق SPF خطأ في المرسل الأصلي. تغير إعادة التوجيه عنوان الإرسال غالبا. إذا بقي DKIM صالحا ومتوافقا، فقد ينجح DMARC.
المستقبل: gmail.com
عنوان الإرسال: 198.51.100.24
العدد: 842
نطاق From: example.com
SPF: fail
DKIM: pass
DMARC: pass
المعاملة: none
قد يناسب هذا توجيها سليما حافظ على توافق DKIM. تحقق من المصدر والتوقيع؛ نجاح المصادقة لا يثبت سلامة المحتوى أو اعتماد المرسل لأغراض العمل.
المستقبل: outlook.com
عنوان الإرسال: 203.0.113.77
العدد: 314
نطاق From: example.com
SPF: fail
DKIM: fail
DMARC: fail
المعاملة: quarantine
تحتاج هذه الحالة إلى تحقيق. قد يكون السبب مرسلا مضبوطا خطأ أو مزودا جديدا لم يكمل المصادقة أو إساءة استخدام أو تغييرا أثناء النقل. لا يثبت التقرير وحده الانتحال.
التقارير التجميعية مقابل تقارير الإخفاق
تعرض التجميعات حركة المستقبلين المشاركين، وقد تعرض تقارير الإخفاق أحداثا فردية. التجميع أساس لكثير من النطاقات، لكنه لا يضمن قائمة مكتملة أو تغييرا آمنا للسياسة.
| نوع التقرير | يطلب بواسطة | المحتوى | الاستخدام | الواقع في 2025-2026 |
|---|---|---|---|---|
| تجميعي | rua=mailto:... | ملخصات XML يومية غالبا حسب المصدر والمصادقة والمعاملة | حصر المصادر وتصحيح التوافق والتحضير للسياسة | مصدر بيانات مهم دون تغطية كاملة |
| إخفاق / جنائي | ruf=mailto:... | تفاصيل رسالة، قد تكون جزئية أو محجوبة | فحص إخفاقات أو إساءة محددة | دعم محدود، وقد لا يرسل كبار المستقبلين شيئا |
تكون لوحة التقارير مفيدة حين يشرح مزودها هذه الفروق وتساعدك البيانات على تعديل الإعدادات، لا لمجرد عرض الرسوم.
قراءة تقارير DMARC بكفاءة
ابدأ بالمصادر الأعلى حركة واربطها بأنظمة العمل وأصلح الإخفاقات الشرعية. ثم افحص المصادر النادرة المهمة أيضا. الحجم ليس المقياس الوحيد للأولوية.
اتبع هذا المسار:
- ابدأ بمصادر الرسائل الأكثر في التقارير التجميعية.
- اربط كل مصدر بـ Google Workspace أو Microsoft 365 أو التسويق أو التطبيق أو الدعم أو نظام مجهول.
- تحقق من نجاح SPF أو DKIM وتوافقه مع نطاق From الظاهر.
- أصلح الإخفاقات الشرعية قبل تشديد السياسة.
- ضع المصادر المجهولة قيد التحقيق. قد يفسر خادم مشترك أو وسيط توجيه حركة شرعية أيضا.
لا تنشغل بالإخفاقات الصغيرة وحدها بينما المرسلون الرئيسيون مضبوطون خطأ. رتب العمل بحسب الحجم والأهمية التشغيلية.
| النتيجة المبلغ عنها | سبب محتمل | الإجراء |
|---|---|---|
| SPF pass, DKIM pass, DMARC pass | المصادقة والتوافق يبدوان عاملين | وثق المصدر وتحقق من شرعيته بصورة مستقلة |
| SPF fail, DKIM pass, DMARC pass | توجيه أو مشكلة في مسار SPF | افحص المسار وبقاء DKIM المتوافق صالحا |
| SPF pass, DKIM fail, DMARC pass | مشكلة DKIM مع نجاح SPF المتوافق | افحص DKIM، خصوصا لمسارات التوجيه |
| SPF fail, DKIM fail, DMARC fail | إساءة أو إعداد خاطئ أو تغييرات في النقل | حقق في المصدر ومعالجة الرسالة |
| عنوان IP مجهول بحركة فعلية | مزود غير مسجل أو خادم مشترك أو توجيه أو إساءة | حدد المصدر أولا، ولا تحظره اعتمادا على التقرير وحده |
من الإصلاحات المعتادة:
- إضافة تضمين SPF الصحيح لمرسل شرعي مؤكد ضمن حدود SPF.
- تفعيل توقيع DKIM للنطاق لدى المزود.
- إعداد return-path مخصص يحقق توافق SPF.
- نقل إرسال المزود إلى نطاق فرعي إذا ناسب سياسة النطاق.
- إصلاح إعادة التوجيه بدلا من الاعتماد على SPF وحده.
يساعد سطر الأوامر على فحص إجابات DNS الحالية، لكنها ليست بالضرورة كل الإجابات المخبأة التي استخدمها المستقبلون:
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +shortلإعداد DNS راجع وثائق TrekMail حول سجلات DNS المطلوبة والبريد الذي يصل إلى المزعج.
مشكلات قد تكشفها التقارير
تساعد التقارير على كشف مصادقة مزود ناقصة وأخطاء توافق ومشكلات توجيه وسياسة لا تراجع. أكملها بقائمة الإرسال الداخلية والسجلات.
قد تبدأ أداة جديدة بالإرسال باسم نطاقك قبل اكتمال SPF أو DKIM. عنوان مجهول في التقرير دليل لبدء التحقيق، لا إثبات قاطع لهذه الحالة.
قد ينجح SPF لنطاق المغلف ويفشل DMARC إذا لم يتوافق مع From ولم ينجح DKIM متوافق أيضا. قد يظهر ذلك في التسويق والتذاكر دون إعداد نطاق ارتداد مناسب.
الاعتماد على SPF وحده ضعيف في التوجيه. إذا غاب DKIM الصالح المتوافق فقد يفشل DMARC في المسار. اقرأ إعداد إعادة التوجيه وإصلاحها واختبرها منفصلة عن الإرسال المباشر.
مشكلة أخرى هي نشر p=none وجمع التقارير دون تحليل. بذلك تفوت فرصة متابعة الأخطاء ودلائل الإساءة.
والتسرع إلى p=reject خطر أيضا. احصر المصادر الشرعية واختبر التدفقات المهمة والنادرة قبل التشديد. لا تثبت التقارير وحدها أمان الانتقال.
دور TrekMail
تفيد التقارير إذا استطعت العمل بنتائجها. قد يجمع TrekMail إدارة النطاق وفحوص DNS والإرسال لتقليل العمل اليدوي، لكن عليك متابعة المصادر الخارجية أيضا.
في الإدارة المتفرقة، تكون النطاقات لدى مضيفين مختلفين وSMTP منفصلا والتقارير في صندوق مشترك. قد يغيب مصدر جديد عن القائمة بسهولة.
في المسار المترابط، تستخدم لوحة TrekMail وتعليمات DNS والمصادقة المتاحة وتختار SMTP خاصا أو مدارا. يمكن إدارة الصناديق والتوجيه والترحيل في البيئة نفسها. لعملاء متعددين اقرأ استضافة البريد لنطاقات متعددة.
يوفر TrekMail، بحسب الخطة، نطاقات مخصصة وصناديق IMAP واستقبالا شاملا وتوجيها وترحيل IMAP وAPI. تستخدم Nano SMTP خاصا بك وفق دليل SMTP المخصص. يمكن للخطط المدفوعة استخدام SMTP المدار. يبدأ Starter في الأسعار المذكورة هنا من $3.50 شهريا، وتوصف Nano كمجانية دون بطاقة. وقد تتاح فترة تجريبية مجانية للخطط المدفوعة لمدة 14 يوما تتطلب بطاقة ائتمان. تحقق من الأسعار والشروط الحالية.
لا تصلح التقارير شيئا بنفسها. تقدم دلائل للفحص، وقد تجعل البيئة الموحدة تنفيذ التصحيحات أسهل.
الانتقال من p=none إلى quarantine أو reject
قد تساعد التقارير على تقييم نجاح المصادقة المتوافقة للمرسلين الشرعيين. أضف حصر المصادر واختبارات التدفقات النادرة وخطة استعادة قبل التطبيق. لا تفترض أن الإخفاقات المتبقية كلها خبيثة أو غير مهمة.
السجلات التالية بدائل متتابعة لمسار محتمل. انشر سجل سياسة واحدا فقط في كل مرحلة:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"لا تضمن النسبة تقسيما دقيقا للتدفق، فهي تخص البريد الفاشل في DMARC ويختلف تطبيقها بين المستقبلين. راجع دورات تقرير مناسبة، وتحقق من المصادر الحرجة والنادرة، واختبر بقاء DKIM صالحا ومتوافقا أثناء التوجيه. قد يتجاوز المستقبل السياسة المطلوبة.
تطلب Google SPF أو DKIM من المرسلين عموما إلى Gmail، وكليهما مع DMARC والتوافق المطبق من مرسلي البريد الجماعي. راجع الشروط في الأسئلة الشائعة حول إرشادات مرسلي Gmail.
الخلاصة: اجعل التقارير جزءا من التشغيل
تقدم تقارير DMARC معلومات مفيدة لكنها جزئية عن المصادر والمصادقة والمعاملة. حللها دوريا مع قائمة الإرسال والسجلات كي تفحص الأخطاء بدلا من تخزينها فقط.
قد يساعد تبسيط الإدارة حين تتعدد النطاقات والمزودون. يقدم TrekMail بحسب الخطة استضافة متعددة النطاقات وتخزينا مشتركا وترحيل IMAP وSMTP خاصا أو مدارا وفحوص مصادقة. تحقق من الميزات والتسعير الحالي في أسعار TrekMail. تدعم هذه الأدوات التحقيق ولا تضمن أمان التطبيق أو الوصول إلى الوارد.
