"سجل SPF غير موجود" — لكنك تمتلكه؟ الأسباب الخمسة الحقيقية (2026)

نُشر 2026-07-08

الأرقام حتى 2026-06-29 · المنهجية v7. بيانات تعداد مجمّعة عبر 261 مليون نطاق مُقيَّم. اطّلع على كيفية تقييمنا.

إذا أفادت أداةُ الفحص بأن “سجل SPF غير موجود” لكنك متأكد من نشره، فالسجل في الغالب مخفيٌّ لا مفقود: 1,013,416 نطاق — أي نحو واحد من كل 138 من تلك التي تحاول نشر SPF — ينشر سجلَّين أو أكثر من سجلات SPF، وهو خطأ PermError (وفق RFC 7208 §3.2) تُبلّغ عنه كثير من أدوات الفحص بوصفه “غير موجود”، وفق تعداد Defaults.Exposed الشامل لـ 261 مليون نطاق.

ثمة خمسة أسباب حقيقية يمكن إصلاحها في جلسة واحدة: خادم خاطئ، أو سجل مكرّر، أو نوع DNS خاطئ أو اقتباسات تالفة، أو خوادم أسماء غير متّسقة، أو تعارض طول/CNAME. فيما يلي: اختبار الستين ثانية لكل سبب، مرتّبة بحسب أولوية الفحص، ثم خطوات الإصلاح.

هل أنت متأكد فعلاً من وجود السجل؟

ابدأ بالاحتمال غير المريح، إذ هو الأكثر شيوعاً إلى حدٍّ بعيد: من بين 261,086,232 نطاق مُقيَّم في تعداد Defaults.Exposed، 121,145,609 — بنسبة 46.4% — لا تملك سجل SPF على الإطلاق. كثيرٌ من حالات “لكنني أعددتُ هذا” تبيّن أنها سجل أُضيف إلى منطقة مرحلة الاختبار أو إلى مزوّد DNS قديم لم يعُد مرجعياً. تحقّق من مزوّد DNS الذي تشير إليه خوادم الأسماء فعلياً (وهو في الغالب ليس المسجِّل) بحثاً عن سجل TXT يبدأ بـ v=spf1. إذا لم يكن موجوداً حقاً، فاتجه مباشرةً إلى إصلاح سجل SPF دون إضاعة الوقت في التحقيق.

كيف تفحص سجل SPF بصورة صحيحة؟

تستعلم أدوات الفحص على الويب عبر محلّل التخزين المؤقت الخاص بها. لرؤية الحقيقة، اسأل خادم الأسماء المرجعي لنطاقك مباشرةً:

# ابحث عن خوادم الأسماء المرجعية
dig NS yourdomain.com +short

# اسأل أحدها مباشرةً عن سجلات TXT
dig TXT yourdomain.com @ns1.yourdnshost.com +short

على Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

قاعدتان للتفسير: أولاً، عُدّ الأسطر التي تبدأ بـ v=spf1 — العدد مهمٌّ بقدر المحتوى. ثانياً، تأكّد من أنك استعلمتَ عن الاسم الصحيح: يقيّم المستقبلون SPF وفق النطاق الوارد في Return-Path (RFC5321.MailFrom، المرسِل الفعلي في الظرف) — لا عنوان From الذي يراه المستلمون. إذا كانت أداتك للرسائل الإخبارية ترسل البريد عبر bounce.yourdomain.com، فإن سجلاً مثالياً على النطاق الرئيسي ليس السجل الذي يبحث عنه المستقبلون.

ما الأسباب الخمسة الحقيقية؟

#	السبب	اختبار الستين ثانية	الحل
1	السجل في مضيف خاطئ (نطاق فرعي مقابل النطاق الرئيسي)	استخدم `dig TXT` على النطاق الدقيق الوارد في Return-Path	انشر السجل على الاسم الذي يرسل فعلياً
2	سجلَّان أو أكثر من سجلات `v=spf1` = PermError	يعيد `dig TXT` سطرَّين أو أكثر تبدأ بـ `v=spf1`	ادمجهما في سجل واحد بالضبط
3	نُشر كنوع 99، أو اقتباسات تالفة	تحقّق من نوع السجل وعلامات الاقتباس الزائدة	أعِد النشر كسجل TXT نظيف واحد
4	تخزين مؤقت قديم / خوادم أسماء غير متّسقة	استعلم كل خادم NS مباشرةً وقارن الإجابات	أصلح خادم الأسماء المتأخر وانتظر انتهاء TTL القديم
5	تجزئة لأكثر من 255 حرفاً أو تعارض CNAME	ابحث عن أجزاء مكسورة أو CNAME بنفس الاسم	اترك المزوّد يجزّئ السلاسل بصورة صحيحة؛ انقل السجل بعيداً عن الاسم المرتبط بـ CNAME

البيانات حتى 2026-06-29.

1. هل السجل في المضيف الخاطئ؟

المثال الكلاسيكي: إضافة SPF على mail.yourdomain.com بينما يدّعي البريد القدوم من yourdomain.com، أو العكس. لا يرث SPF إلى الأسفل — سجلٌ على النطاق الرئيسي لا يقول شيئاً عن النطاقات الفرعية، والعكس صحيح. انشر على الاسم الدقيق الوارد في Return-Path. مزوّدٌ يرسل من نطاق bounce فرعي خاص به يحتاج سجلاً على ذلك النطاق الفرعي — في الغالب CNAME أو TXT يوفّره المزوّد (يوضح دليل إعداد SPF على GoDaddy مواقع هذه الحقول).

2. هل لديك سجلَّا SPF؟

السبب الرئيسي، ورسالة الخطأ الأكثر إضلالاً في مصادقة البريد الإلكتروني. RFC 7208 §3.2 صريح: يجب أن يكون لدى النطاق سجل SPF واحد بالضبط. وجود سجلَّين أو أكثر يُعدّ PermError — يتعامل المستقبلون مع SPF الخاص بك على أنه باطل. بعض الأدوات تُبلّغ عن ذلك بدقة (“سجلات متعددة وُجدت”)؛ وأخرى تُبلّغ عن الأثر الصافي: لم يُعثر على سجل SPF صالح. ترى سجلاً في لوحتك وتستنتج أن الأداة معطّلة. إنها ليست كذلك — لديك سجلٌ زائد.

وجد التعداد 1,013,416 نطاقاً يحمل سجلَّين أو أكثر من سجلات SPF — نحو واحد من كل 138 من النطاقات التي تحاول نشر SPF — كل واحدة بـ SPF معطَّل فعلياً. يحدث هذا عادةً أثناء تغيير مزوّد: يضيف معالج الإعداد الخاص بالمزوّد الجديد سجلاً جديداً بدلاً من تعديل القديم. الحل هو الدمج لا سجلٌ ثانٍ أبداً: اجمع كل شيء في سطر v=spf1 … ~all واحد واحذف الباقي. يشرح تقريرنا سجلَّا SPF يساويان لا شيء كيف وصل مليون نطاق إلى هذا الوضع؛ إذا بدأ الأمر بعد انتقال، راجع توقّف SPF بعد تغيير مزوّد البريد. أثناء الدمج، لا تجمع كل include: عشوائياً — فكل واحدة تكلّف بحثاً في DNS وتُقرّب من الحد الصارم البالغ 10 بحثاً، مما قد يستبدل “غير موجود” بـ PermError: عمليات بحث DNS أكثر من اللازم.

3. هل نشرتَ النوع الخاطئ — أم أن واجهة الأداة أتلفته؟

كان SPF مبكراً يملك نوع سجل DNS خاصاً به (النوع 99، يُسمّى حرفياً “SPF”). أُلغي هذا: يتطلب RFC 7208 نوع TXT، ولا يستعلم المستقبلون عن النوع 99. بعض لوحات DNS لا تزال تعرض “SPF” في قائمة نوع السجل؛ اختره وسجلك حقيقيٌّ ومنسَّق جيداً وغير مرئي. تحقّق من عمود النوع وأعِد النشر كـ TXT.

النسخة الأكثر خفاءً هي الاقتباس. لصق قيمة محاطة بعلامات اقتباس في حقل يُضيف علامات اقتباسه الخاصة ينتج ""v=spf1 …"" — التي لم تعُد تبدأ بـ v=spf1، لذا بالنسبة للمتحقّق فهي غير موجودة. مخرجات dig تُظهر الحقيقة؛ لوحة DNS كثيراً ما تُخفيها من العرض.

4. هل “لا تزال تنتشر” فعلاً؟

“أعطها 24–48 ساعة للانتشار” هي النصيحة الأكثر إفراطاً في مجال DNS. الانتشار ليس إلا انتهاء صلاحية التخزين المؤقت: بمجرد انتهاء TTL السجل (عادةً ساعة، نادراً أكثر من 24 ساعة)، يستطيع كل محلّل رؤية الإجابة الجديدة. لا يزال غير موجود بعد 24 ساعة؟ ليس الانتشار هو السبب.

المشكلتان الحقيقيتان: التخزين المؤقت السلبي — محلّلٌ بحث عنك قبل إضافة السجل يخزّن إجابة “لا يوجد سجل” حتى انتهاء صلاحية TTL السلبي — وخوادم الأسماء غير المتّسقة بعد انتقال، حيث لا يزال النطاق يُدرج خوادم أسماء المزوّد القديم جانب الجديدة ونصف العالم يقرأ منطقة لا تحرّرها بعد الآن. استعلم كل خادم أسماء مُدرج مباشرةً؛ إذا اختلفت الإجابات فقد عثرتَ على المشكلة. أصلح تفويض NS في المسجِّل لتجعل المزوّد الذي تحرّره فعلياً مرجعياً وحيداً.

5. هل السجل طويل جداً أو يعوقه CNAME؟

تبلغ سلسلة واحدة في سجل TXT 255 حرفاً كحدٍّ أقصى. سجلات SPF الأطول مشروعة لكنها يجب أن تُقسَّم إلى سلاسل متعددة بين علامات اقتباس داخل سجل واحد — وكثيراً ما تُخطئ واجهات مزوّدي DNS في التقسيم، فتقطع القيمة أو تكسرها في منتصف آلية بحيث لم يعُد يمكن تحليلها. إذا كان سجلك طويلاً، تحقق من مخرجات dig بحثاً عن قيمة تنتهي فجأة.

منفصلاً عن ذلك، يحظر DNS وجود سجل TXT على اسم يحمل بالفعل CNAME. إذا كان mail.yourdomain.com عبارة عن CNAME لمزوّدك، لا يمكنك أيضاً وضع SPF هناك — بعض اللوحات تقبله ثم تُقدّم CNAME فقط. ضع السجل حيث يشير CNAME (إذا كنت تتحكم فيه)، أو أعِد الهيكلة بحيث لا يحمل الاسم المرسِل CNAME. مزوّدون يتعاملون مع TXT بصورة نظيفة يُيسّران الأمرَّين — راجع دليل إعداد SPF على Cloudflare.

كيف تُصلحه خطوةً بخطوة؟

شغّل الفحص المجاني على defaults.exposed — سيقرأ سجلات DNS المباشرة ويُخبرك بأيّ الحالات الخمس تنطبق قبل أن تلمس أي إعداد.
تأكّد من خوادم الأسماء المرجعية (dig NS) وتحقّق من اتفاقها.
استعلم TXT من الخادم المرجعي للنطاق الدقيق الوارد في Return-Path.
عُدّ أسطر v=spf1: صفر → انشر سجلاً واحداً؛ اثنان أو أكثر → ادمج في سجل واحد.
تحقّق من أن النوع TXT، والقيمة تبدأ بالضبط بـ v=spf1، وأنه لا توجد علامات اقتباس زائدة أو اقتطاع.
انتظر TTL واحداً، ثم أعِد الفحص للتأكد من حل السجل بصورة نظيفة في كل مكان.

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

لماذا يقول مدقّق الاختبار “غير موجود” بينما أرى السجل في لوحة DNS الخاصة بي؟ في الغالب السبب 2 أو 4: سجل v=spf1 ثانٍ يجعل كليهما باطلَّين — وهو PermError تُبلّغ عنه بعض الأدوات بوصفه “غير موجود”، وهي الحالة التي 1,013,416 نطاق فيها حتى 2026-06-29 — أو لوحتك ليست DNS المرجعية فعلياً.

كم من الوقت حتى يرى المدققون الإصلاح الخاص بي؟ TTL واحد — عادةً ساعة، وبحد أقصى 24 ساعة. بعد ذلك، “الانتشار” ليس التفسير؛ أعِد فحص الأسباب الخمسة بدءاً من اتساق خوادم الأسماء.

هل يجب أن أستخدم نوع سجل “SPF” الذي تعرضه لوحة DNS؟ لا. النوع 99 مُلغى؛ يتطلب RFC 7208 TXT فقط. سجل النوع 99 غير مرئي للمستقبلين الحديثين.

السجل موجود الآن — لماذا لا يزال بريدي يفشل SPF؟ لأن SPF يُفحص وفق نطاق Return-Path لا ترويسة From، ويجب أن يُدرج السجل فعلياً الخوادم التي ترسل عنك. الوجود خطوةٌ أولى؛ يغطّي دليل إصلاح سجل SPF خطوات النجاح في الاختبار.

هل غياب سجل SPF شائعٌ فعلاً؟ نعم — 121,145,609 نطاق، بنسبة 46.4% من 261,086,232 المُقيَّمة في تعداد Defaults.Exposed (حتى 2026-06-29)، لا تنشر SPF على الإطلاق. الغياب هو الحالة الافتراضية للإنترنت.

أرسل التقرير إلى المالك

بمجرد حل السجل بصورة نظيفة، أعِد الفحص وأرسل التقرير المُقيَّم إلى مالك النشاط التجاري أو العميل الذي ينتمي إليه النطاق. يوضّح التقرير بلغة بسيطة ما كان معطّلاً وما أصلحته وأين يقف النطاق الآن — وهو بالضبط الدليل الذي سيُطلب منهم تقديمه عند تجديد تأمين الأمن السيبراني واستبيانات أمان الموردين. التقرير هو إيصال العمل المنجز.

افحص سجل SPF الخاص بك مجاناً

اعرف في أيّ الحالات الخمس لـ”غير موجود” يقع نطاقك — بصورة خاصة وللمالك فقط.

افحص نطاقك ← · إصلاح SPF ← · توقّف SPF بعد تغيير مزوّد البريد ← · كيف نقيّم ← · بيانات مجمّعة فقط. البيانات مخزّنة ومعالَجة في الاتحاد الأوروبي.