تحدّد 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 والاستعلامات الفارغة. ارجع إلى الدليل العملي للمصادقة للصورة الكاملة.
RFC 7208 sets an upper bound on the number of DNS queries a receiving server may perform while evaluating an SPF record, to protect servers from resource-exhaustion attacks. Exceeding it makes the SPF result permerror, a verification failure that can affect delivery.
What counts?
Each DNS query caused by these mechanisms and modifiers counts:
include,a,mx,ptr,existsandredirect.
Not counted: ip4, ip6 and all, which need no query.
Important notes
- Nesting counts: every
includeadds its own query, and everything inside the included record counts cumulatively too. - Void lookups: RFC 7208 limits queries that return “nothing” (NXDOMAIN or no data) to 2; exceeding it also results in
permerror. - The
mxmechanism: counts as one query, but resolving the MX host names has its own limit (10 names). - Avoid
ptr: it is slow, unreliable and discouraged by RFC 7208.
How to reduce the count
- Delete what is no longer used: old providers whose records were left behind.
- Replace
includeorawithip4/ip6when sending addresses are fixed, known and under your control. - Split sources across subdomains: such as
news.example.comfor the newsletter; each domain gets its own record and its own limit. - Use a reputable flattening service if you have many providers; it turns includes into addresses and keeps them updated.
Risks of manual flattening
Copying a provider's addresses into ip4 by hand fixes the count but fails silently when the provider changes its addresses. If you do it, review it regularly or use a service that updates it.
Related errors
- More than one
v=spf1record on the same domain is also apermerror. - A long record may exceed the DNS message size over UDP; keep it concise. TXT text is split into strings of at most 255 characters that the receiver concatenates.
Put it into practice
The SPF/DKIM/DMARC Checker counts lookups (worst case) and shows the include tree and void lookups. See the practical authentication guide for the full picture.
