Defaults.Exposed › رفع اشکالها › Guides
SPF بعد از تغییر ارائهدهنده ایمیل متوقف شد — رفع مهاجرت (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
SPF معمولاً بعد از تغییر ارائهدهنده ایمیل خراب میشود چون رکورد ارائهدهنده جدید در کنار رکورد قدیمی اضافه شده. دو رکورد v=spf1 یک خطای دائمی هستند — SPF کاملاً باطل میشود. 1,013,416 دامنه — تقریباً یکی در 138 از آنهایی که SPF را تلاش میکنند — در آن وضعیت هستند، بر اساس سرشماری Defaults.Exposed از 261 میلیون دامنه. آنها را در یکی ادغام کنید.
رفع حدود ده دقیقه طول میکشد: دامنه را اسکن کنید تا ببینید مهاجرت دقیقاً چه باقی گذاشته، هر رکورد SPF را در nameserver های authoritative فهرست کنید، آنها را در یک رکورد واحد که فقط ارائهدهنده جدید را شامل میشود ادغام کنید، و با dig دوباره تأیید کنید. این راهنما هر گام را توضیح میدهد، به علاوه بررسیهای DKIM و nameserver که بیشتر مهاجرتها فراموش میکنند.
چرا SPF درست بعد از مهاجرت خراب شد؟
چون راهنمای تنظیم ارائهدهنده جدید گفت «این رکورد TXT را اضافه کن» — و شما کردید، در کنار رکورد قدیمی. این تنها چیزی است که استاندارد SPF اجازه نمیدهد. RFC 7208 (§3.2، نتیجه خطا مقرر در §4.5) دقیقاً یک رکورد v=spf1 در هر دامنه را مجاز میداند؛ گیرندهای که دو یا بیشتر پیدا کند باید PermError برگرداند نه حدس بزند کدام authoritative است. PermError به این معناست که SPF باطل است: نه رکورد قدیمی، نه رکورد جدید، اصلاً هیچ SPFی.
و اینجا متوقف نمیشود. DMARC یک PermError را به عنوان یک شکست روی پای SPF در نظر میگیرد، پس ایمیل شما اکنون کاملاً به DKIM وابسته است. اگر DKIM ارائهدهنده جدید هنوز هم تنظیم نشده — رایج در وسط مهاجرت — در لحظهای که زیرساخت را تغییر دادید، بدون احراز هویت ارسال میکنید، که وقتی گیرندهها شما را سختگیرانهترین بررسی میکنند است.
این copy-paste است که محافظت را وقتی ارائهدهنده عوض میکنید باطل میکند، و نادر نیست: 1,013,416 دامنه الان دو یا بیشتر رکورد SPF منتشر میکنند — تقریباً یکی در 138 از 139 میلیون جمعیتی که SPF را تلاش میکنند، بر اساس سرشماری Defaults.Exposed از 261 میلیون دامنه (دادهها تا 2026-06-29). اعداد کامل در مورد تله دو-رکورد گزارش خودشان را دارند؛ این صفحه رفع رویهای است.
مهاجرت چه باقی گذاشته؟
پنج باقیمانده تقریباً هر شکست SPF بعد از مهاجرت را ایجاد میکنند. آنها را به این ترتیب بررسی کنید:
| چه چیزی باقی گذاشته شده | چه میبینید | رفع |
|---|---|---|
رکورد SPF قدیمی، هنوز در DNS در کنار رکورد جدید (دو رکورد v=spf1) | بررسیکنندهها «multiple SPF records» یا PermError گزارش میدهند؛ SPF کاملاً متوقف میشود | در یک رکورد ادغام کنید، بقیه را حذف کنید — گامهای زیر |
include: ارائهدهنده قدیمی داخل رکورد واحد شما | SPF کار میکند، اما lookups DNS را هدر میدهید و سرورهای ارائهدهنده قدیمی همچنان میتوانند به عنوان شما ارسال کنند | بعد از اینکه ایمیل کاملاً از سیستم قدیمی تخلیه شد آن را حذف کنید |
include: ارائهدهنده جدید هرگز اضافه نشده | ایمیل از ارائهدهنده جدید SPF را در گیرندهها شکست میدهد | آن را به رکورد موجود واحد اضافه کنید — هرگز به عنوان یک رکورد جدید |
| انتخابگرهای DKIM برای ارائهدهنده جدید ایجاد نشدند | dkim=fail یا امضاها از دامنه پیشفرض ارائهدهنده؛ DMARC پای دومی ندارد | انتخابگرهای جدید را منتشر کنید — گام ۶ زیر |
| رکورد فقط در nameserver های قدیمی بهروزرسانی شده | پاسخهای مختلف بسته به اینکه از چه کسی میپرسید؛ شکستهای متناوب | zone را در nameserver های authoritative رفع کنید؛ هر دو مجموعه را در طول cutover تأیید کنید |
چطور رفع کنم؟ چکلیست مهاجرت
۱. ابتدا اسکن رایگان در defaults.exposed را اجرا کنید. DNS زنده شما را میخواند و میگوید آیا چندین رکورد SPF، یک include مفقود، یا یک شکاف DKIM دارید — قبل از لمس هر چیزی تشخیص دهید.
۲. هر رکورد SPF را در nameserver های authoritative فهرست کنید. dig +short NS yourdomain.com، سپس dig +short TXT yourdomain.com @<nameserver> در مقابل یکی از آنها. رشتههایی که با v=spf1 شروع میشوند را بشمارید. تنها تعداد ایمن ۱ است.
۳. در یک رکورد ادغام کنید. یک رکورد، شروع با v=spf1، حاوی include ارائهدهنده جدید و هر فرستنده دیگری که هنوز استفاده میکنید (ابزار صدور فاکتور، CRM، پلتفرم خبرنامه)، یک -all یا ~all terminal. مثال — Google Workspace قدیمی، Microsoft 365 جدید، در حین تخلیه:
Before: "v=spf1 include:_spf.google.com ~all"
"v=spf1 include:spf.protection.outlook.com -all"
After: "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later: "v=spf1 include:spf.protection.outlook.com -all"
مقادیر ارائهدهنده و ایرادات پانل DNS در راهنماهای تنظیم برای Google Workspace و Microsoft 365 هستند.
۴. رکوردهای اضافی را حذف کنید. ادغام بدون حذف هیچ چیز را رفع نمیکند — PermError از تعداد میآید.
۵. include ارائهدهنده قدیمی را فقط تا وقتی سیستم قدیمی هنوز ارسال میکند نگه دارید — گزارشهای برنامهریزی شده، یک connector CRM قدیمی، یک صندوق پستی فراموش شده. وقتی تخلیه انجام شد، آن را حذف کنید: یک include قدیمی زیرساخت قدیمی را مجاز میگذارد به عنوان شما ارسال کند، و هر include در مقابل سقف سخت ۱۰ lookup DNS هزینه میکند — حداقل 797,263 دامنه SPF را با بلوع از آن سقف باطل کردهاند (سرشماری، 2026-06-29).
۶. DKIM ارائهدهنده جدید را تنظیم کنید — و انتخابگرهای قدیمی را هنوز حذف نکنید. انتخابگرهای جدید ایمیلهای جدید را امضا میکنند؛ انتخابگرهای قدیمی باید تا وقتی هر پیام امضا شده با آنها تحویل داده شده و هر forward تسویه شده منتشر بمانند. راهنمای کامل در DKIM بعد از تغییر ابزارهای ایمیل شکست میخورد.
۷. اگر nameserver ها را هم تغییر دادید، هر دو را بررسی کنید. مهاجرتهای DNS اغلب با مهاجرتهای ایمیل همراه میشوند. مستقیماً هر دو مجموعه NS قدیمی و جدید را جستجو کنید (dig TXT yourdomain.com @old-ns و @new-ns) — تا وقتی delegation registrar کاملاً propagate شود، بعضی گیرندهها هنوز از سرورهای قدیمی میپرسند، پس رکورد رفع شده باید در هر مجموعهای که پاسخ میدهد وجود داشته باشد.
۸. اسکن را دوباره اجرا کنید و تأیید کنید SPF یک رکورد معتبر واحد با یک تأیید نشان میدهد.
SPF واقعاً کدام دامنه را بررسی میکند؟
گیرندهها SPF را در مقابل دامنه Return-Path (RFC5321.MailFrom) ارزیابی میکنند — آدرس bounce — نه هدر From که گیرندههایتان میبینند. بعد از یک مهاجرت این دوبار اهمیت دارد: ارائهدهنده جدید ممکن است تا وقتی یک bounce domain سفارشی پیکربندی کنید از bounce domain خودش استفاده کند، و SPF «تأیید شده» روی دامنهای که مال شما نیست برای DMARC همراستا نخواهد شد. رفع آن DKIM ارائهدهنده جدید است، امضا شده با دامنه شما.
مهاجرت و rebrand همزمان؟
دامنه را هم عوض کردید؟ آنها را به عنوان دو کار در نظر بگیرید. دامنه جدید از همان روز اول به stack کامل — SPF، DKIM، DMARC — نیاز دارد؛ از چکلیست ایمیل دامنه جدید استفاده کنید. دامنه قدیمی تا وقتی forwarding یا ترافیک reply از طریق آن جاری است احراز هویت شده باقی میماند، و وقتی پارک میشود صریحاً قفل میشود (نه فقط رها میشود). یک دامنه قدیمی با SPF نیمه-شکسته باقیمانده یک هدف جعل است که نام سابق شما را میپوشد.
پرسشهای متداول
آیا میتوانم در حین مهاجرت دو رکورد SPF نگه دارم؟
خیر. هیچ دوره مهلتی در استاندارد وجود ندارد — دو رکورد v=spf1 از لحظهای که دومی وجود داشته باشد یک PermError هستند، و 1,013,416 دامنه تا سرشماری (2026-06-29) در آن وضعیت نشستهاند. الگوی safe مهاجرت یک رکورد است که در طول overlap شامل includes هر دو ارائهدهنده میشود.
چقدر باید include ارائهدهنده قدیمی را نگه دارم؟ تا وقتی هیچ چیزی از طریق ارائهدهنده قدیمی ارسال نمیکند — معمولاً طول پنجره overlap، روزها تا چند هفته. Return-Path هر چیزی که هنوز از طریق سیستم قدیمی میرسد را تماشا کنید؛ وقتی آن ترافیک متوقف شد، include را حذف کنید و تعداد lookup را دوباره بررسی کنید.
چرا یک بررسیکننده بعد از رفع آن هنوز رکورد قدیمی را نشان میدهد؟
DNS caching TTL رکورد را رعایت میکند، و اگر nameserver ها تغییر کردند، بعضی resolver ها همچنان مجموعه قدیمی را جستجو میکنند. مستقیماً در nameserver های authoritative با dig TXT yourdomain.com @<ns> تأیید کنید — اگر پاسخ آنجا درست است، رفع انجام شده و cacheها بزودی بهروز میشوند. اگر در یک مجموعه NS اشتباه است، «رکورد SPF پیدا نشد» — علتهای واقعی را ببینید.
آیا باید وقتی ارائهدهنده عوض میکنم DMARC را تغییر دهم؟ معمولاً نه خود رکورد را — صندوق پستی گزارش و سیاست شما را نام میبرد، نه ارائهدهنده. اما نتایج DMARC شما به SPF و DKIM که تازه مهاجرت کردید بستگی دارند: یک افت در گزارشها در طول cutover انتظار داشته باشید، و تأیید کنید هر دو پا تأیید میشوند قبل از اینکه سیاست را سختگیرانهتر کنید. از رفع SPF شروع کنید اگر اسکن نشان میدهد پای SPF همچنان شکست میخورد.
گزارش را به صاحب ارسال کنید
اگر این مهاجرت را برای یک مشتری انجام میدهید، با شواهد تمام کنید. اسکن رایگان را وقتی ادغام زنده است دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار ارسال کنید: SPF، DKIM و DMARC در ارائهدهنده جدید تأیید میشوند، با زبان ساده، تاریخدار. این همان چیزی است که برای تمدید بیمه سایبری و پرسشنامه امنیتی بعدی تأمینکننده ثبت میکنند — اثبات اینکه مهاجرت دامنه را بهتر احراز هویت شده از آنچه شروع کرد باقی گذاشته.
دامنهتان را بررسی کنید ← · DKIM بعد از تغییر ابزارهای ایمیل شکست میخورد ← · «رکورد SPF پیدا نشد» — علتهای واقعی ← · چطور درجهبندی میکنیم ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.