6XC

تدقيق DNS للبريد الإلكتروني (SPF، DKIM، DMARC)

دقّق إعدادات DNS الخاصة بالبريد الإلكتروني لنطاق ما في تقرير واحد: MX وSPF وDKIM وDMARC وMTA-STS وTLS-RPT وBIMI — مع شارات نجاح/تحذير/فشل.

1,174 مشاهدة

Data: Google Public DNS (DoH) — يتم إجراء الاستعلامات من متصفحك.

كيف تعمل مصادقة البريد الإلكتروني؟

تعمل ثلاثة سجلات DNS معًا لمنع أي شخص من إرسال بريد مزوَّر يبدو وكأنه صادر من نطاقك. ينشر SPF (إطار سياسة المرسل) قائمة بالخوادم المخوَّلة صراحةً بإرسال البريد نيابة عن النطاق — يتحقق الخادم المستقبِل من عنوان IP المتصل مقابل تلك القائمة. يضيف DKIM (بريد محدد بمفاتيح النطاق) توقيعًا تشفيريًا إلى كل رسالة صادرة؛ ويجلب الخادم المستقبِل مفتاحك العام من DNS ليتحقق من أن التوقيع لم يتغير أثناء النقل، وهو أمر لا يستطيع SPF وحده اكتشافه. يربط DMARC (مصادقة الرسائل المستندة إلى النطاق والإبلاغ والمطابقة) بين الاثنين: فهو يخبر الخوادم المستقبِلة بما ينبغي فعله عند فشل SPF أو DKIM — عدم فعل شيء، الإرسال إلى البريد المزعج، أو الرفض التام — ويطلب تقارير مجمّعة كي ترى من يرسل فعليًا باسم نطاقك، بمن في ذلك المنتحلون.

مثال ملموس: بدون أي من هذه السجلات الثلاثة، يمكن لمهاجم إرسال بريد إلكتروني يبدو صادرًا من [email protected]، وستُسلّمه معظم خوادم البريد مباشرة إلى صندوق وارد المستلم دون أي تحذير يظهر له. أدخل نطاقك في الأداة أعلاه وستستعلم عن MX وSPF وDKIM (بتجربة المحددات الشائعة تلقائيًا) وDMARC عبر DNS-over-HTTPS، ثم تُشير بدقة إلى ما هو مفقود: عدم وجود سجل SPF على الإطلاق، أو سياسة DMARC عالقة عند p=none (مراقبة فقط، بلا حماية حقيقية)، أو سجلا SPF متنافسان (مخالفة للمعايير تُبطل التحقق كليًا)، أو غياب آلية all في نهاية سلسلة SPF.

ما ينبغي أن تعرفه

ضبط هذه السجلات الثلاثة بشكل صحيح ليس أمرًا اختياريًا لأي شخص يهتم بسمعة العلامة التجارية أو بوصول البريد إلى صندوق الوارد — فالنطاق الذي به ثغرات في SPF أو DKIM أو DMARC أسهل انتحالًا، وأكثر عرضة لأن يُوجَّه بريده المشروع نفسه إلى البريد المزعج، لأن مزودين كبار مثل Gmail وYahoo وOutlook يطلبون بشكل متزايد مصادقة كاملة قبل الوثوق بالمرسل. عملية النشر آمنة إذا نُفّذت بالترتيب: انشر SPF أولًا، وأضف توقيع DKIM عبر مزود بريدك، ثم أضف DMARC بدءًا من p=none حتى تتمكن من مراقبة التقارير المجمّعة دون المخاطرة بالبريد الحقيقي — ولا تنتقل إلى الحجر الصحي أو الرفض إلا بعد التأكد من أن كل مصدر إرسال مشروع، مثل أدوات التسويق أو نظام CRM أو نظام التذاكر، مؤكَّد ومتوافق.

  • لا يمكن أن يكون للنطاق الواحد سوى سجل SPF TXT واحد — إذا كنت تستخدم عدة خدمات (Google Workspace، منصة تسويقية، نظام CRM)، ادمج جميع آليات include الخاصة بها في سلسلة واحدة بدلًا من نشر سجلات منفصلة.
  • محددات DKIM خاصة بكل مزوّد: غالبًا ما ينشر Google Workspace تحت "google"، وMicrosoft 365 تحت "selector1" أو "selector2" — إذا لم يجد الفحص التلقائي شيئًا، ابحث عن اسم المحدد الدقيق لمزوّدك وأدخله يدويًا.
  • تدقق هذه الأداة تهيئة DNS فقط؛ ولا تتحقق من حالة القوائم السوداء ولا تفحص محتوى الرسائل — فتلك طبقات منفصلة من قابلية توصيل البريد الإلكتروني تُبنى فوق أساس DNS مُهيّأ بشكل صحيح.

الأسئلة الشائعة

ما الذي يتحقق منه SPF بالضبط، وما الذي لا يستطيع رصده؟

يتحقق SPF من أن الخادم الذي اتصل لتسليم رسالة مُدرَج في قائمة المرسلين المخوَّلين للنطاق. لا يمكنه اكتشاف التلاعب بالرسالة أثناء النقل، ولا يصمد جيدًا أمام إعادة توجيه البريد الإلكتروني — وهذا بالضبط سبب وجود DKIM وDMARC إلى جانبه؛ SPF وحده غير كافٍ.

ما محددات DKIM التي تجربها أداة الفحص تلقائيًا؟

الشائعة منها: default وgoogle وselector1 وselector2 وk1 وs1 وmail وdkim. تنشر مزودات الخدمة تحت محددات معروفة — يستخدم Google Workspace عادة "google"، ويستخدم Microsoft 365 selector1 أو selector2. إن كان محددك مخصصًا، أدخله مباشرة في حقل المحدد.

سياسة DMARC عندي تُظهر p=none — هل هذه مشكلة؟

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

لماذا يؤدي وجود سجلي SPF إلى كسر كل شيء؟

تسمح المواصفة بسجل SPF TXT واحد بالضبط لكل نطاق. تعامل أدوات التحقق وجود سجلات متعددة كخطأ دائم وقد تُفشل الفحص كليًا، ما يمكن أن يرسل بريدًا مشروعًا في الأصل إلى البريد المزعج. ادمج كل مصدر include في سلسلة v=spf1 واحدة.

هل تتحقق هذه الأداة مما إذا كان نطاقي مدرجًا في قائمة سوداء أو تفحص محتوى البريد المزعج؟

لا — فهي تدقق سجلات DNS فقط: MX وSPF وDKIM وDMARC والإضافات الحديثة MTA-STS وTLS-RPT وBIMI. حالة القوائم السوداء وتقييم البريد المزعج القائم على المحتوى نظامان منفصلان؛ ومصادقة DNS الصحيحة هي الأساس الذي تبني عليه تلك الأنظمة ثقتها.

التعليقات

لا توجد تعليقات بعد — كن أول من يكتب تعليقًا!

أدوات مشابهة

مولّد الوسوم الوصفية (العنوان والوصف) اكتب العنوان والوصف مع معاينة حيّة لجوجل وأدلة على الطول — وانسخ وسوم HTML وصفية نظيفة. استخدم منشئ Open Graph وبطاقات تويتر أنشئ وسوم og: و twitter: مع معاينة حية لبطاقة المشاركة — تحكّم في شكل روابطك على منصات التواصل الاجتماعي. أنشئ معاينة نتيجة بحث Google (مقتطف SERP) شاهد كيف سيبدو عنوانك ورابطك ووصفك التعريفي (meta description) في نتائج بحث Google قبل النشر — مع تحذيرات حيّة لتجاوز عدد الأحرف/البكسل. استخدم منشئ الروابط الودودة حوّل أي عنوان إلى رابط نظيف وودود لمحركات البحث — مع تحويل الأحرف الخاصة، وحذف علامات الترقيم، ودعم معالجة عدة أسطر دفعة واحدة. أنشئ