افحص سجل DMARC واقرأ سياسته ومحاذاته وعناوين تقاريره بكلمات واضحة
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device.يقرأ فاحص DMARC سجل TXT الموجود عند _dmarc متبوعًا باسم النطاق، ويخبرك بما يفعله المستقبِلون بالبريد الذي يفشل في SPF وDKIM. السياسات 3: none وquarantine وreject؛ وآخر 2 منها فقط توقفان البريد المزوّر. وعناوين التقارير في نطاق آخر تحتاج إلى سجل إذن هناك.
تُرجمت هذه الصفحة آليًا من الأصل الإنجليزي. لم يراجع أي شخص هذه الترجمة بعد، لذا فالنسخة الإنجليزية هي التي يُعتمد عليها. اقرأ الأصل الإنجليزي
اكتب النطاق في حقل النطاق واضغط فحص DMARC.
اقرأ العنوان: فهو يذكر السياسة المطبّقة على البريد الفاشل لهذا النطاق.
اقرأ قسم ما يقوله هذا السجل لترى السياسة والمحاذاة وعناوين التقارير بكلمات واضحة.
راجع الملاحظات بحثًا عن عناوين تقارير في نطاق آخر لم يوافق على استلام التقارير.
اضغط نسخ بجانب السجل لنسخه.
اكتب نطاقًا فتسأل الصفحة محلّل DNS-over-HTTPS عامًا عن سجل TXT الموجود عند _dmarc. متبوعًا بذلك الاسم. يُقرأ السجل وسمًا وسمًا ثم يُشرح في جمل: ما الذي يحدث للبريد الفاشل، وما الذي يسري على النطاقات الفرعية، ومدى الصرامة التي يجب أن يطابق بها SPF وDKIM عنوان From، وإلى أين تذهب التقارير.
تأتي القواعد من RFC 9989، المنشور في مايو 2026، الذي حلّ محل RFC 7489 معيارًا لـ DMARC. هناك تغييران مهمان عند قراءة السجلات القديمة. أُزيل الوسم pct: ما زال المستقبِلون الأقدم يستخدمونه للتعامل مع جزء فقط من البريد الفاشل، بينما يتجاهله الأحدث. والوسم t=y يعني الآن وضع الاختبار، حيث يطبّق المستقبِلون درجة أخفّ من السياسة. وكلاهما يُشار إليه بالكلمات.
حين لا يكون للنطاق الفرعي سجل خاص به، يبحث المستقبِلون بدلًا منه عن سجل النطاق التنظيمي. تفعل هذه الصفحة ذلك بالتنقّل في شجرة DNS الذي يعرّفه القسم 4.10 من RFC 9989، فتسأل عن _dmarc عند كل اسم أقصر، 8 على الأكثر، وتعرض كل اسم سألت عنه. لا تُستخدم قائمة اللواحق العامة، فلا شيء يعتمد على أن تكون نسخة منها محدّثة.
تُفحص عناوين التقارير في نطاق آخر للتأكد من الإذن. يطلب القسم 4 من RFC 9990 من المستقبِلين ألا يرسلوا التقارير إلى نطاق آخر إلا إذا نشر ذلك النطاق سجل TXT عند نطاق السياسة متبوعًا بـ ._report._dmarc. والمضيف الذي يستلم التقارير. وغيابه هو السبب المعتاد لعدم وصول أي شيء إلى خدمة DMARC.
يكتب تبويب المولّد سجلًا من اختياراتك ويذكر المضيف الذي يُنشر تحته. ويُسقط الوسوم المساوية لقيمها الافتراضية، ولا يكتب pct.
ما لا يفعله: يقرأ السجل لا بريدك، فلا يستطيع أن يخبرك هل تنجح رسائلك. التقارير اليومية هي التي تخبرك بذلك.
يُرسل النطاق الذي تكتبه إلى المحلّل الذي تختاره، لأن الاستعلام يحتاج إليه. ولا يغادر جهازك أي شيء آخر.
تطلب السياسة p=none من المستقبِلين تسليم البريد الذي يفشل في DMARC كالمعتاد وإرسال التقارير فقط. فيظل البريد المزوّر الذي يستخدم النطاق يصل إلى صناديق الوارد. يستخدمها المالكون بضعة أسابيع ليجدوا في التقارير كل مرسل مشروع، ثم ينتقلون إلى quarantine وأخيرًا إلى reject.
ليس بالضرورة. حين لا يكون لنطاق فرعي مثل mail.example.com سجل، يستخدم المستقبِلون سجل النطاق التنظيمي example.com، ويطبّقون سياسة sp= فيه إن وُجدت وإلا p=. ويمكن للنطاق الفرعي نشر سجله الخاص لتجاوز ذلك.
ثلاثة أسباب معتادة: لا يحتوي السجل على عنوان rua=؛ أو العنوان في نطاق آخر لم ينشر سجل الإذن عند yourdomain._report._dmarc.theirdomain؛ أو السجل نفسه غير صالح، مثل وجود سجلي DMARC تحت اسم واحد، فيتجاهلهما المستقبِلون. يفحص هذا الفاحص الأسباب الثلاثة.
أزال RFC 9989، الذي حلّ محل RFC 7489 في مايو 2026، الوسم pct. يتجاهله المستقبِلون الذين يتبعون المعيار الجديد ويطبّقون السياسة على كل البريد الفاشل؛ بينما ما زال الأقدم يلتزمون به. والوسم الجديد t=y هو البديل لاختبار سياسة أشد بلطف.
تطلب quarantine من المستقبِل معاملة البريد الفاشل على أنه مريب، وهذا يعني عمليًا مجلد البريد العشوائي أو غير المرغوب فيه. وتطلب reject من المستقبِل رفض الرسالة أثناء التسليم، فلا تصل إلى المستلم أبدًا. كلاهما يُعد تطبيقًا للسياسة؛ وreject هي الحماية الأقوى من البريد المزوّر.
فقط إلى محلّل DNS العام الذي تختاره، Cloudflare أو Google، لأن الاستعلام عن سجل DNS يحتاج إلى الاسم. يرى المحلّل الأسماء المطلوبة وعنوان IP الخاص بك. ولا يغادر جهازك أي شيء آخر، وتبويب المولّد لا يرسل شيئًا على الإطلاق.
هل ما زلت عالقًا؟ اسأل عن فاحص DMARC ويمكن لأي شخص يعرف الإجابة أن يجيب. لا حاجة إلى حساب.