Defaults.Exposed › الإصلاحات › Guides
SPF PermError: كيف تُصلح "عمليات بحث DNS كثيرة جداً" دون أن تكسر بريدك الإلكتروني (2026)
نُشر 2026-07-08
الأرقام بتاريخ 2026-06-29 · المنهجية v7. بيانات إحصاء مجمّعة عبر 261 مليون نطاق مُصنَّف. اطلع على طريقة التصنيف.
ما لا يقل عن 797,263 نطاق يتجاوز حد SPF البالغ 10 عمليات بحث DNS، وفقاً لإحصاء Defaults.Exposed لـ 261,086,232 نطاق — من أصل 139 مليون ناشر SPF. عند تجاوز العشر عمليات يتوقف المستقبِل ويُعيد PermError: سجل SPF لديك باطل، ويعدّ DMARC خطأ PermError رسوباً.
للإصلاح ترتيبٌ صارم وكثير من الأدلة تعكسه. عُدّ عمليات البحث الفعلية المحلولة؛ احذف includes المعطلة وغير المستخدمة — هذا وحده يُصلح معظم السجلات؛ انقل المرسلين بالجملة إلى نطاقات فرعية بميزانية SPF خاصة؛ ولا تلجأ إلى التسطيح إلا كملاذ أخير وبإعادة تسطيح مؤتمتة، لأن التسطيح الثابت يتعفن ويُعطل التسليم بصمت.
ماذا يعني “SPF PermError: عمليات بحث DNS كثيرة جداً”؟
يُحدد RFC 7208 §4.6.4 سقفاً لكل فحص SPF عند 10 عمليات بحث DNS. عند التجاوز يتوقف المستقبِل ويُعيد PermError — يُعامَل السجل بأكمله كسجل معطل، لا الجزء المتجاوز فحسب. يُضيف المقطع نفسه سقفاً ثانياً أقل شهرة: ما أقصاه “void lookups” × 2 (استعلامات لا تُعيد إجابة أو NXDOMAIN)، فمجرد إدخالَي include: معطلَين لخدمات ملغاة قد يُبطل سجل SPF وحدهما.
العواقب أسوأ من “لا SPF”: يعدّ DMARC خطأ PermError رسوباً في SPF، فالنطاق الذي يُعطل سجله الخاص يبقى غير موثَّق في ركيزة SPF لكل تقييم DMARC. وإن لم يكن DKIM مُعداً أو تعطَّل في المسار، يرسب البريد في DMARC كلياً.
رقم واحد في الإحصاء يكشف قسوة هذه الحالة: 112,215 نطاق ينشر سجل -all صارم باطل بسبب تجاوز عمليات البحث — من أصل 54,655,923 نطاق ينشر -all أصلاً. أصحابها أتمّوا الجزء الصعب — اختاروا الإنهاء الصارم — وzinclude زائد واحد أوقف السجل بأكمله. يبدون صارمين؛ لكنهم معطوبون. لصورة البيانات الكاملة انظر تقرير SPF PermError.
لماذا تعطَّل SPF دون أن أغيّر شيئاً؟
لأن الميزانية تستهلكها سجلات الآخرين في الغالب. كل include: تُقيَّم بصورة تعاودية وكل آلية بحث بداخلها تُحتسب ضمن عشرتك. سطر واحد في لوحة DNS قد يكلف أربع أو خمس عمليات بحث بعد الحل. يُضيف مزوّد واحد include إضافية ويموت سجل SPF لديك دون أن تُغيّر حرفاً في منطقتك.
المنصات الكبرى ليست المشكلة: سوّى Google وMicrosoft سجلات SPF الخاصة بهما — _spf.google.com و spf.protection.outlook.com تتوسع إلى قوائم IP صريحة لا تكلف أي عمليات بحث داخلية (مُتحقق منه بمقابلة DNS الحي، يوليو 2026). الانفجارات الحقيقية تأتي من سلاسل includes لوحة الاستضافة المتشعبة عدة طبقات، ومن تراكم SaaS المعقول — صندوق بريد ونشرة وإدارة علاقات عملاء ومكتب مساعدة، كل منها “include واحد فقط”. لا أحد يُضيف الحادية عشرة بقصد؛ إنها حصيلة قرارات معقولة. لهذا الحافة مزدحمة: 2,119,539 نطاق يقف عند 9-10 عمليات بحث محلولة بالضبط — تقريباً 1 من كل 66 من ناشري SPF، سليم اليوم، باطل يوم يلصق أحدهم include واحداً إضافياً. سجل SPF عند الشريحة 99% يحلّ بالفعل إلى 9 عمليات بحث. إن كانت بنيتك ثقيلة بالـ SaaS، يُغطي دليل SPF الفاشل لأدوات SaaS النسخة لكل مورد على حدة.
أي أجزاء سجل SPF تُحتسب عمليات بحث DNS؟
| الآلية | تكلفة البحث | ملاحظة |
|---|---|---|
include: | 1 + كل ما بداخلها بصورة تعاودية | مصدر معظم الانفجارات |
a | 1 لكل منها | حتى a المجرد لنطاقك |
mx | 1 لكل منها (بالإضافة إلى عمليات بحث A لمضيفي MX) | تُنسى كثيراً |
ptr | 1 — وموقوف منذ 2014 | احذفه في أي حال |
exists: | 1 لكل منها | نادرة |
redirect= | 1 + محتويات السجل الهدف | تُحتسب مثل include |
ip4: / ip6: | 0 | لهذا يُجدي التسطيح |
-all / ~all / ?all | 0 | المُحدِّد مجاني |
عُدّ المجموع المحلول لا الأسطر المرئية. أربع includes قد تكون أربع عمليات بحث أو أربع عشرة.
كيف أُصلح “عمليات بحث DNS كثيرة جداً” دون أن أكسر البريد؟
- شغّل الفحص المجاني قبل أن تلمس DNS. يُحلل السلسلة الكاملة ويُظهر عدد عمليات البحث الفعلية، فتُصلح المشكلة الحقيقية لا السجل كما يبدو في لوحتك. (إن قال إنه لا سجل SPF لديك، فتلك حالة مختلفة — انظر “سجل SPF غير موجود”.)
- احذف أولاً includes المعطلة وغير المستخدمة. الأداة التي تخليت عنها عام 2023، include المضيف القديم الناجية من الترحيل، المكررات، أي آلية
ptr. الـ includes المعطلة سُمية مزدوجة: تستهلك الميزانية وتكون المصدر المعتاد لـ void lookups. معظم السجلات المتجاوزة تعود دون 10 في هذه الخطوة وحدها. إن حمل سجلك آليات مزوّدك السابق، اتبع دليل تنظيف الترحيل. - تحقق أن كل include باقية تؤدي وظيفة. يُقيّم المستقبلون SPF مقابل نطاق Return-Path (RFC5321.MailFrom) لا ترويسة From — وكثير من أدوات SaaS تضع نطاق ارتداد المورد في Return-Path، فيصبح الـ include في سجلك بلا فائدة سوى استهلاك الميزانية. احتفظ بـ includes للخدمات التي تستخدم نطاقك Return-Path فحسب؛ وللباقي فعّل DKIM بنطاق مخصص من المورد.
- انقل المرسلين بالجملة إلى نطاقات فرعية. النشرات من
news.yourdomain.com، والبريد المعاملاتي منmail.yourdomain.com. كل نطاق فرعي يحصل على سجل SPF خاص بميزانية 10 عمليات بحث جديدة، ومشكلة في مجرى واحد لا تنزّ في الآخرين. - لا تُفكر في التسطيح إلا بعد ذلك — وبتسطيح مؤتمت فقط. انظر أدناه.
- أعد الفحص للتأكيد أنك بارتياح تحت 10 — استهدف هامشاً لا 10 بالضبط وإلا انضممت للتو إلى 2.1 مليون نطاق على حافة الهاوية. ثم اعمل على ما يُشير إليه الفحص في صفحة إصلاح SPF.
هل أُسطّح سجل SPF؟
التسطيح يستبدل includes بكتل ip4:/ip6: الأساسية التي لا تكلف أي عمليات بحث. يُجدي — وإن نُفِّذ يدوياً، فهو انقطاع تسليم مؤجَّل التفجير.
| النهج | عدد عمليات البحث | بمرور الوقت |
|---|---|---|
| التقليم + النطاقات الفرعية (الخطوات 2-4) | يعود عادةً تحت 10 | مستقر؛ المزوّدون يديرون IPs الخاصة بهم |
| التسطيح المؤتمت (خدمة أو مهمة مجدولة تُعيد الحل والنشر) | قريب من 0 | يتابع تغييرات IP المزوّد؛ آمن |
| التسطيح اليدوي لمرة واحدة | قريب من 0 — اليوم | يتعفن بصمت: المزوّدون يُدوّرون IPs والبريد الشرعي يبدأ بالرسوب في SPF دون ظهور أخطاء لديك |
يُدوّر المزوّدون IPs الإرسال بانتظام دون إعلان أحد. قائمة IP ثابتة صحيحة يوم تلصقها وخاطئة بصمت خلال أشهر — ولأن الرسوب يظهر كـ آخرين لا يستلمون بريدك تكتشفه متأخراً. إن أوصلك التقليم والنطاقات الفرعية دون الحد، أوقف هنا؛ لا تنسخ كتل IP طرف ثالث في سجلك كحل دائم.
الأسئلة الشائعة
هل يعني SPF PermError توقف تسليم بريدي؟ ليس فوراً — وهذا ما يجعله خطيراً. يعدّ DMARC PermError رسوباً في SPF، فيعتمد التسليم كلياً على DKIM؛ وإن كان DKIM غائباً أو تعطَّل في المسار، يرسب بريدك في DMARC. من أصل 139 مليون ناشر SPF في إحصائنا (بتاريخ 2026-06-29)، ما لا يقل عن 797,263 في هذه الحالة — معظمهم دون علم.
سجلي يحتوي أربعة includes فقط — كيف يتجاوز 10 عمليات بحث؟ تُحتسب الـ includes بصورة تعاودية: كل ما بداخل كل include (وبداخل includes ها) يُحمَّل على ميزانيتك، فأربعة أسطر مرئية قد تحلّ إلى أربع عشرة عملية بحث. عُدّ بأداة حل لا بالعين — فحلّ السلاسل هو ما مكّن تقرير PermError من إيجاد ~100× نطاقات معطوبة أكثر مما تُظهره العدادات السطحية.
أُنهي سجلي بـ -all — أليس هذا حماية كافية؟
فقط إن نوجد التقييم. وجد إحصاؤنا (بتاريخ 2026-06-29) 112,215 نطاقاً سجلاتها الصارمة بـ -all باطلة بسبب تجاوز عمليات البحث. المُحدِّد الصارم على سجل PermError لا يحمي شيئاً.
هل الحد 10 عمليات بحث لكل include أم للسجل بأكمله؟ للتقييم بأكمله: يُحدد RFC 7208 §4.6.4 الفحص الكامل بـ 10 بالإضافة إلى ما أقصاه void lookups × 2. كل نطاق فرعي له سجله وميزانيته — لهذا تنجح الخطوة 4.
هل تُحتسب إدخالات ip4 وip6 في الحد؟ لا — آليات IP لا تكلف شيئاً، وهذا بالضبط لماذا يُقلل التسطيح العدد.
أرسل للمالك التقرير
إن كنت تُصلح هذا لعميل أو صاحب عمل، أتمّ المهمة بالدليل. أعد الفحص المجاني بعد تغييراتك وأرسل التقرير المُصنَّف لصاحب العمل: لغة بسيطة، مؤرَّخ، PermError زال. هذه هي الوثيقة التي يحتاجها لتجديد تأمين الإنترنت والاستبيان الأمني القادم من العملاء — الفرق بين “غيّرت بعض سجلات DNS” وقبل وبعد موثَّق.
افحص نطاقك مجاناً
اطلع على عدد عمليات البحث المحلول الفعلي — وكل شيء آخر لـ SPF وDKIM وDMARC — بخصوصية تامة ومقتصرة على المالك.
افحص نطاقك ← · إصلاح SPF ← · SPF الفاشل لأدوات SaaS ← · إعداد SPF على GoDaddy ← · طريقة التصنيف ← · بيانات إجمالية فقط. البيانات مخزّنة ومعالَجة في الاتحاد الأوروبي.