SPF ~all در برابر -all: سافت‌فیل یا هاردفیل — 139 میلیون رکورد چه انتخابی کردند (۲۰۲۶)

منتشرشده 2026-07-03

ارقام تا تاریخ 2026-06-29 · روش‌شناسی نسخه ۷. داده‌های تجمیعی سرشماری در سراسر 261 میلیون دامنه درجه‌بندی‌شده. همه ارقام تجمیعی هستند — ما هرگز رکورد یک کسب‌وکار منفرد را منتشر نمی‌کنیم. ببینید چگونه درجه‌بندی می‌کنیم.

هر رکورد SPF به یک مکانیزم «all» ختم می‌شود — حکم نهایی درباره ایمیلی که از هر جایی خارج از فهرست شما می‌آید — و اینترنت به شکلی چشمگیر گزینه نرم را برگزیده است: ‏55.8٪ از 139 میلیون دامنه‌ای که SPF منتشر می‌کنند به ~all (سافت‌فیل) ختم می‌شوند، در برابر 39.3٪ که به -all (هاردفیل) ختم می‌شوند. یک کاراکتر است که «جعل را رد کن» را از «احتمالاً جعل است — به‌هرحال تحویلش بده» جدا می‌کند. اینکه کدام‌یک برای شما درست است به تنظیم دومی بستگی دارد که بیشتر صاحبان دامنه هرگز آن را پیکربندی نمی‌کنند.

‏~all و -all دقیقاً به یک گیرنده چه می‌گویند؟

-all (هاردفیل): «ایمیل از هر جای دیگر را رد کن.» یک نه قاطع.
~all (سافت‌فیل): «ایمیل از جای دیگر احتمالاً معتبر نیست — بپذیرش، شاید نشانه‌گذاری‌اش کن.» یک شانه بالا انداختن.
?all (خنثی): «نظری ندارم.» انتخاب‌شده توسط 3.0٪ از منتشرکنندگان؛ محافظتی فقط به اسم.
+all: «هرکسی می‌تواند به‌جای من ایمیل بفرستد.» منتشرشده توسط 36,014 دامنه، و بدتر از نداشتن رکورد است — مشکل پادری خوش‌آمدگویی گزارش مخصوص خودش را دارد.

پس آیا ~all اشتباه است؟ فقط اگر تنها باشد — و تقریباً همیشه تنهاست

سافت‌فیل یک استدلال مدرن قابل‌دفاع دارد: راهنمای فرستنده گوگل، و بیشتر رویه‌های تحویل‌پذیری همراه آن، بر ~all جفت‌شده با یک سیاست اجرایی DMARC (p=reject) همگرا می‌شوند. این جفت‌شدن به‌اندازه -all در هر گیرنده‌ای که DMARC را ارزیابی می‌کند محافظت می‌کند — که حالا شامل همه ارائه‌دهندگان بزرگ صندوق پستی می‌شود — بدون آنکه ایمیل معتبر فوروارد‌شده را با هاردباونس رد کند، همان قربانی کلاسیک -all. در آن پیکربندی، آن شانه‌بالاانداختن دندان دارد: DMARC حکمی را که SPF از دادنش سر باز زد فراهم می‌کند.

اما همان جفت‌شدن اصل ماجراست، و اینجاست آنچه سرشماری اضافه می‌کند که راهنماهای راه‌اندازی نمی‌توانند: از 77,484,057 رکورد سافت‌فیل در اینترنت، تنها 7.1 میلیون — حدود ۱ از هر 11 — یک سیاست اجرایی DMARC پشت‌سرشان دارند. برای آن 70.4 میلیون دامنه دیگر، ~all دقیقاً همان چیزی است که به نظر می‌رسد. رکورد آن‌ها جعل را شناسایی می‌کند و به آن راه می‌دهد.

مگر الزامات ۲۰۲۴ این را درست نکرد؟

نه — و این تمایز مهم‌تر از آن است که بیشتر پوشش‌های خبری القا می‌کنند. گوگل و یاهو در فوریه ۲۰۲۴ شروع به الزامی‌کردن احراز هویت از فرستندگان انبوه کردند، و مایکروسافت در می ۲۰۲۵ به آن‌ها پیوست: SPF یا DKIM موفق و هم‌ترازشده، به‌علاوه یک رکورد DMARC حداقل در سطح p=none. این الزامات از خواستن اجرا کوتاه می‌آیند — دامنه‌ای با ~all، یک رکورد p=none و DKIM هم‌ترازشده به‌طور کامل تطابق دارد، و همچنان کاملاً قابل جعل باقی می‌ماند. الزامات کاغذبازی را عادی‌سازی کردند، نه محافظت را. آن میانه اجرانشده — تطابق‌یافته، منتشرشده، جعل‌پذیر — دقیقاً همان شکافی است که این سرشماری اندازه می‌گیرد، و بزرگ‌ترین جمعیت در امنیت ایمیل است.

پس رکورد شما باید به چه ختم شود؟

ایمیل می‌فرستید و فوروارد اهمیت دارد (خبرنامه‌ها، فهرست‌های ارسال، نام‌های مستعار): ~all همراه با DMARC p=reject پشت آن — همان جفت‌شدن توصیه‌شده در بالا.
از یک ساختار کاملاً کنترل‌شده ایمیل می‌فرستید: -all کار می‌کند و سیاست را در خود رکورد بیان می‌کند. اول فرستندگان خود را نگاشت کنید — یک پایان سخت‌گیرانه روی یک رکورد نگاشت‌نشده ایمیل واقعی را می‌شکند، یا بدتر.
دامنه هرگز ایمیل نمی‌فرستد: -all به‌علاوه p=reject، همین امروز. هیچ چیز معتبری برای محافظت وجود ندارد، پس چیزی هم برای شکستن نیست.

هر پایانی که انتخاب کنید، درس یک‌خطی سرشماری برقرار است: کیفیت‌سنج (qualifier) فقط به‌اندازه چیزی که آن را اجرا می‌کند اهمیت دارد. جایگاه شما روی آن نردبان قابل اندازه‌گیری است.

پرسش‌های پرتکرار

آیا SPF ~all بهتر است یا -all؟ هیچ‌کدام، به‌طور جهان‌شمول. ~all با یک سیاست اجرایی DMARC الگویی است که راهنمای گوگل توصیه می‌کند — محافظت برابر در گیرندگانی که DMARC را ارزیابی می‌کنند، بدون شکستن ایمیل فوروارد‌شده. -all مناسب فرستندگان کاملاً کنترل‌شده است. ~all به‌تنهایی — وضعیت همه دامنه‌های سافت‌فیل به‌جز ۱ از هر 11 — گزینه ضعیف است.

سافت‌فیل SPF یعنی چه؟ ~all به گیرندگان می‌گوید که ایمیل از سرورهای فهرست‌نشده احتمالاً نامعتبر است اما همچنان باید پذیرفته شود، معمولاً با ظن. تنها زمانی به محافظت واقعی تبدیل می‌شود که یک سیاست DMARC روی آن شکست عمل کند؛ ببینید SPF بدون DMARC.

آیا هاردفیل -all ایمیل فوروارد‌شده مرا می‌شکند؟ می‌تواند: فوروارد ایمیل شما را از سرور فورواردکننده دوباره می‌فرستد، سروری که SPF شما آن را فهرست نکرده است، و یک هاردفیل پیش از آنکه DKIM یا DMARC به میدان بیایند، دعوت به رد می‌کند. همین خطر است که علت وجود جفت‌شدن ~all + p=reject است.

آیا گوگل و مایکروسافت حالا -all را الزامی می‌کنند؟ نه. الزامات فرستنده انبوه احراز هویت هم‌ترازشده و موفق و یک رکورد DMARC حداقل در سطح p=none را می‌خواهند — نه اجرا، نه کیفیت‌سنج مشخصی. رد ایمیل انبوه غیرمطابق توسط گوگل فعال است؛ مایکروسافت شکست‌ها را به پوشه ناخواسته می‌فرستد و به‌سوی رد کامل حرکت می‌کند. تطابق، محافظت نیست.

بررسی کنید رکورد شما به چه ختم می‌شود — و چه چیزی پشت آن ایستاده است

دو جست‌وجو هر دو را به شما می‌گویند، رایگان، در ۳۰ ثانیه. اگر شما یکی از آن 70.4 میلیون شانه‌بالاانداختن اجرانشده هستید، راه‌حل یک رکورد DNS است، نه یک خرید.

دامنه خود را بررسی کنید ← · اصلاح SPF ← · اصلاح DMARC ← · مدل بلوغ SPF ← · نقشه +all ← · فقط داده‌های تجمیعی. داده‌ها در اتحادیه اروپا ذخیره و پردازش می‌شوند.