فاحص سجل SPF

بمساعدة الخادم جديد DNS والنطاقات

اقرأ سجل SPF المنشور في TXT لأي نطاق وقيّمه كما يفعل خادم البريد المستقبِل: يُتتبَّع كل include وredirect وتُحَلّ عناصر a وmx، ويُحسب ذلك كله مقابل حدّ الاستعلامات العشرة في RFC 7208، وتُكشف الاستعلامات الفارغة والحلقات، ويُشرح عنصر all الذي يحدد مصير المرسِلين غير المدرجين. أما السجل الذي تلصقه فيُحلَّل في متصفحك لتتحقق منه قبل نشره.

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

ما هو سجل SPF؟

سجل SPF سجل TXT يبدأ بـ v=spf1 ويحدد الخوادم المسموح لها بإرسال البريد باسم النطاق في مغلّف SMTP (عنوان Return-Path). يقارن الخادم المستقبِل عنوان الاتصال بعناصر السجل فيحصل على pass أو fail أو softfail أو neutral، وللحدّ من هذا العمل يسمح RFC 7208 بعشرة استعلامات DNS على الأكثر في كل تقييم، وتجاوزها يعني permerror.

كيفية استخدام فاحص سجل SPF

  1. اكتب نطاق عنوان المرسِل مثل example.com، ويصلح أيضاً عنوان كامل مثل billing@example.com.
  2. اضغط «فحص SPF». يقرأ خادم متقن سجلات TXT للنطاق ويتتبّع كل include وredirect.
  3. اقرأ الملخص: النتيجة، وعدد استعلامات DNS المستخدمة من أصل 10، والاستعلامات الفارغة، ومصير المرسِلين غير المدرجين.
  4. راجع جدول الاستعلامات والأخطاء والتحذيرات، وصحّح السجل لدى مزوّد DNS ثم أعد الفحص.
  5. لتجربة تعديل قبل نشره، الصق السجل الجديد في الحقل الثاني؛ فيُحلَّل في متصفحك ولا يُرسَل شيء.

مزايا فاحص سجل SPF

  • تقييم كامل وفق RFC 7208: تُتتبَّع سلاسل include وredirect، وتُحَلّ عناصر a وmx، وتُحسب عناصر ptr وexists
  • حساب حدّ الاستعلامات العشرة على السلسلة كلها، مع إدراج كل استعلام بعد العاشر دون إرساله أبداً
  • الإبلاغ عن الاستعلامات الفارغة (أسماء بلا سجل، ولا يُسمح بأكثر من اثنين) والحلقات وأهداف include الخالية من SPF على أنها permerror
  • كل عنصر في السجل مع النتيجة التي يعطيها عند التطابق (Pass وFail وSoftFail وNeutral)، وهل يكلّف استعلام DNS، وما الذي أعاده
  • شرح عنصر all الذي يحسم الأمر في النهاية بعد أي redirect=، أي ما يحدث لبريد الخوادم التي لم تُدرجها
  • فحص مسوّدة سجل تلصقها في الحقل الثاني داخل متصفحك قبل نشرها
  • أخطاء وتحذيرات وخطوات تالية بلغة واضحة، مع السجل أو الاسم الذي يخصّه كل منها

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

المدخلات

  • اسم النطاق — نطاق المرسِل في المغلّف، ويُكتب اسماً أو عنوان بريد أو رابطاً، وتُقبل أسماء النطاقات الدولية.
  • سجل SPF ملصوق (اختياري) — سجل واحد يبدأ بـ v=spf1، مجرّداً أو بين علامات تنصيص كما يُنسخ من ملف المنطقة. عند تعبئته يُفحص في متصفحك ولا يُجرى أي استعلام.

المخرجات

  • الملخص — النتيجة، واستعلامات DNS المستخدمة من 10، والاستعلامات الفارغة من 2، ومصير المرسِلين غير المدرجين، وعدد سجلات SPF المنشورة إن كانت أكثر من واحد.
  • السجل — سجل SPF الذي عُثر عليه، والاسم الذي فُحص، وهدف redirect= إن كانت السياسة مُحالة، وعدد استعلامات DNS التي أجراها الفحص.
  • عناصر السجل — كل عنصر مع نوعه والنتيجة التي يعطيها عند التطابق، وهل يكلّف استعلاماً، وما الذي أعاده.
  • استعلامات DNS بالترتيب — كل استعلام في السلسلة كلها مع عمقه ونتيجته، بما فيها ما تجاوز الحد ولم يُرسَل.
  • الأخطاء والتنبيهات وما الخطوة التالية — كل ملاحظة بلغة واضحة مع الاسم أو العنصر الذي تخصّه.

مثال على فاحص سجل SPF

نطاق سياسة SPF فيه عنصر include واحد (google.com، أكتوبر 2026)

الإدخال:

google.com

النتيجة:

النتيجة: يعمل مع تحذيرات · استعلامات DNS: ‎1 / 10 · الاستعلامات الفارغة: ‎0 / 2 · المرسِلون غير المدرجين: ~all (softfail: يُعلَّم بريد الخوادم غير المدرجة ولا يُرفض)
السجل: v=spf1 include:_spf.google.com ~all
استعلامات DNS بالترتيب: 1 · include:_spf.google.com · _spf.google.com · العمق 0 · عُثر على سجل SPF
تنبيهات: "~all" (softfail) يطلب من الخوادم المستقبِلة قبول بريد الخوادم غير المدرجة مع تعليمه، والصيغة الصارمة هي "-all". ومع تطبيق سياسة DMARC يصبح الفرق صغيراً.

كيف تقرأ نتائج فاحص سجل SPF

«لا مشكلات»: ينتهي السجل بـ ‎-all، ويبقى ضمن 10 استعلامات واستعلامين فارغين حتى لمرسِل لا يتطابق مع أي عنصر قبل النهاية، ولا يوجد ما يستدعي التحذير.

«الصياغة سليمة»: تظهر بدلاً من ذلك لسجل ملصوق ينتهي بـ ‎-all ولا شيء فيه يستدعي التحذير. لم تُتتبَّع عناصر include فيه، فلا يظهر العدد الكامل للاستعلامات إلا عند فحص النطاق المنشور.

«يعمل مع تحذيرات»: تستطيع الخوادم تقييم السجل، لكن شيئاً يُضعفه — غالباً ‎~all أو ‎?all أو غياب all أو عنصر ptr المتقادم أو استعلام DNS فشل مؤقتاً أثناء الفحص.

«فيه أخطاء»: سيتوقف الخادم المستقبِل عند permerror (أكثر من 10 استعلامات، أو سجلّان، أو خطأ صياغة، أو include بلا SPF، أو حلقة)، أو أن ‎+all يُنجح كل الخوادم. وكثير من الخوادم تعامل النطاق حينها كأنه بلا SPF.

استعلامات DNS: يشمل العدد كل ما يُبلَغ عبر include، فقد يستهلك سجل من ثلاثة عناصر ثمانية أو تسعة استعلامات عبر مزوّد واحد. والعدد 8 فما فوق لا يترك متسعاً للخدمة التالية التي ستضيفها.

«لا يوجد سجل SPF»: لا يوجد عند الاسم سجل TXT يبدأ بـ v=spf1. تحصل الخوادم على النتيجة none، ولا ينجح DMARC حينها إلا عبر DKIM.

متى تستخدم فاحص سجل SPF

  • إضافة خدمة إرسال جديدة — نظام CRM أو منصة نشرات بريدية أو نظام دعم فني — والتأكد من أن include الخاص بها لا يتجاوز بالنطاق حد الاستعلامات العشرة.
  • معرفة سبب فشل بريد خدمة ما في SPF، أو في توافق DMARC، لدى Gmail أو Outlook.
  • مراجعة مسوّدة سجل قبل نافذة التعديل دون نشرها.
  • تدقيق النطاقات المحجوزة وغير المستخدمة للتأكد من أنها تنشر "v=spf1 -all".

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

  • «أكثر من 10 استعلامات DNS»: افتح جدول الاستعلامات لترى أي include يستهلك أكثر، واحذف الخدمات التي لم تعد تستخدمها، أو استبدل include المزوّد الذي ينشر نطاقات عناوين ثابتة بنطاقات ip4 وip6 نفسها.
  • «ينشر النطاق أكثر من سجل SPF»: يوجد سجلّا TXT يبدآن بـ v=spf1، وكثيراً ما يكون أحدهما قديماً تركه مزوّد سابق. ادمجهما في سجل واحد.
  • «هدف include أو redirect لا ينشر سجل SPF»: يشير include إلى اسم بلا سجل SPF — خطأ إملائي، أو مزوّد غيّر اسم المضيف الخاص بـ include. قارنه بدليل الإعداد الحالي لدى المزوّد.
  • ظهور temperror في النتائج: أحد النطاقات في السلسلة لم يُجب في الوقت المحدد. أعد الفحص، فإن استمر الإخفاق فالمشكلة في خوادم أسماء ذلك النطاق.
  • رسالة حدّ الطلبات: يُحتسب كل فحص SPF بما يصل إلى 21 استعلام DNS من حصتك في أدوات DNS، فقد تستنفدها بضعة فحوص متتالية. انتظر عدد الثواني المعروض ثم أعد المحاولة.

الأسئلة الشائعة حول فاحص سجل SPF

ما هو حد الاستعلامات العشرة في SPF؟

يسمح القسم 4.6.4 من RFC 7208 للخادم المستقبِل بعشرة استعلامات DNS على الأكثر أثناء تقييم SPF. كل عنصر include أو a أو mx أو ptr أو exists ومعدِّل redirect يكلّف استعلاماً واحداً، بما في ذلك ما يرد داخل السجلات المضمَّنة، أما ip4 وip6 وall فلا تكلّف شيئاً. الاستعلام الحادي عشر يعني permerror، وكثير من الخوادم تعامل النطاق حينها كأنه بلا SPF صالح. يحسب الفاحص الاستعلامات على السلسلة كلها ويُدرج كل ما بعد العاشر دون إرساله.

ما الفرق بين -all و~all و?all في نهاية سجل SPF؟

عنصر all في آخر السجل يحدد مصير المرسِل غير المذكور فيه: ‎-all يطلب الرفض (fail)، و‎~all يطلب القبول مع التعليم كمشبوه (softfail)، و‎?all محايد بلا حكم، أما ‎+all فيُنجح كل خوادم الإنترنت. ومع DMARC بسياسة quarantine أو reject يصغر الفرق بين ‎-all و‎~all لأن DMARC هو الذي يقرّر، أما ‎+all فلا يكون آمناً أبداً.

هل يجوز أن يكون للنطاق سجلّا SPF؟

لا. ينصّ القسم 4.5 من RFC 7208 على أن الخادم الذي يجد أكثر من سجل TXT يبدأ بـ v=spf1 عند الاسم نفسه يعيد permerror. ادمج عناصر السجلين في سجل واحد — مثلاً سجل واحد يضم عنصرَي include — واحذف الآخر.

لماذا يصل بريدي مع أن الفاحص يُظهر permerror؟

تتعامل الخوادم المستقبِلة مع سجل SPF المعطوب بطرق مختلفة: كثير منها يعامله كأنه غير موجود، وبعضها يتجاهل SPF ويعتمد على DKIM، وقلّة ترفض الرسالة. والبريد الموقّع بـ DKIM قد ينجح في DMARC رغم ذلك. ومع هذا يستحق الخطأ الإصلاح، لأن جزء SPF من مصادقة بريدك لا يؤدي حالياً أي دور.

هل يُرسَل السجل الذي ألصقه إلى أي جهة؟

لا. يُحلَّل السجل الملصوق في متصفحك دون أي استعلام، ولذلك لا تُتتبَّع أهداف include وredirect فيه، ولا تُحسب إلا عناصر الاستعلام المكتوبة في السجل نفسه. افحص النطاق المنشور لترى السلسلة كاملة.

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

SPF ‏(RFC 7208) سجل TXT عند النطاق الذي تستخدمه الرسالة في مغلّف SMTP — أي عنوان MAIL FROM الذي تسجّله الخوادم المستقبِلة باسم Return-Path — أو في اسم HELO. يقيّم الخادم المستقبِل العناصر من اليسار إلى اليمين: يقارن ip4 وip6 عنوان الاتصال بنطاق عناوين، ويقارنه a وmx بعناوين النطاق أو خوادم بريده، ويسأل include هل ينجح SPF لنطاق آخر، وأول تطابق يحسم النتيجة بحسب مؤهِّله. أما redirect= فيُحيل القرار إلى سجل آخر إذا لم يتطابق شيء ولم يكن في السجل عنصر all.

للحدّ من عمل الخادم المستقبِل يسمح القسم 4.6.4 بعشرة عناصر على الأكثر تستدعي استعلامات DNS — include وa وmx وptr وexists وredirect — في التقييم كله، وباستعلامين فارغين على الأكثر، وتجاوز أيّ منهما permerror. ويتتبّع الفاحص كل عنصر في السجلات المنشورة: يحسب الاستعلامات بالترتيب الذي سيصادفها به الخادم المستقبِل، ويحلّ أهداف include وredirect وعناوين عناصر a وmx، ويُدرج ما بعد العاشر دون إرساله. ولأن الخادم المستقبِل يتوقف عند أول عنصر يتطابق (القسم 4.6.2)، فالعدد هو أقصى ما يمكن أن يسببه أي مرسِل من استعلامات، أما بريد خادم مذكور في أول السجل فيكلّف أقل. ويعتمد ptr وexists على عنوان الاتصال أو على الماكرو، فيُحسبان ولا يُحَلّان.

تُشتق النتيجة من هذا المسار: «فيه أخطاء» عند وقوع permerror أو عندما يُنجح ‎+all كل الخوادم ولو عبر include، و«يعمل مع تحذيرات» عند الإخفاقات المؤقتة أو ‎~all أو ‎?all أو غياب all أو أي تحذير آخر، و«لا مشكلات» فقط لسجل ينتهي بـ ‎-all ولا شيء يُذكر فيه.

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

تُقرأ السجلات عبر محلّل Cloudflare العام من خادم متقن على حافة Cloudflare، وقد لا يظهر تعديل أجريته قبل دقائق حتى تنتهي صلاحية الإجابات المخزّنة.

يقيّم الفاحص السياسة المنشورة لا رسالة بعينها: لا يستطيع أن يقول هل ينجح عنوان إرسال محدد، لأن ptr وexists والماكرو تحتاج ذلك العنوان، فتُحسب ولا تُحَلّ.

عدد الاستعلامات هو أقصى ما يمكن أن يسببه أي مرسِل: يتوقف الخادم المستقبِل عند أول عنصر يتطابق، فيكلّف بريد الخادم المذكور مبكراً استعلامات أقل، والسجل الذي يتجاوز الحد لا يعطي permerror إلا للمرسِلين الذين يبلغون الاستعلام الحادي عشر.

في السجل الملصوق يُحلَّل السجل نفسه فقط، ولا تُتتبَّع أهداف include وredirect، فلا يظهر العدد الكلي للاستعلامات ومشكلات السجلات المضمَّنة إلا في الفحص المباشر.

تختلف الخوادم المستقبِلة في صرامة تطبيق الحدود وفي معاملة permerror؛ والنتيجة تصف RFC 7208 لا السياسة المحلية لكل خادم.

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

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

المراجع