Defaults.Exposed › رفع اشکالها › Guides
SPF برای ابزارهای SaaS شما شکست میخورد؟ چرا این اتفاق میافتد و ترتیب رفع — نسخه اروپا (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
وقتی یک ابزار SaaS «SPF شکست میخورد»، رکورد شما معمولاً مشکل نیست: ایمیل DMARC alignment را شکست میدهد، یا زنجیر include شما محدودیت ۱۰-DNS-lookup SPF را شکسته. 2,119,539 از 138,927,207 دامنه منتشرکننده SPF در ۹–۱۰ lookup هستند — یک include SaaS از لبه — بر اساس سرشماری Defaults.Exposed از 261,086,232 دامنه.
در ادامه: چطور بفهمید کدام یک از دو مشکل را دارید، سپس ترتیب رفع — ابتدا اسکن کنید، دامنهای که ابزار واقعاً از آن ارسال میکند را پیدا کنید، فروشنده را به DKIM دامنه سفارشی سوئیچ کنید، و فقط یک include SPF جایی اضافه کنید که واقعاً کمک میکند — به علاوه موارد خاص برای HubSpot، Salesforce، Mailchimp و SendGrid.
چرا ایمیل از یک ابزار SaaS SPF را شکست میدهد؟
سه الگو تقریباً هر مورد را پوشش میدهند:
| آنچه گزارش یا bounce میگوید | آنچه واقعاً اشتباه است | رفع |
|---|---|---|
| SPF تأیید میشود، DMARC همچنان شکست میخورد | Alignment: ابزار SPF را روی bounce domain خودش تأیید کرد، نه دامنه شما | DKIM دامنه سفارشی فروشنده را روشن کنید (CNAMEs) |
SPF permerror | زنجیر include شما از محدودیت ۱۰-DNS-lookup SPF تجاوز کرده | include ها را هرس کنید؛ رفع too-many-lookups را ببینید |
SPF fail / softfail | ابزار واقعاً با return-path شما ارسال میکند و در رکورد شما نیست | include فروشنده را اضافه کنید یا bounce domain سفارشی آن را فعال کنید |
دادهها تا 2026-06-29.
ردیف بولد جایی است که بیشتر مردم ایستادهاند. اضافه کردن خطوط include: برای هر ابزار آن را لمس نمیکند — و هر خط شما را به ردیف دوم نزدیکتر میکند: حداقل 797,263 دامنه قبلاً از محدودیت ۱۰ lookup تجاوز کردهاند، و SPF آنها اکنون یک PermError برمیگرداند که هیچ چیز را محافظت نمیکند. اعداد کامل در گزارش SPF PermError.
SPF واقعاً کدام دامنه را بررسی میکند؟
نه آن در هدر From شما. گیرندهها SPF را در مقابل دامنه Return-Path (RFC5321.MailFrom، که bounce یا envelope-from address هم نامیده میشود) ارزیابی میکنند — هدر From که گیرندهتان میبیند هیچ نقشی در بررسی SPF خودش ندارد.
این یک واقعیت بیشتر «شکستهای SPF SaaS» را توضیح میدهد. پلتفرم بازاریابی شما با یک Return-Path مثل [email protected] ارسال میکند؛ SPF در مقابل vendor.com بررسی میشود و به خوبی تأیید میشود. سپس DMARC میپرسد آیا آن دامنه بررسی شده SPF با دامنه From شما مطابقت دارد. نه، پس پای SPF DMARC شکست میخورد و داشبورد شما میگوید «SPF شکست میخورد». ویرایش رکورد SPF خودتان نمیتواند آن را رفع کند — رکورد شما هرگز مشورت نشد.
ترتیب رفع چیست؟
۱. ابتدا اسکن رایگان را اجرا کنید. در یک مرور به شما میگوید آیا SPF مفقود، تکراری، بالای محدودیت lookup یا خوب است، و DMARC کجا ایستاده — قبل از لمس DNS. ۲. Return-Pathای که ابزار واقعاً استفاده میکند را پیدا کنید. یک آزمایش از ابزار برای خودتان ارسال کنید و هدر Return-Path (و Authentication-Results) را در پیام خام بخوانید. این به شما میگوید در کدام ردیف جدول بالا هستید. ۳. DKIM دامنه سفارشی فروشنده را روشن کنید. هر ابزار SaaS جدی «domain authentication» ارائه میدهد: چند رکورد CNAME که به آن اجازه میدهد DKIM-sign به عنوان دامنه شما کند. آن امضا با دامنه From شما همراستا میشود، پس DMARC از طریق DKIM تأیید میشود — به طور پایدار، و حتی وقتی ایمیل forward میشود. این رفعی است که دوام میآورد. ۴. include SPF فروشنده را فقط اگر از return-path شما استفاده میکند اضافه کنید — bounce domain سفارشی آن را فعال کردهاید، یا واقعاً با دامنه شما در envelope ارسال میکند. یک include برای فروشندهای که از طریق دامنه خودش bounce میکند هیچ چیزی نمیخرد و بودجه lookup را خرج میکند. ۵. DNS lookup ها را قبل از ذخیره بشمارید. محدودیت ۱۰ lookup resolved است، include ها به صورت recursive شمارش میشوند، و 2,119,539 دامنه قبلاً در ۹–۱۰ هستند — p99 سرشماری 9 است. نزدیک به لبه؟ ابتدا include ها را برای ابزارهایی که دیگر استفاده نمیکنید حذف کنید. تازه ارائهدهنده ایمیل تغییر دادید؟ یک رکورد دوم باقیمانده را بررسی کنید — دو رکورد SPF برابر PermError است. ۶. دوباره اسکن کنید و تأیید کنید. SPF روی دامنه درست تأیید میشود، DKIM همراستا، DMARC تأیید میشود. مرجع کامل در چطور SPF را رفع کنیم است؛ راهنماهای ارائهدهنده مثل SPF روی GoDaddy و DMARC روی IONOS کلیکهای پانل DNS را پوشش میدهند.
برای HubSpot، Salesforce، Mailchimp و SendGrid چه باید کنید؟
HubSpot. دامنه ارسالی را در تنظیمات HubSpot متصل کنید و دو CNAME DKIM که صادر میکند (hs1-… / hs2-…) را منتشر کنید. این DKIM را با دامنه From شما همراستا میکند. نیازی به یک include SPF HubSpot ندارید مگر اینکه HubSpot را برای استفاده از bounce domain خودتان پیکربندی کرده باشید.
Salesforce. یک کلید DKIM در Salesforce Setup ایجاد کنید و جفت CNAME که ایجاد میکند را منتشر کنید. اگر Salesforce با return-path سازمان شما ارسال میکند، include:_spf.salesforce.com را اضافه کنید و bounce domain را پیکربندی کنید — این CRM بزرگی است که include SPF اغلب واقعاً نیاز است.
Mailchimp. دامنه را احراز هویت کنید و CNAME های DKIM k2 / k3 را منتشر کنید. alignment Mailchimp فقط DKIM است — دیگر include SPFی برای اضافه کردن وجود ندارد، و اضافه کردن یکی از یک آموزش قدیمی فقط lookup ها را هدر میدهد.
SendGrid. domain authentication («automated security») را کامل کنید: سه CNAME که هم DKIM و هم return-path را روی subdomain خودتان مدیریت میکنند. نیازی به include SPF نیست. از 740,321 دامنهای که SPF sendgrid.net را مجاز میدانند، فقط 18.0٪ DMARC اجرایی دارند (دادهها تا 2026-06-29) — بیشتر فرستندههای SendGrid یک گام کوتاه از تکمیل متوقف میشوند.
Zendesk و همه چیز دیگر: همان الگو. صفحه «domain authentication» ابزار را پیدا کنید، CNAME های DKIM را منتشر کنید، و فقط SPF را لمس کنید اگر ابزار مستند میکند که از return-path شما استفاده میکند.
آیا SPF برای کسبوکارهای اروپایی متفاوت است؟
خیر — SPF، DKIM و DMARC همه جا یکسان کار میکنند. آنچه در اروپا متفاوت است زمینه است: چه کسی میپرسد، و همسایههایتان قبلاً چه کردهاند.
ccTLD شما نوار محلی را تعیین میکند. ccTLD های اروپایی SPF را بالاتر از نرخ .com منتشر میکنند، اما دامنههایی که کار را تمام میکنند — یک سیاست DMARC اجرایی روی آن — در همه جا اقلیت هستند:
| TLD | اتخاذ SPF (از دامنههای درجهبندی شده) | DMARC اجرایی (از دامنههای درجهبندی شده) |
|---|---|---|
| .nl | 75.91% | 29.43% |
| .ie | 70.89% | 8.79% |
| .de | 64.67% | 21.38% |
| .dk | 50.42% | 19.88% |
| .com | 54.14% | 9.50% |
دادهها تا 2026-06-29. فرانسه: 13.65٪ DMARC اجرایی؛ ایتالیا: 5.24٪.
پیشفرض host اروپایی شما اهمیت دارد. 4,346,526 دامنه سرورهای ایمیل EU IONOS (_spf-eu.ionos.com) را در SPF مجاز میدانند — و فقط 0.3٪ به strict -all ختم میشوند، با 1.0٪ DMARC-enforced. 2,132,049 OVH در strictness بهتر عمل میکنند (43.7٪) اما فقط 2.2٪ DMARC را اجرا میکنند (دادهها تا 2026-06-29). اگر هرگز رکورد را لمس نکردهاید، روی آن پیشفرضها ایستادهاید.
مقرراتگذاران اکنون این را نام میبرند. NIS2 ماده ۲۱(۲)(j) از موجودیتهای در محدوده میخواهد ارتباطات خود را ایمن کنند، و آییننامه اجرایی کمیسیون (EU) 2024/2690 اقدامات امنیت ایمیل و DNS را مشخص میکند. احراز هویت ایمیل قطعه ملموس و قابل بررسی است — و غیرمعمول برای انطباق، رایگان قابل رفع است.
در مورد محل ذخیره داده: اسکنر و سرشماری Defaults.Exposed در AWS eu-west-1 اجرا میشوند، ما فقط ارقام aggregate منتشر میکنیم، و یک اسکن فقط دامنهای که میپرسید را بررسی میکند.
پرسشهای متداول
بررسیکننده SPF من «pass» میگوید اما داشبورد ابزار میگوید SPF شکست میخورد — چرا؟ بررسیکننده رکورد شما را آزمایش کرد؛ گیرنده دامنه Return-Pathای که ابزار واقعاً استفاده کرد را آزمایش کرد، سپس DMARC آن را با دامنه From شما مقایسه کرد. این یک شکست alignment است، نه یک شکست رکورد — با DKIM دامنه سفارشی فروشنده رفع میشود، نه با ویرایش SPF.
آیا باید فقط include SPF را برای هر ابزاری که استفاده میکنیم اضافه کنیم؟ خیر. هر include بخشی از بودجه ۱۰-lookup SPF را به صورت recursive خرج میکند: 2,119,539 از 138,927,207 دامنه منتشرکننده SPF در ۹–۱۰ lookup هستند، و حداقل 797,263 بالا هستند — SPF آنها PermError برمیگرداند و هیچ چیز را محافظت نمیکند (دادهها تا 2026-06-29).
آیا include DMARC را هم رفع میکند؟ فقط اگر ابزار با return-path شما ارسال کند، پس SPF تأیید شود و همراستا باشد. برای بیشتر ابزارهای SaaS نیست — به همین دلیل DKIM همراستا، نه SPF، پایی است که DMARC را برای ایمیل SaaS تأیید میکند.
آیا این یک الزام قانونی در اتحادیه اروپا است؟ برای موجودیتهای در محدوده NIS2، ماده ۲۱(۲)(j) و آییننامه اجرایی (EU) 2024/2690 امنیت ایمیل را یک تعهد میکنند. حتی خارج از محدوده، بیمهگران و پرسشنامههای مشتری به طور فزاینده میپرسند — و تا 2026-06-29، هیچ ccTLD اروپایی حتی یک سوم دامنههایش را به یک سیاست DMARC اجرایی نرسانده (29.43٪ در .nl در بهترین حالت؛ 5.24٪ در .it).
گزارش را به صاحب ارسال کنید
وقتی CNAME ها زنده شدند، اسکن را دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار یا مشتری ارسال کنید. با زبان ساده نشان میدهد چه چیزی شکست میخورد، چه چیزی رفع کردید و دامنه اکنون کجا ایستاده — دقیقاً شواهدی که برای تمدید بیمه یا پرسشنامه امنیتی مشتری نیاز دارند، به صورت کتبی نه بر اساس حرف شما.
دامنه خود را رایگان بررسی کنید
ببینید دقیقاً کدام پای SPF، DKIM و DMARC شکست میخورد — به صورت خصوصی و فقط برای صاحب.
دامنهتان را بررسی کنید ← · رفع SPF ← · SPF PermError: «too many DNS lookups» ← · چطور درجهبندی میکنیم ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.