Defaults.Exposed › رفع اشکالها › Guides
SPF PermError: چطور «بیش از حد DNS Lookup» را بدون شکستن ایمیل رفع کنید (۲۰۲۶)
منتشرشده 2026-07-08
ارقام تا تاریخ 2026-06-29 · روششناسی نسخه ۷. دادههای آماری انبوه از 261 میلیون دامنه درجهبندیشده. نحوه درجهبندی ما را ببینید.
حداقل 797,263 دامنه محدودیت ۱۰ DNS lookup SPF را میشکنند، بر اساس سرشماری Defaults.Exposed از 261,086,232 دامنه — از 139 میلیون ناشر SPF. بعد از ده lookup، گیرنده متوقف میشود و PermError برمیگرداند: SPF شما باطل است، و DMARC یک PermError را بهعنوان شکست محاسبه میکند.
رفع ترتیب سختی دارد، و اکثر راهنماها آن را برعکس میکنند. تعداد lookup های واقعی resolved خود را بشمارید؛ include های مرده و استفادهنشده را حذف کنید — این بهتنهایی اکثر رکوردها را رفع میکند؛ فرستندگان انبوه را به subdomainهایی با بودجه SPF خودشان منتقل کنید؛ فقط بهعنوان آخرین چاره flatten کنید، و فقط با re-flattening خودکار، چون flattening استاتیک فاسد میشود و بیصدا تحویل را میشکند.
«SPF PermError: بیش از حد DNS lookup» چه معنایی دارد؟
RFC 7208 §4.6.4 هر بررسی SPF را در ۱۰ DNS lookup محدود میکند. بعد از ده، گیرنده متوقف میشود و PermError برمیگرداند — کل رکورد بهعنوان خراب تلقی میشود، نه فقط بخشی که بیش از بودجه است. همان بخش یک سقف دوم کمتر شناختهشده هم اضافه میکند: حداکثر ۲ «void lookup» (queryهایی که بدون پاسخ یا NXDOMAIN برمیگردند)، پس یکی-دو ورودی include: مرده برای سرویسهای لغوشده میتوانند بهتنهایی SPF شما را باطل کنند.
پیامد بدتر از «بدون SPF» است: DMARC یک PermError را بهعنوان شکست SPF محاسبه میکند، پس یک دامنه که SPF خودش را میشکند در پایه SPF هر ارزیابی DMARC احراز هویتنشده است. اگر DKIM تنظیم نشده یا در transit میشکند، آن ایمیل الان DMARC را بهطور کامل شکست میدهد.
یک عدد سرشماری نشان میدهد این حالت شکست چقدر ظالمانه است: 112,215 دامنه یک رکورد -all سخت منتشر میکنند که به دلیل سرریز lookup باطل است — از 54,655,923 دامنهای که -all منتشر میکنند. صاحبان آنها بخش سخت را انجام دادند — ending سخت را انتخاب کردند — و یک include اضافه کل رکورد را خاموش کرد. سخت به نظر میرسند؛ خراب هستند. برای تصویر کامل داده، گزارش SPF PermError را ببینید.
چرا SPF من وقتی چیزی را تغییر ندادم شکست؟
چون بودجه بیشتر توسط رکوردهای دیگران خرج میشود. هر include: بهصورت بازگشتی ارزیابی میشود، و هر مکانیزم lookup درون آن در برابر ده تای شما محاسبه میشود. یک خط در panel DNS شما میتواند چهار یا پنج lookup هزینه داشته باشد بعد از resolve شدن. یک ارائهدهنده یک include دیگر تو در تو میگذارد، و SPF شما بدون یک تغییر در zone شما میمیرد.
پلتفرمهای بزرگ مشکل نیستند: Google و Microsoft هر دو SPF خودشان را flatten کردهاند — _spf.google.com و spf.protection.outlook.com به لیستهای IP ساده expand میشوند که صفر lookup داخلی هزینه دارند (در برابر DNS زنده تأیید شده، جولای ۲۰۲۶). انفجارهای دنیای واقعی از زنجیرههای include panel هاستینگ چندین لایه تو در تو، و از stack کردن صادقانه SaaS میآید — صندوق پستی plus خبرنامه plus CRM plus helpdesk، هر کدام «فقط یک include». هیچکس عمداً یازدهمین lookup را اضافه نمیکند؛ بهعنوان جمع تصمیمات معقول میرسد. به همین دلیل لبه کلیف آنقدر شلوغ است: 2,119,539 دامنه دقیقاً در ۹-۱۰ lookup resolved نشستهاند — تقریباً ۱ از هر 66 از همه ناشران SPF، امروز خوب، آن روزی که کسی یک include دیگر paste کند باطل. رکورد SPF percentile 99 قبلاً به 9 lookup resolve میشود. اگر stack شما SaaS-heavy است، راهنمای SPF شکستخورده برای ابزارهای SaaS نسخه فروشنده به فروشنده را پوشش میدهد.
کدام بخشهای یک رکورد SPF بهعنوان DNS lookup محاسبه میشوند؟
| مکانیزم | هزینه Lookup | یادداشت |
|---|---|---|
include: | ۱ + همه چیز داخل آن، بهصورت بازگشتی | جایی که تقریباً همه انفجارها از آنجا میآیند |
a | ۱ هر کدام | حتی a خالی برای دامنه خودتان |
mx | ۱ هر کدام (بهعلاوه lookup های A هاستهای MX) | اغلب فراموش میشود |
ptr | ۱ — و از ۲۰۱۴ منسوخ شده | صرف نظر از آن حذف کنید |
exists: | ۱ هر کدام | نادر |
redirect= | ۱ + محتوای رکورد هدف | مانند یک include محاسبه میشود |
ip4: / ip6: | ۰ | به همین دلیل flattening کار میکند |
-all / ~all / ?all | ۰ | qualifier رایگان است |
کل resolved را بشمارید، نه خطوط قابل مشاهده. چهار include میتواند چهار lookup یا چهارده باشد.
چطور «بیش از حد DNS lookup» را بدون شکستن ایمیل رفع کنم؟
۱. اسکن رایگان را قبل از لمس DNS اجرا کنید. زنجیره include کامل شما را resolve میکند و تعداد lookup واقعی شما را نشان میدهد، پس مشکل واقعی را رفع میکنید — نه رکورد آنطور که در panel شما ظاهر میشود. (اگر میگوید اصلاً SPF ندارید، این یک شکست متفاوت است — «رکورد SPF پیدا نشد» را ببینید.)
۲. ابتدا include های مرده و استفادهنشده را حذف کنید. ابزاری که در ۲۰۲۳ رها کردید، include هاست قدیمی که از مهاجرت جان سالم به در برد، تکراریها، هر مکانیزم ptr. include های مرده دوبار سمی هستند: بودجه lookup و منبع معمول void lookup ها را میسوزانند. اکثر رکوردهای بیش از بودجه فقط در این مرحله زیر ۱۰ برمیگردند. اگر رکوردتان هنوز مکانیزمهای ارائهدهنده قبلی را حمل میکند، راهنمای پاکسازی مهاجرت را دنبال کنید.
۳. بررسی کنید هر include باقیمانده چیزی انجام میدهد. گیرندگان SPF را در برابر دامنه Return-Path (RFC5321.MailFrom)، نه header From ارزیابی میکنند — و بسیاری از ابزارهای SaaS bounce domain خودشان را روی Return-Path میگذارند، پس include آنها در رکورد شما چیزی به جز خرج بودجه انجام نمیدهد. فقط برای سرویسهایی که دامنه شما را بهعنوان Return-Path استفاده میکنند include نگه دارید؛ برای بقیه، DKIM سفارشی-دامنه فروشنده را فعال کنید.
۴. فرستندگان انبوه را به subdomain منتقل کنید. خبرنامهها از news.yourdomain.com، ایمیل تراکنشی از mail.yourdomain.com. هر subdomain رکورد SPF خودش را با بودجه ۱۰ lookup تازه میگیرد، و یک مشکل در یک جریان دیگر به دیگران خونریزی نمیکند.
۵. فقط بعد از آن flattening را در نظر بگیرید — و فقط flattening خودکار. زیر را ببینید.
۶. دوباره اسکن کنید تا تأیید کنید بهراحتی زیر ۱۰ هستید — به headroom هدف بزنید، نه دقیقاً ۱۰، وگرنه فقط به 2.1 میلیون دامنه روی لبه کلیف برگشتید. سپس از طریق هر چیز دیگری که اسکن نشان میدهد در صفحه رفع SPF کار کنید.
آیا باید رکورد SPF خود را flatten کنم؟
Flattening includeها را با بلوکهای ip4:/ip6: زیرین جایگزین میکند که صفر lookup هزینه دارند. کار میکند — و دستی انجام شده، یک خاموشی تحویل با تأخیر است.
| رویکرد | تعداد Lookup | در طول زمان |
|---|---|---|
| Prune + subdomainها (مراحل ۲-۴) | معمولاً زیر ۱۰ برمیگردد | پایدار؛ ارائهدهندگان IP خودشان را مدیریت میکنند |
| Flattening خودکار (یک سرویس یا job برنامهریزیشده که دوباره resolve و منتشر میکند) | نزدیک ۰ | تغییرات IP ارائهدهنده را دنبال میکند؛ امن |
| Flattening دستی یکباره | نزدیک ۰ — امروز | بیصدا فاسد میشود: ارائهدهندگان IP ارسالی را میچرخانند، ایمیل قانونی شروع به شکست SPF میکند بدون هیچ خطایی از طرف شما |
ارائهدهندگان IP ارسال را بهطور معمول میچرخانند و به هیچکس اعلام نمیکنند. یک لیست IP استاتیک روزی که paste میکنید درست است و ظرف ماهها بیصدا اشتباه میشود — و چون شکست بهصورت دیگران که ایمیل شما را دریافت نمیکنند ظاهر میشود، دیر متوجه میشوید. اگر prune کردن و subdomainها شما را زیر محدودیت نگه میدارند، همانجا بمانید؛ هرگز بلوکهای IP شخص ثالث را بهعنوان یک رفع دائمی در رکورد خود کپی-paste نکنید.
پرسشهای متداول
آیا SPF PermError به این معنی است که ایمیل من تحویل داده نمیشود؟ فوراً نه — این همان چیزی است که آن را خطرناک میکند. DMARC یک PermError را بهعنوان شکست SPF محاسبه میکند، پس تحویل کاملاً به DKIM متکی است؛ اگر DKIM گمشده یا در transit میشکند، DMARC را شکست میدهید. از 139 میلیون ناشر SPF در سرشماری ما (تا 2026-06-29)، حداقل 797,263 در این حالت هستند — اکثر بدون اینکه بدانند.
رکورد من فقط چهار include دارد — چطور میتواند بیش از ۱۰ lookup باشد؟ Includeها بهصورت بازگشتی شمارش میشوند: همه چیز داخل هر include (و داخل include های آن) به بودجه شما تعلق میگیرد، پس چهار خط قابل مشاهده میتواند به چهارده lookup resolve شود. با یک ابزار resolving بشمارید، نه با چشم — resolve کردن زنجیرهها همان چیزی است که گزارش PermError ما ~100× بیشتر دامنههای خراب از آنچه شمارشهای سطحی نشان میدهند پیدا کرد.
رکورد من با -all ختم میشود — مطمئناً محافظت دارم؟
فقط اگر رکورد ارزیابی شود. سرشماری ما (تا 2026-06-29) 112,215 دامنه را یافت که رکوردهای -all سختشان از سرریز lookup باطل هستند. یک qualifier سخت روی یک رکورد PermError هیچچیز را محافظت نمیکند.
آیا محدودیت ۱۰ lookup برای هر include است یا برای کل رکورد؟ کل ارزیابی: RFC 7208 §4.6.4 بررسی کامل را در ۱۰ محدود میکند، بهعلاوه حداکثر ۲ void lookup. هر subdomain رکورد و بودجه خودش را دارد — به همین دلیل مرحله ۴ کار میکند.
آیا ورودیهای ip4 و ip6 به محدودیت محاسبه میشوند؟ خیر — مکانیزمهای IP هیچچیز هزینه ندارند، که دقیقاً به همین دلیل flattening تعداد را کاهش میدهد.
گزارش را برای صاحب دامنه بفرستید
اگر این کار را برای یک مشتری یا کارفرما انجام میدهید، کار را با مدرک تمام کنید. اسکن رایگان را بعد از تغییرات اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار بفرستید: به زبان ساده، با تاریخ، PermError رفعشده. این چیزی است که برای تمدید بیمه سایبری و پرسشنامه امنیتی مشتری بعدی نیاز دارند — تفاوت بین «چند رکورد DNS را تغییر دادم» و یک قبل-و-بعد مستند.
دامنه خود را رایگان بررسی کنید
تعداد lookup resolved واقعی خود را — و هر چیز دیگری در SPF، DKIM و DMARC — بهصورت خصوصی و فقط برای صاحب ببینید.
دامنه خود را بررسی کنید ← · رفع SPF ← · SPF شکستخورده برای ابزارهای SaaS ← · تنظیم SPF در GoDaddy ← · نحوه درجهبندی ما ← · فقط دادههای انبوه. دادهها در اتحادیه اروپا ذخیره و پردازش میشوند.