Defaults.Exposed › گزارشها
چرا SPF من شکست میخورد؟ مشکل ۱۰ جستجوی SaaS برای فرستندگان بریتانیایی و اروپایی (2026)
منتشرشده 2026-07-09
اعداد تا تاریخ 2026-06-29 · روششناسی نسخه ۷. دادههای مجموعه سرشماری در 261 میلیون دامنه درجهبندیشده. ببینید چگونه درجهبندی میکنیم.
وقتی SPF برای کسبوکاری که از ابزارهای SaaS در بریتانیا یا اتحادیه اروپا استفاده میکند شکست میخورد، محتملترین دلیل یک قانون RFC است که هرگز مجبور نشدهاید به آن فکر کنید: پس از ۱۰ جستجوی DNS، SPF دیگر “شکست” برنمیگرداند — بلکه PermError برمیگرداند، یعنی رکورد طوری برخورد میشود که انگار اصلاً وجود ندارد. حداقل 797,263 دامنه از این خط گذشتهاند. 2,119,539 دامنه دیگر دقیقاً روی ۹ تا ۱۰ جستجو ایستادهاند — یک ابزار جدید کافی است تا آنها را از لبه پرتاب کند.
چرا SPF وقتی یک ابزار SaaS اضافه میکنید میشکند؟
SPF با فهرست کردن سرورهای ایمیلی که مجاز به ارسال بهنام دامنه شما هستند کار میکند. کسبوکارهای مدرن معمولاً سرور ایمیل خود را نمیچرخانند — از Google Workspace برای ایمیل داخلی، Mailchimp برای کمپینها، HubSpot برای دنبالههای فروش، و Pipedrive برای ارتباط CRM استفاده میکنند. هر پلتفرم به شما یک خط include: میدهد که در DNS خود بچسبانید.
مشکل اینجاست: هر include: خودش یک جستجوی DNS است. و هر رکورد داخل آن include میتواند بهصورت بازگشتی جستجوهای بیشتری ایجاد کند. RFC 7208 §4.6.4 سقف سختی از ده جستجو تعیین میکند. پس از ده جستجو، سرور ایمیل دریافتکننده ارزیابی را متوقف میکند و PermError برمیگرداند — که یک شکست نرم نیست که در اسپم برود. یعنی رکورد SPF شما طوری برخورد میشود که انگار وجود ندارد. احراز هویت ایمیل در بخش SPF شکست میخورد.
این را در پنل DNS خود نخواهید دید. شمارنده فقط در طول ارزیابی زنده فعال میشود. ممکن است سه خط include: در رکورد مرئی داشته باشید و هنوز دوازده جستجو عمیق باشید، چون رکورد SPF هر فروشنده sub-includeهای خودش را میکشد.
چند دامنه از قبل از حد گذشتهاند؟
حداقل 797,263. این تعداد پس از حل هر هدف include: مربوط به SPF که ۱۰۰ بار یا بیشتر ارجاع داده شده بود — 10,842 هدف مجزا که 95.2٪ از همه ارجاعات include را پوشش میدهند — و قیمتگذاری زنجیره کامل هر دامنه به دست آمد. شمارش سطحی (چیزی که با شمردن فقط خطوط مرئی در یک رکورد پیدا میکنید) حدود 7,958 را مییابد. عدد قیمتگذاریشده زنجیره 100 برابر بزرگتر است، چون تقریباً همه آسیبها داخل اهداف include نامرئی است.
وضعیتی که بیشتر احتمال دارد یک کسبوکار اروپایی را تحت تأثیر قرار دهد:
| سناریو | چه اتفاقی میافتد |
|---|---|
| Google Workspace + Mailchimp + HubSpot + یک ابزار دیگر | احتمالاً روی ۱۰ جستجو یا بیشتر |
| هاستینگ IONOS + هر سه ابزار SaaS | خطر بالا: هدف SPF خود IONOS چندین hop اضافه میکند |
| هاستینگ OVH + دو ابزار تراکنشی + یک CRM | خطر بستگی به عمق SPF OVH در زمان ارزیابی دارد |
| Microsoft 365 بهتنهایی | خطر پایین: SPF مایکروسافت فشرده و نگهداریشده است |
ارائهدهندگان هاستینگ اروپایی و تنظیمات پیشفرض ضعیف SPF
ارائهدهنده هاستینگی که با آن شروع کردهاید اهمیت دارد — چون برخی از آنها تنظیمات پیشفرض SPF را تعیین میکنند که قبل از اتصال حتی یک ابزار SaaS، چند جستجو از دهتای شما را مصرف میکنند.
در میان بزرگترین ارائهدهندگان هاستینگ مورد استفاده دامنههای اروپایی در سرشماری ما:
| ارائهدهنده | دامنههایی که از آن استفاده میکنند | SPF سختگیرانه (-all) | DMARC اجرایی |
|---|---|---|---|
| IONOS (EU) | 4,346,526 | 0.3٪ | 1.0٪ |
| OVH | 2,132,049 | 43.7٪ | 2.2٪ |
| Microsoft 365 | 10,205,070 | 85.0٪ | 21.7٪ |
| Google Workspace | 12,145,313 | 8.0٪ | 18.5٪ |
IONOS برجسته است: تنها 1.0٪ از دامنههای میزبانیشده در IONOS DMARC اجرایی دارند، یعنی اکثریت قریببهاتفاق هیچ احراز هویت فرستندهای ندارند. دامنههای OVH در تنظیم SPF سختگیرانه بهتر عمل میکنند (43.7٪) اما در اجرای DMARC به 2.2٪ میرسند — SPF بهتنهایی، بدون DMARC که آن را به هدر From: متصل کند، فقط پاکت را محافظت میکند، نه آنچه گیرنده میبیند.
Microsoft 365 استثنای مثبت است: 85.0٪ از دامنههای میزبانیشده در مایکروسافت از SPF سختگیرانه استفاده میکنند، عمدتاً چون جادوگر جریان ایمیل مایکروسافت بهصورت پیشفرض -all تنظیم میکند. Google Workspace بهصورت پیشفرض ~all (softfail) تنظیم میکند و 92٪ از دامنههایش را بدون حفاظت سختگیرانه رها میکند.
چگونه در کمتر از ۶۰ ثانیه خرابی SPF را تشخیص دهید
سریعترین بررسی، ابزار رایگانی است که کل زنجیره جستجو را ارزیابی میکند — نه فقط رکورد مرئی را. دستور nslookup -type=TXT yourdomain.com را در خط فرمان اجرا کنید و هر include: که میبینید را بشمارید. سپس هر یک از آن رکوردها را جستجو کنید و آنها را بشمارید. اگر قبل از اینکه includeها تمام شوند، انگشتانتان تمام شدند، در منطقه خطر هستید.
رویکرد قابلاطمینانتر: دامنهتان را اینجا بررسی کنید — اسکنر کل زنجیره حلشده را ارزیابی میکند، PermError را علامتگذاری میکند، و نشان میدهد کدام مکانیزمها بودجه جستجوی شما را مصرف میکنند.
سه نتیجه تشخیصی:
- PermError — از قبل از ده گذشتهاید. هر ایمیلی که ارسال میکنید در بررسی SPF نزد گیرنده شکست میخورد.
- روی ۹ تا ۱۰ جستجو — روی لبه هستید. ادغام بعدی SaaS شما را از آن میاندازد.
- Softfail (~all) به جای hardfail (-all) — زیر حد هستید اما رکورد با تساهل بیش از حد تنظیم شده که حفاظت واقعی ارائه نمیدهد. برای تصویر کامل از
-allدر مقابل~allگزارش اشتباهات پیکربندی SPF را ببینید.
چگونه SPF را هنگام استفاده از چندین ابزار SaaS درست کنید
سه رویکرد وجود دارد، به ترتیب دوام:
۱. حسابرسی و هرس کردن. با فهرست کردن هر include: در رکورد فعلی خود شروع کنید. هر پلتفرمی را که دیگر استفاده نمیکنید حذف کنید — ESPهای قدیمی، ابزارهای CRM از قراردادهای قبلی، پلتفرمهایی که آزمایش کردید اما رها کردید. این رایگان است و اغلب چند جستجو بازمیگرداند. هر include: حذفشده ممکن است ۱ تا ۳ sub-lookup را حذف کند.
۲. صاف کردن رکورد SPF. صاف کردن SPF تمام اهداف include: را به محدودههای IP پایهشان تبدیل میکند و آنها را مستقیماً بهعنوان مکانیزمهای ip4: و ip6: در رکورد شما مینویسد. مکانیزمهای IP جستجو ایجاد نمیکنند، بنابراین یک رکورد صافشده میتواند دهها منبع ارسال را فهرست کند و هنوز روی صفر جستجو باشد. نقطه ضعف: هر بار که فروشندهای IPهای ارسالیاش را بهروز میکند باید مجدداً صاف کنید، و این بدون اطلاع اتفاق میافتد. اکثر سازمانها از یک سرویس صافکردن SPF پولی استفاده میکنند (PowerDMARC، EasyDMARC، Dmarcian و دیگران این را ارائه میدهند) یا یک جریان کار نظارتی میسازند.
۳. استفاده از ماکرو SPF. ماکرو RFC 7208 به شما امکان میدهد رکوردهایی بسازید که یک جستجوی DNS در هر بررسی انجام میدهند و بهصورت پویا پاسخ میدهند، به جای زنجیرهای از includeها. ماکروها به پشتیبانی هاستینگ DNS و مقداری تلاش در پیادهسازی نیاز دارند، اما راهحل معماری تمیزی برای سازمانهایی با فرستندگان SaaS زیاد هستند.
پس از رفع SPF، آن را با اجرای DMARC جفت کنید — SPF بدون DMARC فقط فرستنده پاکت را احراز هویت میکند، نه آدرس From: در هدر که گیرندگان میبینند.
سوالات متداول
چرا رکورد SPF من ابزار DNS من را رد میکند اما در هدرهای ایمیل همچنان شکست میخورد؟
اکثر ابزارهای جستجوی DNS فقط مکانیزمهای مرئی در رکورد خودتان را میشمارند، نه sub-lookupهایی که آن مکانیزمها ایجاد میکنند. ممکن است دو خط include: داشته باشید و هنوز از حد بگذرید اگر رکورد هر فروشنده چند تا بیشتر داشته باشد. فقط یک ابزار قیمتگذاری زنجیره (یا یک سرور ایمیل دریافتکننده) عمق کامل را میشمارد. دامنهتان را بررسی کنید تا تعداد واقعی زنجیره را ببینید.
آیا شکست SPF به معنای رفتن ایمیلهایم به اسپم است؟
PermError (جستجوهای بیش از حد) یعنی بخش SPF احراز هویت یک نتیجه غیرنتیجه برمیگرداند — عملاً غایب. DMARC هم SPF و هم DKIM را ارزیابی میکند؛ اگر DKIM قبول شود، DMARC میتواند با وجود PermError در SPF قبول شود. اگر هیچکدام قبول نشوند، DMARC شکست میخورد و نتیجه به سیاست DMARC شما بستگی دارد. در p=none، ایمیل هنوز تحویل داده میشود اما شکست ثبت میشود. در p=quarantine یا p=reject، ایمیل فیلتر یا برگردانده میشود. SPF را درست کنید تا فقط به DKIM وابسته نباشید.
یک مجموعه معمولی SaaS چند جستجو استفاده میکند؟ رکورد p99 در سرشماری ما قبل از اضافه کردن هر چیزی روی 9 جستجو است — درست روی حد. یک رکورد Google Workspace ۳ تا ۴ جستجو اضافه میکند؛ Mailchimp ۱ تا ۲ اضافه میکند؛ HubSpot بسته به پیکربندی فعلیشان ۱ تا ۳ اضافه میکند. سه ابزار اصلی بهعلاوه پیشفرض ارائهدهنده هاستینگ شما اغلب برای رسیدن به ده کافی است.
آیا صاف کردن SPF امن است؟
بله، به شرطی که آن را بهروز نگه دارید. صاف کردن زنجیرههای include: را به محدودههای IP ثابت تبدیل میکند — اگر فروشندهای IPهای ارسالی خود را تغییر دهد و شما مجدداً صاف نکنید، شروع به رد کردن ایمیلهایشان خواهید کرد. اکثر سازمانها از یک سرویس صافکردن مدیریتشده استفاده میکنند که تغییرات IP را رصد میکند نه اینکه بهصورت دستی آن را نگهداری کنند.
SPF من سالهاست اینطور بوده — چرا ناگهان شکست میخورد؟ چون فروشندگان شما رکوردهای SPF خودشان را بهروز کردهاند، نه شما. هر بار که یک پلتفرم SaaS محدوده IP ارسالی جدیدی اضافه میکند یا یک include تودرتو دیگری میگذارد، هزینه زنجیره شما بدون هیچ تغییری از طرف شما بالا میرود. حد ۱۰ جستجو بهصورت زنده در زمان دریافت پیام ارزیابی میشود، بنابراین تغییر یک فروشنده صبح سهشنبه میتواند SPF شما را بعدازظهر سهشنبه بشکند.
آیا رفع SPF قابلیت تحویل ایمیل را بهبود میبخشد؟ یک منبع شکست احراز هویت را حذف میکند، که پیشنیاز تحویل مستمر است — بهخصوص از آنجایی که Google و Yahoo اکنون تراز DMARC را برای فرستندگان انبوه اجرا میکنند. SPF بهتنهایی تصویر کامل نیست: آن را با DKIM و DMARC جفت کنید برای احراز هویت کامل ایمیل.
SPF خود را رایگان بررسی کنید
اگر مطمئن نیستید که رکورد SPF شما از حد جستجو گذشته است — یا خیلی ضعیف تنظیم شده که از دامنه شما محافظت کند — یک بررسی رایگان انجام دهید. کل زنجیره حلشده را ارزیابی میکند و دقیقاً نشان میدهد بودجه کجا صرف میشود.
دامنهتان را بررسی کنید ← · SPF را درست کنید ← · گزارش SPF PermError ← · گزارش پیکربندی اشتباه SPF ← · مدل بلوغ پذیرش SPF ← · DMARC را درست کنید ← · فقط دادههای مجموعه. دادهها در اتحادیه اروپا ذخیره و پردازش میشوند.