Defaults.Exposed › التقارير

لماذا يفشل SPF لديّ؟ مشكلة 10 استعلامات DNS للمؤسسات الأوروبية التي تستخدم أدوات SaaS (2026)

نُشر 2026-07-09

الأرقام بتاريخ 2026-06-29 · المنهجية الإصدار 7. بيانات إجمالية من تعداد شامل لـ 261 مليون نطاق مُقيَّم. اطّلع على طريقة التقييم.

عندما يفشل SPF لدى مؤسسة تستخدم أدوات SaaS في المملكة المتحدة أو الاتحاد الأوروبي، فإن السبب الأرجح هو قاعدة واحدة من معيار RFC لم تضطر من قبل للتفكير فيها: بمجرد تجاوز 10 استعلامات DNS، لا يُعيد SPF “فشلاً” — بل يُعيد PermError، مما يعني أن السجل يُعامَل كأنه غير موجود أصلاً. تجاوز ما لا يقل عن 797,263 نطاقاً هذا الحد بالفعل. وثمة 2,119,539 نطاقاً آخر يقف عند 9–10 استعلامات تماماً — أداةٌ واحدة جديدة تكفي لإيقاعها في الهاوية ذاتها.

لماذا ينكسر SPF عند إضافة أداة SaaS جديدة؟

يعمل SPF عبر إدراج خوادم البريد المصرَّح لها بالإرسال باسم نطاقك. لا تُشغّل المؤسسات الحديثة خوادم بريد خاصة بها في الغالب — بل تستخدم Google Workspace للبريد الداخلي، وMailchimp للحملات التسويقية، وHubSpot لتسلسلات المبيعات، وPipedrive لتواصل إدارة علاقات العملاء. كل منصة تمنحك سطر include: تضعه في DNS الخاص بك.

المشكلة: كل include: هو في حد ذاته استعلام DNS. وكل سجل داخل ذلك الـ include قد يُطلق استعلامات إضافية بصورة متكررة. يضع معيار RFC 7208 §4.6.4 حداً أقصى صارماً يبلغ عشرة استعلامات. وعند تجاوزه، يتوقف خادم البريد المستقبِل عن التقييم ويُعيد PermError — وهو ليس فشلاً ناعماً ينتهي في مجلد البريد المزعج، بل يعني أن سجل SPF الخاص بك يُعامَل كأنه غير موجود. وبذلك يفشل التحقق من هوية المُرسِل على مستوى SPF.

لن ترى هذا في لوحة تحكم DNS لديك. لا يبدأ العدّاد في العمل إلا أثناء التقييم الحي. يمكنك أن يكون لديك ثلاثة أسطر include: فقط في سجلك المرئي وتجد نفسك في عمق اثني عشر استعلاماً، لأن سجل SPF لكل مزوّد يسحب بدوره sub-includes خاصة به.

كم عدد النطاقات التي تجاوزت الحد بالفعل؟

ما لا يقل عن 797,263. هذا هو العدد الذي تم حسابه بعد تتبع كل هدف include: في SPF المُرجَع إليه 100 مرة أو أكثر — 10,842 هدفاً مختلفاً يغطي 95.2% من جميع مراجع include — وتسعير السلسلة الكاملة لكل نطاق. يجد العدّ السطحي (ما تجده بعدّ الأسطر المرئية فقط في السجل) نحو 7,958. الرقم بعد تسعير السلسلة أكبر بمقدار 100 مرات، لأن معظم الضرر يكمن داخل أهداف include غير المرئية.

الوضع الأكثر احتمالاً للتأثير على مؤسسة أوروبية:

مزودو الاستضافة الأوروبيون وإعدادات SPF الضعيفة الافتراضية

مزود الاستضافة الذي بدأت معه مهم — لأن بعضهم يُعيّن إعدادات SPF افتراضية تستهلك عدة استعلامات من رصيدك العشرة قبل توصيل أي أداة SaaS واحدة.

من بين أكبر مزودي الاستضافة التي تستخدمها النطاقات الأوروبية في تعداد بياناتنا:

تبرز IONOS بشكل لافت: 1.0% فقط من النطاقات المستضافة على IONOS تمتلك DMARC مُطبَّقاً، مما يعني أن الغالبية العظمى لا تملك أي مصادقة هوية مُرسِل ذات معنى على الإطلاق. أداء نطاقات OVH أفضل من حيث إعداد SPF الصارم (43.7%) لكنه يتراجع إلى 2.2% على مستوى تطبيق DMARC — وSPF وحده، دون DMARC الذي يربطه بعنوان From:، لا يحمي إلا الغلاف، لا ما يراه المستلم فعلاً.

Microsoft 365 هو الاستثناء الإيجابي: 85.0% من النطاقات المستضافة على Microsoft تستخدم SPF الصارم، ويعود ذلك إلى أن معالج تدفق بريد Microsoft يُعيّن -all افتراضياً. أما Google Workspace فيُعيّن ~all (softfail) افتراضياً، مما يترك 92% من نطاقاتها دون حماية صارمة.

كيف تشخّص فشل SPF في أقل من 60 ثانية

الفحص الأسرع هو أداة مجانية تُقيّم سلسلة الاستعلامات الكاملة — لا السجل المرئي فحسب. شغّل الأمر nslookup -type=TXT yourdomain.com من سطر الأوامر وعُدّ كل include: تراه. ثم ابحث عن كل سجل من تلك السجلات وعُدّ ما بداخله. إذا نفدت أصابعك قبل نفاد الـ includes، فأنت في منطقة الخطر.

النهج الأكثر موثوقية: افحص نطاقك هنا — يُقيّم الماسح السلسلة المُحلَّلة الكاملة، يُشير إلى PermError، ويُريك أي الآليات تستهلك ميزانية الاستعلامات الخاصة بك.

ثلاثة نتائج تشخيصية:

• PermError — لقد تجاوزت العشرة بالفعل. كل بريد إلكتروني ترسله يفشل في فحص SPF عند المستلم.
• عند 9–10 استعلامات — أنت على حافة الهاوية. التكامل التالي مع أي SaaS سيتجاوز بك الحد.
• Softfail (~all) بدلاً من hardfail (-all) — أنت دون الحد لكن السجل مُعيَّن بتساهل مفرط لا يوفر حماية حقيقية. اطّلع على تقرير الإعداد الخاطئ لـ SPF للصورة الكاملة حول -all مقابل ~all.

كيف تُصلح SPF عند استخدام أدوات SaaS متعددة

ثمة ثلاثة مناهج، مرتبة حسب الديمومة:

1. التدقيق والتقليص. ابدأ بإدراج كل include: في سجلك الحالي. احذف أي منصة لم تعد تستخدمها — مزودو خدمة البريد الإلكتروني القدامى، أدوات CRM من عقود سابقة، منصات اختبرتها ثم تركتها. هذا مجاني وكثيراً ما يستعيد لك عدة استعلامات. كل include: محذوف قد يُزيل 1–3 استعلامات فرعية.

2. تسطيح سجل SPF. يُحلّل SPF flattening جميع أهداف include: إلى نطاقات IP الأساسية ويكتبها مباشرة في سجلك كآليات ip4: وip6:. آليات IP لا تُطلق استعلامات، لذا يمكن لسجل مُسطَّح أن يُدرج عشرات مصادر الإرسال ويبقى عند صفر استعلامات. العيب: يجب إعادة التسطيح كلما حدَّث مزوّد عناوين IP الإرسال الخاصة به، وهو أمر يحدث دون إشعار. تستخدم معظم المؤسسات خدمة تسطيح SPF مدفوعة (PowerDMARC، EasyDMARC، Dmarcian وغيرها تقدم هذا) أو تبني سير عمل للمراقبة.

3. استخدام وحدات ماكرو SPF. تتيح لك وحدات ماكرو RFC 7208 بناء سجلات تُجري استعلام DNS واحداً لكل فحص وتُجيب ديناميكياً، بدلاً من سلسلة من includes. تتطلب وحدات الماكرو دعم استضافة DNS وبعض الجهد في التنفيذ، لكنها الحل المعماري النظيف للمؤسسات ذات المُرسِلين المتعددين عبر SaaS.

بعد إصلاح SPF، اقرنه بـ تطبيق DMARC — فـ SPF وحده دون DMARC يُصادق فقط على مُرسِل الغلاف، لا عنوان From: في الرأسية الذي يراه المستلمون.

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

لماذا يجتاز سجل SPF الخاص بي أداة DNS الخاصة بي لكنه لا يزال يفشل في رؤوس البريد الإلكتروني؟ معظم أدوات بحث DNS تعدّ فقط الآليات المرئية في سجلك الخاص، لا الاستعلامات الفرعية التي تُطلقها تلك الآليات. يمكنك أن يكون لديك سطرا include: فقط وتتجاوز الحد إذا كان سجل كل مزوّد يحتوي على عدة استعلامات إضافية. فقط أداة تسعير السلسلة (أو خادم البريد المستقبِل) تعدّ العمق الكامل. افحص نطاقك لترى العدد الحقيقي للسلسلة.

هل يعني فشل SPF أن رسائلي الإلكترونية ستذهب إلى البريد المزعج؟ PermError (استعلامات كثيرة جداً) يعني أن الشق الخاص بـ SPF في المصادقة يُعيد نتيجة غير محددة — غياب فعلي. يُقيّم DMARC كلاً من SPF وDKIM؛ إذا اجتاز DKIM، يمكن لـ DMARC أن يجتاز رغم PermError في SPF. إذا لم يجتز أيٌّ منهما، يفشل DMARC، والنتيجة تعتمد على سياسة DMARC الخاصة بك. عند p=none، تُسلَّم الرسائل لكن يُسجَّل الفشل. عند p=quarantine أو p=reject، تُفلتر الرسائل أو تُرفض. أصلح SPF حتى لا تعتمد على DKIM وحده.

كم عدد الاستعلامات التي يستخدمها مكدّس SaaS نموذجي؟ يقع سجل SPF عند المئين التاسع والتسعين في تعداد بياناتنا عند 9 استعلامات — عند الحد تماماً — قبل إضافة أي شيء. يُضيف سجل Google Workspace من 3 إلى 4 استعلامات؛ Mailchimp يُضيف 1–2؛ HubSpot يُضيف 1–3 حسب تكوينه الحالي. ثلاثة أدوات رئيسية مع إعداد مزود الاستضافة الافتراضي كثيراً ما يكفي للتجاوز.

هل تسطيح SPF آمن؟ نعم، شريطة الحفاظ عليه محدَّثاً. التسطيح يُحوّل سلاسل include: إلى نطاقات IP ثابتة — إذا غيّر أحد المزوّدين عناوين IP الإرسال ولم تُعد التسطيح، ستبدأ في رفض بريدهم. تستخدم معظم المؤسسات خدمة تسطيح مُدارة تراقب تغييرات IP بدلاً من صيانته يدوياً.

كان SPF على هذا الحال منذ سنوات — لماذا يفشل الآن فجأة؟ لأن مزوّديك حدَّثوا سجلات SPF الخاصة بهم، لا سجلاتك أنت. في كل مرة تُضيف فيها منصة SaaS نطاق IP إرسال جديداً أو تدمج include إضافياً، يرتفع تكلفة سلسلتك دون أي تغيير من طرفك. يُقيَّم حد 10 استعلامات حياً عند استلام الرسالة، لذا يمكن لتغيير مزوّد يوم الثلاثاء صباحاً أن يُعطّل SPF لديك بعد ظهر الثلاثاء.

هل يُحسّن إصلاح SPF إمكانية تسليم البريد الإلكتروني؟ يُزيل مصدراً من مصادر فشل المصادقة، وهو شرط أساسي للتسليم المتسق — لا سيما منذ أن بدأت Google وYahoo في تطبيق محاذاة DMARC للمُرسِلين المجمّعين. SPF وحده ليس الصورة الكاملة: اقرنه بـ DKIM وDMARC لمصادقة بريد إلكتروني كاملة.

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

إذا لم تكن متأكداً مما إذا كان سجل SPF الخاص بك يتجاوز حد الاستعلامات — أو مُعيَّناً بضعف لا يحمي نطاقك — أجرِ فحصاً مجانياً. يُقيّم السلسلة المُحلَّلة الكاملة ويُريك بالضبط أين تُستنفَد الميزانية.

افحص نطاقك ← · أصلح SPF ← · تقرير SPF PermError ← · تقرير الإعداد الخاطئ لـ SPF ← · نموذج نضج اعتماد SPF ← · أصلح DMARC ← · بيانات إجمالية فقط. تُخزَّن البيانات وتُعالَج في الاتحاد الأوروبي.