انتقل إلى المحتوى
مساعدة طارئةابدأ الآن
العودة إلى الأدوات

أداة فحص DMARC

استعلم عن سجل DMARC لنطاق ما واطّلع على سياسته وسياسة النطاقات الفرعية وعنوان التقارير وما يجب إصلاحه. ويقيّم الفحص نفسه SPF وDKIM وبقية جوانب أمان البريد الإلكتروني للنطاق.
ابدأ فحصًا
  • فحص قائم على DNS
  • تحليل غير اقتحامي

ما سجل DMARC؟

سجل DMARC هو سجل DNS من نوع TXT في _dmarc متبوعًا بنطاقك، ويبدأ بـ v=DMARC1. ويخبر الخوادم المستقبِلة بما تفعله بالبريد الذي لا يدعم نطاقَ From فيه نجاحٌ محاذى في SPF أو DKIM، وإلى أين ترسل التقارير. وقيمة وسم السياسة فيه، p، هي none (مراقبة فقط) أو quarantine أو reject.

تقرأ أداة فحص DMARC هذه سجل النطاق. وإذا لم يوجد، تستعلم عن سجل النطاق التنظيمي كما تفعل الخوادم المستقبِلة، وتوضح متى تكون السياسة موروثة. ثم تُجري فحص أمان البريد الإلكتروني الكامل لـ SPF وDKIM والسجلات الأخرى.

عُرّف DMARC في RFC 7489. وفي مايو 2026، حلّ محله RFC 9989 بوصفه مواصفة ضمن مسار المعايير، فأضاف الوسمين np وt وصنّف pct تاريخيًا. وتقرأ أداة الفحص وسوم RFC 7489.

كيف يحسب فحص DMARC درجة السجل

يبدأ السجل من 100 ويخسر نقاطًا عن كل نقطة ضعف. الدرجة 80 فأكثر جيدة، ومن 50 إلى 79 تحذير، وما دون 50 سيئة. ويستحوذ DMARC على 25 نقطة من أصل 100 نقطة في التقييم الإجمالي لأمان البريد الإلكتروني، وهو أكثر من أي سجل آخر.
p=reject
الدرجة الكاملة.
p=quarantine
يخصم 10 نقاط.
p=none
يخصم 40 نقطة: لا تتخذ الخوادم المستقبِلة أي إجراء بشأن البريد الفاشل.
pct أقل من 100
يخصم 15 نقطة: لا يخضع للسياسة إلا جزء من البريد الفاشل.
لا يوجد rua
يخصم 10 نقاط: لا تُطلب أي تقارير مجمّعة.
sp=none مع p أكثر صرامة
يخصم 5 نقاط: النطاقات الفرعية أقل حماية من النطاق.
سجل موروث
تُحسب الدرجة من sp في النطاق التنظيمي، أو من p عند غياب sp: تحصل reject على 100، وquarantine على 75، وnone على 50، مع خصم 15 عندما يكون pct أقل من 100.

مشكلات DMARC الشائعة وكيفية إصلاحها

هذه هي المشكلات التي تكتشفها أداة الفحص هذه، مع التغيير الذي يصلح كلًّا منها.

لا يوجد سجل DMARC

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

الإصلاح: انشر سجل TXT في _dmarc للنطاق، مبتدئًا بوضع المراقبة مع عنوان لتلقي التقارير المجمّعة.

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

p=none دون الانتقال إلى مرحلة تالية

تطلب p=none من الخوادم المستقبِلة عدم اتخاذ أي إجراء، لذا يظل البريد المنتحَل يُسلَّم. إنها مرحلة لجمع التقارير، لا وسيلة حماية.

الإصلاح: استخدم التقارير المجمّعة لإصلاح SPF وDKIM لكل مرسل شرعي، ثم انتقل إلى p=quarantine ولاحقًا إلى p=reject. وللنطاقات التي ينشر مستخدموها في القوائم البريدية، يقترح RFC 9989 قضاء شهر على الأقل على p=none ومدة مماثلة على p=quarantine قبل p=reject.

لا يوجد عنوان تقارير rua

من دون rua، لا ترسل الخوادم المستقبِلة أي تقارير مجمّعة (RFC 7489، القسم 6.3)، فلا يمكنك معرفة الخدمات التي تفشل قبل إنفاذ سياسة ما.

الإصلاح: أضف rua=mailto: مع صندوق بريد تطّلع عليه أو عنوان خدمة تقارير DMARC. وإذا كان صندوق البريد في نطاق تنظيمي آخر، فيجب أن يأذن لنطاقك أولًا (RFC 7489، القسم 7.1).

pct أقل من 100

يطبّق pct السياسة على جزء فقط من البريد الفاشل. وقد صنّف RFC 9989 الوسم pct تاريخيًا لأن الخوادم المستقبِلة طبّقت القيم غير 0 و100 بصورة غير متسقة.

الإصلاح: أزل pct لتُطبَّق السياسة على كل البريد الفاشل، أو استخدم t=y أثناء اختبار سياسة أكثر صرامة.

سياسة أضعف للنطاقات الفرعية

يترك sp=none مع p=quarantine أو p=reject النطاقات الفرعية عرضة للانتحال، بما فيها النطاقات الفرعية التي لا تستخدمها للبريد مطلقًا.

الإصلاح: أزل sp لتتبع النطاقات الفرعية p، أو اضبطه على المستوى نفسه.

وسوم DMARC

تُفصل الوسوم بفواصل منقوطة. وتُتجاهل الوسوم التي لا يعرفها الخادم المستقبِل.
v=DMARC1
الإصدار. يجب أن يكون الوسم الأول.
p=
السياسة المطبّقة على البريد الذي يفشل في DMARC: none أو quarantine أو reject.
sp=
سياسة النطاقات الفرعية. وعند غيابها، تتبع النطاقات الفرعية p.
rua=
وجهة التقارير المجمّعة، في صورة عناوين mailto: مفصولة بفواصل.
ruf=
وجهة تقارير الإخفاق عن الرسائل الفردية. ولا يرسلها كثير من مزوّدي صناديق البريد الكبار.
adkim= / aspf=
المحاذاة في DKIM وSPF: يقبل r (المرن، وهو الافتراضي) نطاقًا فرعيًا من نطاق From، ويتطلب s (الصارم) تطابقًا تامًا.
fo=
الإخفاقات التي تستدعي إرسال تقارير الإخفاق: 0 أو 1 أو d أو s. ويُتجاهل في غياب ruf.
pct=
نسبة البريد الفاشل التي تُطبَّق عليها السياسة، وهي 100 افتراضيًا. وقد صنّفه RFC 9989 تاريخيًا.
np= / t=
أضافها RFC 9989: سياسة للنطاقات الفرعية غير الموجودة، وt=y لاختبار سياسة دون تطبيقها بالكامل.

مثال على سجل

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

المصادر

مزيد من أدوات مصادقة البريد الإلكتروني

ما بعد سجلات DNS

تمنع هذه السجلات الآخرين من إرسال البريد باسم نطاقك نفسه تمامًا. لكنها لا تمنع التصيّد من النطاقات المشابهة أو من الحسابات المخترقة، التي ترسل بريدًا مصادَقًا عليه. يربط Vigilbase OS أدوات الأمان التي تدفع مقابلها بالفعل، ومنها Microsoft 365 وGoogle Workspace وProofpoint وMimecast. ويحقق الوكيل Vigil في الحوادث عالية الخطورة، ويتولى محللو Vigilbase الحالات الاستثنائية.

SOC مُدارابدأ الآن
الأسئلة

أسئلة شائعة عن أداة فحص DMARC

ما وظيفة أداة فحص DMARC؟

تستعلم عن سجل TXT في _dmarc متبوعًا بالنطاق، وتفحص السياسة وسياسة النطاقات الفرعية وpct وعنوان التقارير المجمّعة. وتتبع هذه الأداة أيضًا آلية الرجوع إلى النطاق التنظيمي التي تستخدمها الخوادم المستقبِلة، وتُجري فحص أمان البريد الإلكتروني الكامل.محلل أمان البريد الإلكترونيمقارنة الفحوصات الأمنية العامة

ما الاستعلام عن DMARC؟

استعلام DNS عن سجل TXT في _dmarc متبوعًا بالنطاق، مثل _dmarc.example.com. وإذا لم يُنشر شيء هناك، تستخدم الخوادم المستقبِلة سجل النطاق التنظيمي. يمكنك إجراء هذا الاستعلام في هذه الصفحة، أو باستخدام dig TXT _dmarc.example.com.حول مصادقة البريد الإلكتروني

ما الفرق بين p=none وp=quarantine وp=reject؟

تطلب none من الخوادم المستقبِلة عدم اتخاذ أي إجراء والاكتفاء بالإبلاغ، وتطلب quarantine منها معاملة البريد الفاشل على أنه مشبوه، كتسليمه إلى مجلد البريد العشوائي مثلًا، وتطلب reject منها رفضه. وتجمع الخوادم المستقبِلة بين السياسة وفحوصها الخاصة عند اتخاذ القرار.حول مصادقة البريد الإلكتروني

لماذا تُظهر أداة الفحص أن سجل DMARC الخاص بي موروث؟

ليس للنطاق سجل DMARC خاص به، لذا تطبّق الخوادم المستقبِلة سجل النطاق التنظيمي، مستخدمةً سياسة sp فيه، أو p عند غياب sp (RFC 7489، القسم 6.6.3). انشر سجلًا في النطاق الفرعي إذا كان يحتاج إلى سياسة مختلفة.حول مصادقة البريد الإلكتروني

هل ينبغي أن أستخدم p=reject؟

فقط بعد أن تُظهر تقاريرك نجاح كل المرسلين الشرعيين. يُلزم RFC 9989 النطاقات التي تنشر p=reject بتوقيع بريدها باستخدام DKIM بدلًا من الاعتماد على SPF وحده، وينصح النطاقات التي ينشر مستخدموها في القوائم البريدية بعدم نشر p=reject (القسم 7.4).حول مصادقة البريد الإلكترونيمحلل أمان البريد الإلكتروني

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

لا. حلّ RFC 9989، المنشور في مايو 2026 ضمن مسار المعايير، محل RFC 7489. وهو يُبقي على v وp وsp وrua وruf وadkim وaspf وfo، ويضيف np وpsd وt، ويصنّف pct وrf وri تاريخية. وانتقلت التقارير المجمّعة وتقارير الإخفاق إلى RFC 9990 وRFC 9991.حول مصادقة البريد الإلكتروني

هل يمكن إرسال تقارير DMARC إلى نطاق آخر؟

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

هل يمكنني إجراء استعلام DMARC عبر API؟

نعم. أرسل {"target":"example.com"} بطلب POST إلى https://vigilbase.com/api/v1/agent/tools/email-security/execute. تتضمن الاستجابة نتيجة أمان البريد الإلكتروني الكاملة، ويرد تحليل DMARC تحت result.details.records.dmarc.تشغيل فحص عبر API العامةمصادقة API وحدود معدل الطلبات