كيف تمنع SPF وDKIM وDMARC إرسال بريد باسم نطاقك؟
يحدّد SPF (RFC 7208) الخوادم المسموح لها بالإرسال باسم النطاق، ويوقّع DKIM (RFC 6376) الرسائل بمفتاح منشور في DNS، لكن أياً منهما لا يتحقق من عنوان المرسل الذي يراه الناس. أما DMARC (RFC 7489) فيفعل ذلك: لا تجتاز الرسالة إلا إذا نجح SPF أو DKIM لنطاق محاذٍ لعنوان From، وتخبر سياسة p= المستقبِلين بتسليم الباقي (none) أو عزله (quarantine) أو رفضه (reject) — فلا يحمى النطاق من الانتحال المباشر إلا حين ينشر p=quarantine أو p=reject.
ملاحظة أمنية: لا يحمي DMARC إلا النطاق نفسه بالضبط. أما النطاقات المقلِّدة وأسماء العرض المزوّرة فتجتاز كل الفحوص، لذا تبقى طلبات تغيير بيانات الدفع وطلبات بيانات الدخول الواردة بالبريد بحاجة إلى تأكيد عبر قناة أخرى.
كيفية استخدام فاحص انتحال نطاق البريد
- أدخل النطاق الوارد في عنوان المرسل (example.com)؛ ويُختصر عنوان البريد أو الرابط إلى النطاق.
- الصق اختيارياً ترويسات رسالة مشبوهة (في Gmail: «عرض الرسالة الأصلية»، وفي Outlook: «عرض مصدر الرسالة»)، وإن تركت حقل النطاق فارغاً أُخذ نطاق المرسل منها.
- اضغط «افحص النطاق» واقرأ خطورة الانتحال وأسبابها، ثم تفاصيل SPF وDMARC.
- نفّذ «ما الخطوة التالية» من الأعلى، وأعد الفحص بعد كل تعديل في DNS حين تنقضي مدة TTL الخاصة به.
مزايا فاحص انتحال نطاق البريد
- يقرأ سجلات MX وSPF وDMARC وMTA-STS وTLS-RPT وBIMI للنطاق في فحص واحد عبر محلّلات DNS-over-HTTPS العامة
- يقدّر مدى سهولة تزوير بريد باسم النطاق — خطورة منخفضة أو متوسطة أو عالية أو غير معروفة — من سياسات SPF وDMARC المنشورة، ويذكر كل قاعدة حدّدت المستوى
- يتتبّع DMARC صعوداً إلى النطاق التنظيمي، فيُحكم على النطاق الفرعي الذي لا سجل له بالسياسة التي تنطبق عليه فعلاً (sp= أو p=)
- يعرض خاتمة SPF (-all أو ~all أو ?all أو +all أو تفويض redirect)، وعدد مصطلحات استعلامات DNS والسجلات المكررة، وسياسة DMARC ونسبتها وأنماط المحاذاة وعناوين التقارير
- يقرأ اختيارياً ترويسات رسالة ملصوقة داخل متصفحك: نتائج SPF وDKIM وDMARC التي سجّلها خادم الاستقبال، ومحاذاتها مع نطاق المرسل، وعنوان Reply-To على نطاق آخر
- يرتّب الخطوات التالية: نشر SPF، ثم نشر DMARC، ثم الانتقال من p=none إلى quarantine فـ reject، وإغلاق النطاقات التي لا ترسل بريداً
المدخلات والمخرجات
المدخلات
- نطاق المرسل — نطاق عنوان From؛ ويُختصر العنوان مثل billing@example.com أو الرابط إلى النطاق. وتُرفض عناوين IP.
- ترويسات الرسالة (اختياري) — كتلة الترويسات الكاملة لرسالة واحدة، تُقرأ في متصفحك فقط. وإن كان حقل النطاق فارغاً فُحص نطاق المرسل منها.
المخرجات
- الملخّص وسبب هذا المستوى — خطورة الانتحال، وخاتمة SPF، وسياسة DMARC المنطبقة، ومضيفات MX، وكل قاعدة حدّدت المستوى.
- SPF وDMARC — السجلات كما نُشرت، ومكان العثور على DMARC، والسياسة، وسياسة النطاقات الفرعية، والنسبة، وأنماط المحاذاة، وعناوين التقارير.
- خوادم البريد (MX) وسياسات البريد الأخرى — مضيفات MX بحسب الأولوية، وهل MTA-STS وTLS-RPT وBIMI منشورة.
- ما سجّله خادم الاستقبال (مع الترويسات) وما الخطوة التالية — نتائج SPF وDKIM وDMARC المسجّلة ومحاذاتها، والتعديلات المطلوبة بالترتيب.
مثال على فاحص انتحال نطاق البريد
نطاق لا يرسل بريداً ومُغلق بإحكام
الإدخال:
example.comالنتيجة:
خطورة الانتحال: منخفضة (من السياسات المنشورة وحدها) · SPF -all · سياسة DMARC reject · مضيفات MX: Null MX
سبب هذا المستوى: Null MX (RFC 7505): يعلن النطاق أنه لا يستقبل بريداً أبداً. · SPF ينتهي بـ «-all» وDMARC بـ p=reject بنسبة 100%: يرفض المستقبِلون البريد المزوّر.
DMARC: v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s في _dmarc.example.com · المحاذاة (adkim / aspf) s / s · التقارير المجمّعة (rua) —
MTA-STS: غير منشور · TLS-RPT: غير منشور · BIMI: غير منشور
ما الخطوة التالية: أضف عنوان rua= لتصلك التقارير المجمّعة التي تكشف من يرسل البريد باسم النطاق.كيف تقرأ نتائج فاحص انتحال نطاق البريد
«عالية» تعني أن المزوِّر يستطيع إرسال بريد يسلّمه معظم المستقبِلين على أنه من النطاق: لا سياسة DMARC مُلزِمة، أو SPF غائب أو مفتوح للجميع. و«متوسطة» تعني أن البريد المزوّر يُصفّى غالباً لكنه لا يُرفض دائماً. و«منخفضة» تعني أن المستقبِلين الذين يطبّقون DMARC يرفضون البريد الذي يفشل في المحاذاة.
المستوى وصف لسياسات النطاق لا لأي رسالة. فالبريد من نطاق منخفض الخطورة قد يُزوَّر لدى مستقبِل يتجاهل DMARC، والنطاق المقلِّد لا يحتاج أي وصول إلى نطاقك أصلاً.
p=none وضع مراقبة: يجمع التقارير ولا يطلب من المستقبِلين فعل شيء، لذا تُصنَّف خطورة النطاق ذي p=none عالية حتى لو كان SPF وDKIM مثاليين.
مع الترويسات الملصوقة، تعني «نتيجة DMARC (المسجّلة): أخفقت» أن خادم الاستقبال لم يوثّق الرسالة لنطاق مرسلها — وهي علامة قوية على التزوير حين ينشر ذلك النطاق quarantine أو reject. أما «لا شيء — لا توجد سياسة DMARC منشورة» فتعني أنه لم تكن هناك سياسة تُطبَّق، و«فحص غير مكتمل» (temperror أو permerror) يعني أن خادم الاستقبال لم يُتمّ الفحص؛ وليس أيٌّ منهما دليلاً على التزوير.
متى تستخدم فاحص انتحال نطاق البريد
- معرفة ما إذا كان نطاقك يُستغل لإرسال رسائل تصيّد باسمك، وما يجب نشره لإيقاف ذلك.
- مراجعة نطاق مورّد أو شريك قبل الوثوق برسائل منه تطلب تغيير بيانات الحساب البنكي.
- التحقيق في رسالة مشبوهة: هل وُثّقت لنطاق مرسلها، وهل يفرض ذلك النطاق DMARC؟
- إغلاق النطاقات المحجوزة أو المتقاعدة التي يجب ألا ترسل بريداً أبداً.
استكشاف الأخطاء وإصلاحها
- «The resolver answered SERVFAIL for …»: DNS النطاق يتعطل، وكثيراً ما يكون السبب DNSSEC معطوباً. أصلح ذلك أولاً، فالمستقبِلون لا يستطيعون قراءة السياسات أيضاً.
- الخطورة متوسطة رغم أن DMARC هو p=reject: SPF ينتهي بـ ~all أو ?all، أو pct أقل من 100، أو sp= أضعف، أو SPF مفوَّض عبر redirect=. وقائمة الأسباب تحدّد أيها.
- سجل نشرته للتو لا يظهر: تحفظ المحلّلات إجابات DNS مدة TTL الخاصة بالسجل. انتظر انقضاءها وأعد الفحص.
- «لم يُعثر على عنوان مرسل في الترويسات الملصوقة»: الصق كتلة الترويسات كاملة بما فيها سطر From:، أو اكتب النطاق بنفسك.
الأسئلة الشائعة حول فاحص انتحال نطاق البريد
ماذا يعني مستوى خطر الانتحال؟
مدى سهولة إرسال بريد باسم النطاق ووصوله على أنه منه، مُقدَّراً من سياسات SPF وDMARC المنشورة وحدها. «منخفضة» تعني أن المستقبِلين الذين يطبّقون DMARC يرفضون البريد المزوّر، و«عالية» تعني أنه لا توجد سياسة DMARC مُلزِمة أو أن SPF غائب أو مفتوح للجميع. وهو ليس حكماً على رسالة بعينها.
سياسة DMARC عندنا p=none، فلماذا الخطورة عالية؟
لأن p=none تطلب التقارير فقط، ويواصل المستقبِلون تسليم البريد الذي يفشل في التحقق كالمعتاد. إنها خطوة أولى صحيحة لمعرفة من يرسل باسمك، لكن الحماية تبدأ مع p=quarantine وتكتمل مع p=reject.
هل تفحص الأداة مفاتيح DKIM؟
ليس هنا: يقع مفتاح DKIM في selector._domainkey.domain، والمحدِّد (selector) لا يمكن اكتشافه من DNS. خذ قيمة s= من ترويسة DKIM-Signature في إحدى رسائلك واستخدم فاحص سجل DKIM.
هل أستطيع معرفة إن كانت رسالة معيّنة مزوّرة؟
الصق ترويساتها. تعرض الأداة نتائج SPF وDKIM وDMARC التي سجّلها خادم الاستقبال ومدى محاذاتها مع نطاق المرسل. فشل DMARC المسجّل لنطاق سياسته p=reject علامة قوية على التزوير؛ أما الترويسات التي تحت ترويسات خادمك فيمكن تزييفها، فثق بالنتائج التي كتبها نظام بريدك أنت.
نطاقنا لا يرسل أي بريد، فهل نحتاج SPF وDMARC؟
نعم، فالنطاقات غير المستخدمة هدف شائع للانتحال. انشر «v=spf1 -all» وسجل DMARC بسياسة p=reject، ويُفضّل سجل null MX («0 .»، RFC 7505) حتى لا يرسل أحد أو يستقبل باسم النطاق.
ملاحظات تقنية
يحدّد SPF (RFC 7208) الخوادم المسموح لها بالإرسال باسم النطاق في المغلّف (MAIL FROM)، ويوقّع DKIM (RFC 6376) الرسائل بمفتاح منشور في DNS، ويربط DMARC (RFC 7489) الاثنين بنطاق المرسل الظاهر: لا تجتاز الرسالة DMARC إلا إذا نجح SPF أو DKIM لنطاق محاذٍ لعنوان From، وتخبر p= المستقبِلين بما يفعلونه بالباقي — none (مراقبة) أو quarantine (مجلد الرسائل المزعجة) أو reject.
يتبع المستوى قواعد ثابتة: غياب SPF، أو «+all»، أو SPF معطوب، أو غياب DMARC، أو DMARC غير صالح، أو سياسة فعلية none ← عالية؛ وSPF ينتهي بـ «-all» مع p=reject بنسبة pct=100 دون sp= أضعف ← منخفضة؛ وما بينهما — ~all أو ?all، أو quarantine، أو pct أقل من 100، أو سياسة أضعف للنطاقات الفرعية، أو SPF مفوَّض عبر redirect= لا يقرؤه هذا العرض ← متوسطة؛ وإخفاق الاستعلام ← غير معروف.
يتتبّع استعلام DMARC الاسمَ _dmarc الخاص بالنطاق (_dmarc.mail.example.com) صعوداً نحو النطاق التنظيمي (ثلاثة أسماء على الأكثر في هذا الفحص)؛ وإن جاءت السياسة من نطاق أعلى انطبقت sp= على النطاق الفرعي إن وُجدت، وإلا فـ p=. ويُقرأ SPF قراءة ثابتة: تُعدّ مصطلحات include: وredirect= ولا تُتبع، فلا يظهر «+all» أو تجاوز حد الاستعلامات خلف include إلا في فاحص سجل SPF.
يرسل خادم متقن 8 استعلامات DNS-over-HTTPS على الأكثر في كل فحص: MX، وسجلات TXT للنطاق، وتتبّع DMARC، و_mta-sts (MTA-STS، RFC 8461)، و_smtp._tls (TLS-RPT، RFC 8460)، وdefault._bimi. وسجل null MX («0 .»، RFC 7505) يعلن أن النطاق لا يستقبل بريداً. وتُحلَّل الترويسات الملصوقة في المتصفح، وأحدث ترويسة Authentication-Results حكمت على كل طريقة هي التي تحدّد النتيجة المسجّلة، وتُعرض النتيجة على حقيقتها — pass أو fail أو softfail أو neutral أو none أو temperror أو permerror؛ أما الترويسة التي لا يطابق معرّف authserv فيها خادمَ الاستقبال المذكور في ترويسات Received فتُستبعد، كما يطلب RFC 8601.
الحدود ومنهجية القياس
لا تُفحص إلا سياسات DNS المنشورة: لا تُفحص مفاتيح DKIM (فهي تحتاج محدِّداً)، ولا تُتبع include: وredirect= في SPF، ولا تُرسل أي رسالة ولا تُستقبل — فالمستوى ليس اختباراً لسلوك مستقبِل بعينه.
تمر الاستعلامات عبر محلّلات DNS-over-HTTPS العامة من حافة Cloudflare، وتُظهر ما كان لدى تلك المحلّلات في تلك اللحظة.
قد تُزوَّر الترويسات الواقعة تحت ترويسات خادم بريدك. تعرض الأداة أحدث النتائج المسجّلة، ولا تستطيع إثبات أن ترويسة تحمل اسم خادمك قد كتبها خادمك فعلاً.
الأمان والخصوصية
يُرسل النطاق إلى خادم متقن فيسأل محلّلات DNS العامة عن سجلات بريده، ولا يُخزَّن شيء. أما الترويسات الملصوقة فتُحلَّل في متصفحك ولا تُرسل أبداً.
المراجع
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)معيار DMARC كما نُشر أول مرة (2015): السجل عند _dmarc، ووسوم p وsp وpct وadkim وaspf وrua وruf، وتوافق المعرّفات مع SPF وDKIM، والرجوع إلى نطاق تنظيمي يُحدَّد بقائمة النطاقات العامة. حلّ محله RFC 9989 في مايو 2026، لكن وسومه pct وrf وri لا تزال تظهر في سجلات منشورة.
- RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1معيار SPF نفسه: سجل v=spf1 وآلياته ومؤهِّلاته، وترتيب التقييم، وحدّا الاستعلامات العشرة والاستعلامين الفارغين في كل فحص.
- RFC 6376: DomainKeys Identified Mail (DKIM) Signaturesتواقيع DKIM وسجل المفتاح العام عند selector._domainkey: وسومه (v وk وp وt وs وh وn) وكيف يجد المتحقِّق المفتاح ويستخدمه.