تحدّد RFC 7208 حدًّا أعلى لعدد الاستعلامات التي يجوز لخادم المستلم إجراؤها أثناء تقييم سجل SPF، لحماية الخوادم من هجمات الاستنزاف. تجاوز الحد يجعل نتيجة SPF permerror، أي فشلًا في التحقق قد يؤثر على التسليم.
ما الذي يُحسب؟
يُحسب كل استعلام DNS تسبّبه هذه الآليات والمُعدِّلات:
includeوaوmxوptrوexistsوredirect.
ولا يُحسب: ip4 وip6 وall، فهي لا تحتاج استعلامًا.
ملاحظات مهمة
- التداخل يُحسب: كل
includeيضيف استعلامه، وكل ما بداخل السجل المضمَّن يُحسب أيضًا بشكل تراكمي. - الاستعلامات «الفارغة» (void lookups): تضع RFC 7208 حدًّا قدره 2 للاستعلامات التي تُرجع «لا يوجد» (NXDOMAIN أو بلا بيانات)؛ تجاوزه يؤدي إلى
permerrorأيضًا. - آلية
mx: تُحسب استعلامًا واحدًا، لكن حلّ أسماء خوادم MX له حدّه الخاص (10 أسماء). - تُفضَّل ألّا تستخدم
ptr؛ فهي بطيئة وغير موثوقة ومُثبَّط استعمالها في RFC 7208.
كيف تخفّض العدد
- احذف ما لم يعد مستخدمًا: مزوّدون قدماء بقيت سجلاتهم.
- استبدل
includeأوaبـip4/ip6حين تكون عناوين الإرسال ثابتة ومعروفة وتحت سيطرتك. - افصل المصادر على نطاقات فرعية: مثل
news.example.comللنشرة ولكل نطاق سجله وحدّه المستقل. - استعمل خدمة «تسطيح» (flattening) موثوقة إن كان لديك مزوّدون كثر؛ وهي تحوّل الـinclude إلى عناوين وتحدّثها تلقائيًا.
مخاطر التسطيح اليدوي
نسخ عناوين المزوّد يدويًا إلى ip4 يحلّ مشكلة العدد لكنه يفشل بصمت عندما يغيّر المزوّد عناوينه. إن فعلته فراجِعه دوريًا أو استعمل خدمة تحدّثه.
أخطاء متصلة
- أكثر من سجل
v=spf1على النطاق نفسه يُعدّpermerrorكذلك. - سجل طويل قد يتجاوز حجم رسالة DNS على UDP؛ اجعله موجزًا. يُقسَّم نص TXT إلى سلاسل لا تزيد كل منها عن 255 حرفًا ويجمعها المستلم.
طبّق ذلك
يعدّ فاحص SPF/DKIM/DMARC الاستعلامات (بحسب أسوأ حالة) ويُظهر شجرة include والاستعلامات الفارغة. ارجع إلى الدليل العملي للمصادقة للصورة الكاملة.
