فاحص سجل DMARC

بمساعدة الخادم جديد DNS والنطاقات

يقرأ الفاحص سجل TXT عند الاسم ‎_dmarc الذي يسبق النطاق (مثل ‎_dmarc.example.com)؛ وإن لم يكن للنطاق الفرعي سجل صعد إلى النطاقات الأم حتى سجل النطاق التنظيمي، وبيّن هل تنطبق سياسة p= أم sp=. يُعرض كل وسم يعرّفه RFC 9989 ‏(p وsp وnp وadkim وaspf وt وpsd وrua وruf وfo) بقيمته أو بقيمته الافتراضية، ومعها وسوم RFC 7489 ‏pct وrf وri إن وردت في السجل، وتُشرح الأخطاء والإعدادات الضعيفة. أما السجل الذي تلصقه فيُفحص في متصفحك قبل نشره.

الخصوصية: يُرسَل الاسم الذي تبحث عنه من خادم متقن إلى محلّلات DNS العامة المذكورة في النتائج. ولا يُخزَّن أي شيء.

ما هو سجل DMARC؟

سجل DMARC ‏(RFC 9989، الذي حلّ محل RFC 7489 في مايو 2026) سجل TXT عند الاسم ‎_dmarc الذي يسبق النطاق (‎_dmarc.example.com) يخبر الخوادم المستقبِلة بما تفعله مع البريد الذي لا يُثبَت نطاقه في ترويسة From بنجاح متوافق في SPF أو DKIM — لا شيء (p=none) أو العزل (quarantine) أو الرفض (reject) — وإلى أين ترسل التقارير. والنطاق الفرعي الذي ليس له سجل خاص يخضع لسجل النطاق التنظيمي، عبر سياسة sp= إن وُجدت.

ملاحظة أمنية: من دون سياسة DMARC إلزامية (quarantine أو reject) لا يُطلب من الخوادم التي تطبّق DMARC إيقاف البريد الذي يضع نطاقك بعينه في عنوان From ويفشل في توافق SPF وDKIM. وحتى p=reject لا تشمل النطاقات المشابهة في الشكل ولا اسم العرض الذي يظهر بجانب العنوان.

كيفية استخدام فاحص سجل DMARC

  1. اكتب نطاق عنوان From أو أحد نطاقاته الفرعية؛ ويصلح أيضاً ‎_dmarc.example.com أو عنوان بريد كامل.
  2. اضغط «فحص DMARC». يقرأ خادم متقن ‎_dmarc عند ذلك الاسم، فإن لم يجد سجلاً قرأه عند النطاقات الأم.
  3. اقرأ السياسة المطبَّقة وموضع السجل، وللنطاق الفرعي انظر هل تحسم الأمرَ sp= أم p=.
  4. راجع جدول الوسوم وعناوين التقارير والأخطاء والتنبيهات، ثم اتبع الخطوات التالية.
  5. لتجربة سجل قبل نشره، الصقه في الحقل الثاني؛ فيُحلَّل في متصفحك.

مزايا فاحص سجل DMARC

  • السياسة التي تنطبق فعلاً على الاسم الذي تُدخله: سجل النطاق نفسه، أو للنطاق الفرعي الذي ليس له سجل، سياسة sp= أو p= في سجل النطاق التنظيمي
  • عرض مسار البحث اسماً اسماً: ‎_dmarc عند النطاق، ثم عند كل نطاق أم حتى العثور على سجل
  • كل وسم في RFC 9989 مع معناه وقيمته — ومنها np وpsd وt — والقيمة الافتراضية لكل وسم لم يُكتب في السجل، ووسوم RFC 7489 ‏pct وrf وri إن كان السجل لا يزال يستخدمها
  • فحص عناوين التقارير الموجودة في نطاق تنظيمي آخر بحثاً عن سجل التفويض الذي يجب أن ينشره ذلك النطاق قبل أن تُرسَل إليه التقارير
  • شرح الإعدادات الضعيفة: p=none، ووضع الاختبار (t=y)، وpct أقل من 100، وغياب عنوان rua=، وsp= أضعف من p=، ووجود سجلَّي DMARC عند الاسم نفسه
  • فحص مسوّدة سجل تلصقها في الحقل الثاني داخل متصفحك قبل نشرها
  • خطوات تالية بلغة واضحة، من أول سجل p=none حتى سياسة p=reject مطبَّقة

المدخلات والمخرجات

المدخلات

  • اسم النطاق — نطاق أو نطاق فرعي، يُكتب اسماً أو عنوان بريد أو اسم ‎_dmarc مثل ‎_dmarc.example.com؛ وتُقبل أسماء النطاقات الدولية.
  • سجل DMARC ملصوق (اختياري) — سجل واحد يبدأ بـ v=DMARC1، مجرّداً أو بين علامتَي تنصيص. عند تعبئته يُفحص في متصفحك ولا يُجرى أي استعلام، والنطاق إن كُتب معه يفيد فقط في تمييز عناوين التقارير الداخلية من الخارجية.

المخرجات

  • الملخص — السياسة المطبَّقة، وموضع السجل، وقيمة pct= إن ضبطها السجل، ووضع الاختبار إن كان t=y، وعدد عناوين التقارير المجمَّعة.
  • السجل — الاسم المفحوص والسجل الموجود، وللنطاق الفرعي الوسم (sp= أو p=) الذي تنطبق السياسة من خلاله.
  • الأسماء المفحوصة — كل اسم ‎_dmarc سأل عنه البحث، مع «لا يوجد سجل» أو «عدة سجلات، استُبعدت كلها» أو «عُثر على سجل».
  • وسوم السجل — كل وسم في RFC 9989 مع معناه وقيمته، والقيم الافتراضية مميَّزة، ومعها pct وrf وri إن استخدمها السجل.
  • عناوين التقارير — كل عنوان rua= وruf= مع بيان هل يلزمه تفويض وهل وُجد.
  • الأخطاء والتنبيهات وما الخطوة التالية — كل ملاحظة بلغة واضحة، والخطوات التي تترتب على النتيجة.

مثال على فاحص سجل DMARC

نطاق فرعي يرث سياسته (docs.github.com، أكتوبر 2026)

الإدخال:

docs.github.com

النتيجة:

السياسة المطبَّقة: reject (يُرفض البريد الذي يفشل) · موضع السجل: _dmarc.github.com (النطاق التنظيمي) · النسبة (pct): 100 · عناوين التقارير المجمَّعة: 1
الأسماء المفحوصة: _dmarc.docs.github.com — لا يوجد سجل · _dmarc.github.com — عُثر على سجل (النطاق التنظيمي)
السجل: v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1
تنطبق على هذا النطاق الفرعي عبر: sp=reject

كيف تقرأ نتائج فاحص سجل DMARC

reject: السياسة الإلزامية — يُطلب من الخوادم التي تطبّق DMARC رفض البريد الذي يفشل في التوافق لهذا النطاق بعينه. ولا تشمل النطاقات المشابهة في الشكل ولا اسم العرض الذي يظهر بجانب العنوان.

quarantine: يذهب البريد الفاشل إلى الرسائل المزعجة أو يُحتجز؛ فيقلّ ظهور البريد المزوّر لكنه يُسلَّم في مكان ما.

none: السياسة تجمع التقارير فقط، ويُسلَّم البريد الفاشل كالمعتاد، فلا يُطلب من الخوادم بعدُ إيقاف البريد الذي ينتحل النطاق.

«لا يوجد سجل DMARC»: لا ينشر الاسم ولا نطاقاته الأم أي سجل، فتقرر الخوادم المستقبِلة بنفسها ما تفعله بالبريد الفاشل.

«سجل غير صالح»: تتجاهله الخوادم — غالباً لأنه لا يبدأ بـ v=DMARC1، أو لوجود أكثر من سجل DMARC عند الاسم نفسه دون سجل صالح عند نطاق أم (فتُستبعد كلها، RFC 9989 §4.10)، أو لأن p= مفقود أو مكتوب خطأً ولا يوجد عنوان rua= صالح. فإن وُجد rua= صالح عاملت الخوادم السجلّ كأنه p=none بدلاً من ذلك، وكذلك إذا كان sp= أو np= غير صالح (RFC 9989 §4.10.1).

متى تستخدم فاحص سجل DMARC

  • بدء تطبيق DMARC والتأكد من نشر أول سجل p=none مع عنوان rua= نشراً صحيحاً.
  • الانتقال من none إلى quarantine أو reject والتأكد من أن التعديل أصبح فعّالاً.
  • معرفة السياسة التي تحمي نطاقاً فرعياً ليس له سجل خاص به.
  • التأكد من أن التقارير المرسلة إلى خدمة تقارير DMARC مفوَّضة فتصل فعلاً.

استكشاف الأخطاء وإصلاحها

  • «لا يوجد سجل DMARC» رغم أنك أنشأته: يجب أن يكون السجل من نوع TXT عند ‎_dmarc الذي يسبق النطاق (‎_dmarc.example.com) لا عند النطاق نفسه. وكثير من لوحات DNS تضيف النطاق تلقائياً، فاكتب ‎_dmarc وحده اسماً للسجل.
  • «أكثر من سجل DMARC عند هذا الاسم»: حين يبدأ سجلّان بـ v=DMARC1 تستبعدهما الخوادم معاً وتتابع البحث عند النطاقات الأم (RFC 9989 §4.10)، فيخضع الاسم لسياسة نطاق أم أو لا تنطبق عليه أي سياسة. احذف أحدهما واحتفظ في الآخر بالوسوم التي تحتاجها.
  • عنوان تقارير بلا سجل تفويض: يجب أن ينشر نطاق خدمة التقارير الاسم your-domain._report._dmarc.their-domain، ومعظم خدمات تقارير DMARC تفعل ذلك حين تضيف نطاقك إلى حسابك لديها.
  • لا تصل التقارير رغم ضبط rua=: تحقق من كتابة العنوان (يجب أن يبدأ بـ mailto:)، ومن تفويض النطاق الخارجي، ومن أن صندوق البريد يقبل مرفقات XML المضغوطة.
  • رسالة حدّ الطلبات: يكلّف فحص DMARC حتى خمسة استعلامات DNS وواحداً لكل نطاق تقارير يُفحص، من حصة مشتركة مع أدوات DNS الأخرى؛ انتظر الثواني المعروضة.

الأسئلة الشائعة حول فاحص سجل DMARC

بأي سياسة DMARC أبدأ؟

ابدأ بـ p=none مع عنوان rua=، واقرأ التقارير المجمَّعة بضعة أسابيع حتى تتأكد أن كل خدمة ترسل البريد باسمك تنجح في SPF أو DKIM مع التوافق، ثم انتقل إلى p=quarantine وأخيراً p=reject. القفز مباشرة إلى reject قد يرفض بريداً مشروعاً من مرسِل نسيته.

هل يحتاج النطاق الفرعي إلى سجل DMARC خاص به؟

لا. إن لم يكن للنطاق الفرعي سجل خاص به (لا شيء عند ‎_dmarc.mail.example.com مثلاً) تستخدم الخوادم المستقبِلة سجل النطاق التنظيمي: سياسة sp= فيه إن وُجدت، وإلا سياسة p=. ويصعد الفاحص بالطريقة نفسها ويبيّن أي سجل وأي وسم ينطبقان. لا تنشئ سجلاً للنطاق الفرعي إلا إذا احتاج سياسة مختلفة.

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

يستقبل rua= التقارير المجمَّعة: ملخصات XML يومية تبيّن أي الخوادم أرسلت بريداً باسمك وهل نجح. أما ruf= فيطلب تقارير فشل عن رسائل بعينها، وقلّة من الخوادم الكبيرة ترسلها. والعنوان الموجود في نطاق تنظيمي آخر لا تصله التقارير إلا إذا فوّضه ذلك النطاق: تقارير example.com المرسلة إلى عنوان في reports.example.net تحتاج سجلاً عند example.com._report._dmarc.reports.example.net ‏(RFC 9990 §4).

ماذا يفعل الوسمان pct= وt=؟

الوسم pct= من RFC 7489: كان يطبّق السياسة على تلك النسبة من البريد الفاشل ويعامل الباقي بدرجة أخف (quarantine تصبح none، وreject تصبح quarantine). وقد حذفه RFC 9989، الذي حلّ محل RFC 7489 في مايو 2026، وأضاف t=y، وهو وضع اختبار تطبّق فيه الخوادم السياسة بدرجة أخف على كل البريد الفاشل. والخوادم التي تتبع RFC 9989 تتجاهل pct=، فاحذف t=y وpct= حين ينتهي التطبيق التدريجي.

لماذا يظهر سجل DMARC لديّ غير صالح؟

الأسباب المعتادة: سجل لا يبدأ بـ v=DMARC1، أو وسم p= مفقود أو مكتوب خطأً في سجل بلا عنوان rua= صالح (فإن وُجد عاملت الخوادم السجلّ كأنه p=none)، أو سجلّا TXT يبدآن بـ v=DMARC1 عند الاسم نفسه دون سجل صالح عند نطاق أم (فتستبعدهما الخوادم معاً، RFC 9989 §4.10)، أو سجل منشور عند النطاق نفسه بدلاً من ‎_dmarc (عند example.com بدلاً من ‎_dmarc.example.com).

ملاحظات تقنية

يربط DMARC ‏(RFC 9989، الذي حلّ محل RFC 7489 في مايو 2026) عنوانَ From الذي يراه القارئ بـ SPF وDKIM: تنجح الرسالة حين ينجح SPF أو DKIM لنطاق متوافق مع نطاق From — النطاق نفسه في التوافق الصارم (adkim=s وaspf=s)، أو نطاق يشاركه النطاق التنظيمي في التوافق المرن، وهو الافتراضي. ويخبر السجلُّ عند ‎_dmarc الذي يسبق النطاق الخوادمَ المستقبِلة بما تفعله مع البريد الفاشل: p=none (تقارير فقط)، أو quarantine، أو reject، مع t=y لمرحلة الاختبار (وكان RFC 7489 يستخدم pct= للتطبيق التدريجي) وrua= وruf= للتقارير.

حين لا يكون للاسم سجل، تستخدم الخوادم سجل النطاق التنظيمي: تنطبق سياسة sp= فيه على النطاقات الفرعية إن وُجدت، وnp= على النطاقات الفرعية غير الموجودة. كان RFC 7489 يحدد النطاق التنظيمي بقائمة النطاقات العامة (Public Suffix List)، أما RFC 9989 فيستبدل بها صعوداً في شجرة DNS لا يتجاوز ثمانية استعلامات، قد يبلغ النطاق العلوي، ويراعي وسم psd=، ويعتمد السجل ذا المقاطع الأقل. ويقارب خادم متقن ذلك: ‎_dmarc عند الاسم ثم عند كل نطاق أم حتى مستوى من مقطعين، بخمسة أسماء على الأكثر، ويُعتمد أول اسم عنده سجل واحد بالضبط (ويُتخطّى الاسم الذي عنده أكثر من سجل كما يشترط RFC 9989 §4.10) — والنتيجة واحدة ما لم ينشر اسم وسيط أو لاحقة عامة سجلاً أيضاً.

لا تُرسل التقارير إلى عنوان في نطاق تنظيمي آخر إلا إذا نشر ذلك النطاق سجل TXT بقيمة v=DMARC1 تحت اسمه ‎_report._dmarc — فتقارير example.com المرسلة إلى reports.example.net تحتاجه عند example.com._report._dmarc.reports.example.net ‏(RFC 9990 §4، وقبله RFC 7489 §7.1). وتُقارن النطاقات التنظيمية عبر قائمة النطاقات العامة، فالعنوان في reports.example.com لا يحتاج إلى هذا السجل لنطاق mail.example.com. ويبحث الفاحص عن السجل لنطاقين خارجيين على الأكثر ويبيّن هل هو موجود.

الحدود ومنهجية القياس

يقرأ الفاحص السجلات المنشورة، ولا يرى كيف طبّق خادم معين السياسة على رسالة معينة — فذلك ما تبيّنه التقارير المجمَّعة.

يقارب البحث الصعودَ في شجرة DNS كما يعرّفه RFC 9989: يفحص خمسة أسماء على الأكثر ويتوقف عند مستوى من مقطعين، فلا يستعلم عن نطاق علوي ولا يقرأ وسم psd=، ويعتمد أول سجل يجده لا السجل ذا المقاطع الأقل. ولا تختلف السياسة إلا إذا نشر اسم وسيط أو لاحقة عامة سجلاً أيضاً. وتحت لاحقات عامة مثل co.uk قد يفحص اسماً مثل ‎_dmarc.co.uk.

تُقرأ السجلات عبر محلّل Cloudflare العام من خادم متقن على حافة Cloudflare، وقد لا يظهر التعديل حتى تنتهي صلاحية الإجابات المخزّنة.

لا يُفحص تفويض أكثر من نطاقين خارجيين للتقارير في التشغيل الواحد.

الأمان والخصوصية

في الفحص المباشر يصل النطاق إلى خادم متقن، الذي يسأل DNS العام لدى Cloudflare عبر HTTPS عن أسماء ‎_dmarc للنطاق ونطاقاته الأم، وعن سجل التفويض في نطاق التقارير لعناوين التقارير الخارجية. أما السجل الملصوق فلا يغادر متصفحك. لا يُخزَّن شيء.

المراجع