فاحص قابلية تسليم البريد

بمساعدة الخادم جديد أدوات الويب المساعدة

أدخل النطاق الذي ترسل منه فيقرأ خادم متقن سجلات البريد الخاصة به عبر محلّلات DNS-over-HTTPS العامة — MX وSPF وDMARC وMTA-STS وTLS-RPT وBIMI في ثمانية استعلامات على الأكثر، ثم عناوين ما يصل إلى ثلاثة من مضيفات MX وDNS العكسي لها — ويحوّلها إلى قائمة تحقق فيها «ناجح» و«تحذير» و«فشل» مع طريقة إصلاح كل بند. إنه يفحص ما ينشره النطاق في DNS، لا وصول الرسائل إلى صندوق الوارد ولا سمعة المرسل ولا محتوى الرسائل، وتذكر النتيجة ما لم يستطع رؤيته.

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

ما سجلات DNS التي يحتاجها النطاق قبل أن يرسل بريداً؟

سجل SPF يسرد الخوادم التي ترسل باسم النطاق (RFC 7208)، ومفتاح DKIM لكل خدمة إرسال (RFC 6376)، وسجل DMARC — بسياسة p=none على الأقل مع عنوان rua= للتقارير (RFC 7489) — وسجلات MX كي تجد الردود ورسائل الارتداد وجهة، وخوادم إرسال لعناوينها اسم PTR يعود إليها. يشترط مزوّدو البريد مثل Gmail هذه السجلات قبل قبول البريد بكميات، وهي ضرورية للوصول إلى صندوق الوارد لكنها لا تكفي، لأن السمعة والمحتوى هما ما يحسم الموقع.

ملاحظة أمنية: حتى النطاق الذي لا يرسل بريداً ينبغي أن ينشر «v=spf1 -all» وسجل DMARC بسياسة p=reject، كي لا يرسل أحد باسمه.

كيفية استخدام فاحص قابلية تسليم البريد

  1. أدخل نطاق عنوان From لديك (example.com)؛ ويُختصر العنوان البريدي مثل news@example.com أو الرابط إلى النطاق.
  2. أبقِ خيار «افحص أيضاً عناوين ما يصل إلى 3 من مضيفات MX وDNS العكسي لها» محدداً، إلا إذا كنت تريد السجلات وحدها.
  3. اضغط «افحص النطاق» وانزل في «قائمة التحقق»: بنود «فشل» أولاً ثم بنود «تحذير».
  4. أصلح السجلات لدى مزوّد DNS، وانتظر انقضاء مدة TTL، ثم أعد الفحص؛ وبعدها افحص مفتاح DKIM لكل خدمة ترسل باسمك بأداة فاحص سجل DKIM.

مزايا فاحص قابلية تسليم البريد

  • يقرأ سجلات MX وSPF وDMARC وMTA-STS وTLS-RPT وBIMI لنطاق الإرسال في فحص واحد عبر محلّلات DNS-over-HTTPS العامة
  • يحوّلها إلى قائمة تحقق — «ناجح» أو «تحذير» أو «فشل» أو «معلومات» أو «غير معروف» أو «لا يُفحص هنا» — مع ما تعنيه كل نتيجة لخادم الاستقبال
  • يجلب عنوان ما يصل إلى ثلاثة من مضيفات MX ويفحص DNS العكسي المؤكَّد أمامياً: اسم PTR يعود عند الاستعلام إلى العنوان نفسه
  • ينبّه إلى مشكلات SPF التي يعاقب عليها المستقبِلون: غياب السجل، أو وجود سجلين، أو «+all»، أو سجل معطوب، أو أكثر من 10 مصطلحات استعلام، أو خاتمة لا تحمي شيئاً
  • يفحص DMARC كما تقرؤه قواعد Gmail للمرسلين بالجملة — سجل بسياسة p=none على الأقل — ويتحقق من وصول التقارير المجمّعة (rua) إليك
  • يرتّب الخطوات التالية، ويذكر بالوضوح نفسه ما لا يراه فحص DNS: وصول الرسالة إلى صندوق الوارد، والسمعة، والمحتوى، وتوقيع DKIM

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

المدخلات

  • نطاق الإرسال — نطاق عنوان From لديك؛ ويُختصر العنوان البريدي أو الرابط إليه. وتُرفض عناوين IP.
  • «افحص أيضاً عناوين ما يصل إلى 3 من مضيفات MX وDNS العكسي لها» — مفعّل افتراضياً؛ ألغِ تحديده لقراءة السجلات وحدها.

المخرجات

  • الملخص وقائمة التحقق — عدد البنود الناجحة والتحذيرات والفاشلة وغير المفحوصة، وكل فحص مع حالته ومعناه.
  • ما الخطوة التالية — إصلاحات بنود «فشل» و«تحذير» بالترتيب.
  • خوادم البريد (MX) وSPF وDMARC — مضيفات MX مع العنوان واسم PTR وهل هو مؤكَّد أمامياً، وسجل SPF ومصطلحات الاستعلام فيه، وسجل DMARC ومكان العثور عليه وسياسته وعنوان التقارير.
  • ما لا يشمله هذا الفحص — موقع الرسالة في الصندوق، والسمعة، والمحتوى، وتوقيع DKIM، وDNS العكسي لخوادم الإرسال التي ليست مضيفات MX.

مثال على فاحص قابلية تسليم البريد

example.com، نطاق محجوز ومُغلق بحيث لا يرسل بريداً أبداً

الإدخال:

example.com (المثال المدمج في الأداة)

النتيجة:

الملخص: ناجح 3 · تنبيهات 1 · فشل 1 · لا يُفحص هنا 1
قائمة التحقق: سجلات MX — فشل (Null MX وفق RFC 7505: يعلن النطاق أنه لا يقبل أي بريد) · سجل SPF — ناجح (ينتهي بـ -all) · استعلامات DNS في SPF — ناجح · سجل DMARC — ناجح (سياسة مُلزِمة) · تقارير DMARC — تحذير (لا يوجد عنوان rua=) · DKIM — لا يُفحص هنا · MTA-STS وTLS-RPT وBIMI — معلومات (غير منشورة)
SPF: ‏v=spf1 -all · DMARC: ‏v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s في _dmarc.example.com، السياسة (p) ‏reject
ما الخطوة التالية: انشر سجلات MX للنطاق (أو استخدم نطاق إرسال يستقبل البريد) · أضف عنوان rua= إلى سجل DMARC · افحص مفتاح DKIM لكل خدمة ترسل باسمك

كيف تقرأ نتائج فاحص قابلية تسليم البريد

«فشل» يعني أن المستقبِلين سيرفضون على الأرجح بريد النطاق أو لا يثقون به حتى يُصلح: غياب SPF، أو SPF معطوب أو «+all»، أو سجل DMARC غير صالح، أو مضيفات MX بلا عناوين، أو Null MX على نطاق ترسل منه.

«تحذير» يعني أن البريد قد يُسلَّم لكن بثقة أقل، أو أنك تعمل دون رؤية: لا سجل DMARC، أو لا تقارير rua=، أو خاتمة «?all»، أو عناوين MX بلا DNS عكسي مطابق.

«ناجح» يخص السجل المنشور فقط: سجل DMARC بسياسة p=none ينجح لأن Gmail تقبله من المرسلين بالجملة، رغم أنه لا يمنع التزوير — ويقيّم فاحص انتحال نطاق البريد ذلك الجانب.

«لا يُفحص هنا» و«غير معروف» ليسا نجاحاً: يحتاج DKIM إلى محدِّد، والاستعلام الفاشل لا يقول شيئاً في أي اتجاه.

نجاح كل البنود بداية جيدة لا وعد بالوصول إلى صندوق الوارد: السمعة والمحتوى ونسب الشكاوى هي التي تحسم الموقع.

متى تستخدم فاحص قابلية تسليم البريد

  • تجهيز نطاق جديد أو خدمة إرسال جديدة قبل أول حملة.
  • معرفة سبب تحوّل رسائل نطاق ما إلى البريد العشوائي بعد تغيير في DNS أو في المزوّد.
  • فحص نطاق عميل أو قسم مقابل متطلبات Gmail للمرسلين بالجملة قبل الإطلاق.
  • مراجعة خادم بريد مستضاف ذاتياً: عناوين MX وأسماء PTR وسجل SPF في فحص واحد.

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

  • «تعذّر على محلّلات DNS العامة الإجابة عن هذا النطاق»: النطاق غير موجود، أو أن DNS الخاص به يجيب بـ SERVFAIL (وكثيراً ما يكون السبب DNSSEC معطوباً). أصلح DNS أولاً، فالمستقبِلون لا يستطيعون قراءة سجلاتك أيضاً.
  • سجل نشرته للتو ما زال يظهر مفقوداً: تحتفظ المحلّلات بالإجابات طوال مدة TTL للسجل. انتظر انقضاءها ثم أعد الفحص.
  • يظهر DNS العكسي «لا يوجد سجل PTR» لمضيف يديره مزوّدك: لا يضبط PTR إلا مالك نطاق العناوين. اطلبه من مزوّد الاستضافة أو الشبكة، أو تجاهله إن كان ذلك المضيف لا يرسل أبداً.
  • «لم يُستعلم عنه: نفدت حصة استعلامات DNS لهذه الدقيقة»: تُحتسب استعلامات MX من حصة دقيقة مشتركة مع أدوات DNS الأخرى. انتظر دقيقة ثم أعد الفحص.

الأسئلة الشائعة حول فاحص قابلية تسليم البريد

هل تعني النتيجة النظيفة أن رسائلي ستصل إلى صندوق الوارد؟

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

لماذا يظهر DKIM بعبارة «لا يُفحص هنا»؟

يُنشر مفتاح DKIM في selector._domainkey.domain، ولا يتيح DNS سرد المحدِّدات التي يستخدمها النطاق. خذ قيمة s= من ترويسة DKIM-Signature في رسالة أرسلتها (يعرضها محلّل ترويسات البريد الإلكتروني) وافحص ذلك المفتاح بأداة فاحص سجل DKIM.

ماذا تشترط Gmail على المرسلين؟

تطلب إرشادات Google من كل مرسل SPF أو DKIM، وسجلات DNS أمامية وعكسية صالحة لنطاقات الإرسال أو عناوينه، واستخدام TLS، ونسبة بريد عشوائي مُبلَّغ عنها دون 0.3%. ويُشترط على من يرسل أكثر من 5000 رسالة يومياً إلى Gmail أيضاً SPF وDKIM معاً، وسجل DMARC (تُقبل سياسة none)، ونطاق From محاذٍ لـ SPF أو DKIM، وإلغاء اشتراك بنقرة واحدة في الرسائل التسويقية. وتفحص هذه الأداة الجزء المنشور في DNS من تلك القائمة.

لماذا يُفحص DNS العكسي لمضيفات MX؟

مضيفات MX تستقبل البريد، لكن حين ترسل الخوادم نفسها أيضاً — وهو شائع في البريد المستضاف ذاتياً — يتوقع المستقبِلون أن يكون لكل عنوان اسم PTR يعود إليه. أما إن كنت ترسل عبر مزوّد (Google Workspace أو Microsoft 365 أو خدمة بريد)، فالـ DNS العكسي لخوادم الإرسال لديه من مسؤوليته ولا يظهر هنا.

كم استعلام DNS يجريه الفحص الواحد؟

ثمانية على الأكثر لسجلات البريد، ثم من اثنين إلى أربعة لكل مضيف MX — عنوان IPv4 الخاص به (أو IPv6 إن لم يكن له IPv4)، واسم PTR لذلك العنوان، وعنوان ذلك الاسم إذا اختلف عن اسم المضيف — لثلاثة مضيفات على الأكثر. تخرج الاستعلامات من حافة Cloudflare إلى محلّلات DNS-over-HTTPS العامة، ولا يُخزَّن شيء.

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

النظرة العامة طلب واحد إلى خادم متقن يرسل ثمانية استعلامات DNS-over-HTTPS على الأكثر من حافة Cloudflare: سجل MX، وسجلات TXT للنطاق (من أجل SPF وفق RFC 7208)، وتتبّع DMARC من _dmarc في النطاق صعوداً إلى نطاقه التنظيمي (RFC 7489)، و_mta-sts ‏(RFC 8461)، و_smtp._tls ‏(RFC 8460)، وdefault._bimi. وسجل Null MX ‏(«0 .» وفق RFC 7505) يعلن أن النطاق لا يستقبل بريداً.

يُقرأ SPF قراءة ثابتة: تُعدّ مصطلحات الاستعلام في السجل نفسه مقابل حد العشرة في RFC 7208 §4.6.4، وتُحسب include: وredirect= دون تتبّعها، ووجود أكثر من سجل v=spf1 خطأ دائم. أما فاحص سجل SPF فيتتبّع السلسلة كاملة.

يُفحص DNS العكسي كما يفحصه المستقبِلون (DNS عكسي مؤكَّد أمامياً): يُحلّ عنوان IPv4 لمضيف MX (أو IPv6 إن لم يكن له IPv4)، ويُقرأ سجل PTR الخاص به (RFC 1035)، ويجب أن يعود اسم PTR إلى العنوان نفسه. وكل استعلام طلب مستقل من متصفحك إلى خادم متقن، من اثنين إلى أربعة لكل مضيف، لثلاثة مضيفات على الأكثر.

تطلب إرشادات Google للمرسلين من كل مرسل SPF أو DKIM، وDNS أمامياً وعكسياً صالحاً لخوادم الإرسال، وTLS، ونسبة بريد عشوائي دون 0.3%، وتطلب ممن يرسل أكثر من 5000 رسالة يومياً SPF وDKIM معاً، وDMARC بسياسة p=none على الأقل، ومحاذاة From، وإلغاء الاشتراك بنقرة واحدة (RFC 8058). ولا يمكن فحص شيء من خارج النطاق إلا الجزء المنشور في DNS من هذه القائمة.

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

لا يُفحص إلا DNS المنشور: لا موقع الرسالة في الصندوق، ولا سمعة المرسل أو القوائم السوداء، ولا المحتوى، ولا نسب الشكاوى، ولا توقيع DKIM، ولا TLS في الاتصالات الصادرة، ولا ترويسات إلغاء الاشتراك.

لا تُفحص مفاتيح DKIM لأن المحدِّد لا يُكتشف من DNS، ولا تُتتبّع include: وredirect= في SPF ضمن هذه النظرة العامة.

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

تذهب الاستعلامات إلى محلّلات DNS-over-HTTPS العامة من حافة Cloudflare، وتعرض ما كان في ذاكرتها المؤقتة في تلك اللحظة.

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

يُرسل النطاق وأسماء مضيفات MX وعناوينها من خادم متقن إلى محلّلات DNS العامة؛ ولا يُخزَّن شيء ولا تُرسل أي رسالة بريد.

المراجع

  • Email sender guidelinesGoogle (Gmail Help)ما تشترطه Gmail على كل مرسل (SPF أو DKIM، وDNS أمامي وعكسي، وTLS، ونسبة بريد عشوائي دون 0.3%) وعلى من يرسل أكثر من 5000 رسالة يومياً (SPF وDKIM معاً، وDMARC، والمحاذاة، وإلغاء الاشتراك بنقرة واحدة).
  • RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1IETF · 2014معيار SPF نفسه: سجل v=spf1 وآلياته ومؤهِّلاته، وترتيب التقييم، وحدّا الاستعلامات العشرة والاستعلامين الفارغين في كل فحص.
  • RFC 6376: DomainKeys Identified Mail (DKIM) SignaturesIETF · 2011تواقيع DKIM وسجل المفتاح العام عند selector._domainkey: وسومه (v وk وp وt وs وh وn) وكيف يجد المتحقِّق المفتاح ويستخدمه.