Defaults.Exposed › رفع اشکال‌ها › Guides

«رکورد SPF پیدا نشد» — اما شما یکی دارید؟ ۵ دلیل واقعی (۲۰۲۶)

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

ارقام تا تاریخ 2026-06-29 · روش‌شناسی نسخه ۷. داده‌های آماری انبوه از 261 میلیون دامنه درجه‌بندی‌شده. نحوه درجه‌بندی ما را ببینید.

اگر یک ابزار بررسی می‌گوید «رکورد SPF پیدا نشد» اما مطمئنید که یکی منتشر کرده‌اید، رکورد معمولاً نامرئی است نه گم‌شده: 1,013,416 دامنه — تقریباً یک از هر 138 دامنه‌ای که SPF را تلاش می‌کنند — دو یا چند رکورد SPF دارند، یک PermError (RFC 7208 §3.2) که بسیاری از ابزارها آن را به‌عنوان «پیدا نشد» گزارش می‌دهند، بر اساس سرشماری Defaults.Exposed از 261 میلیون دامنه.

پنج دلیل واقعی وجود دارد که همه در یک نشست قابل رفع هستند: هاست اشتباه، رکورد تکراری، نوع DNS اشتباه یا نقل‌قول خراب، name server های ناسازگار، یا تداخل طول/CNAME. در ادامه: آزمون ۶۰ ثانیه‌ای برای هر یک، به ترتیب بررسی، سپس مراحل رفع.

آیا مطمئنید رکورد واقعاً وجود دارد؟

از احتمال ناخوشایند شروع کنید، چون بسیار رایج‌ترین حالت است: از 261,086,232 دامنه درجه‌بندی‌شده در سرشماری Defaults.Exposed، 121,145,609 دامنه — 46.4% — اصلاً رکورد SPF ندارند. بسیاری از موارد «اما من این را تنظیم کردم» درنهایت نشان می‌دهد که رکورد به یک zone staging یا یک ارائه‌دهنده DNS قدیمی که دیگر معتبر نیست اضافه شده. ارائه‌دهنده DNS که name server های شما به آن اشاره می‌کنند (که اغلب registrar شما نیست) را برای یک رکورد TXT که با v=spf1 شروع می‌شود بررسی کنید. اگر واقعاً آنجا نیست، از کارآگاهی دست بکشید و مستقیماً به رفع رکورد SPF بروید.

چطور یک رکورد SPF را به‌درستی بررسی کنید؟

ابزارهای تحت وب، DNS را از طریق resolver کش‌کننده خودشان بررسی می‌کنند. برای دیدن حقیقت، مستقیماً از name server معتبر دامنه‌تان بخواهید:

# name server های معتبر را پیدا کنید
dig NS yourdomain.com +short

# مستقیماً از یکی از آن‌ها رکورد TXT بخواهید
dig TXT yourdomain.com @ns1.yourdnshost.com +short

در ویندوز: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

دو قانون تفسیر. اول، خطوطی که با v=spf1 شروع می‌شوند را بشمارید — تعداد به‌اندازه محتوا مهم است. دوم، بررسی کنید نام صحیح را query کرده‌اید: گیرندگان SPF را در برابر دامنه Return-Path (RFC5321.MailFrom، «envelope from») ارزیابی می‌کنند — نه آدرس From که گیرندگان می‌بینند. اگر ابزار خبرنامه شما ایمیل را از طریق bounce.yourdomain.com ارسال می‌کند، یک رکورد کامل در apex، رکوردی نیست که گیرندگان جستجو می‌کنند.

پنج دلیل واقعی چیست؟

داده‌ها تا تاریخ 2026-06-29.

۱. آیا رکورد در هاست اشتباه است؟

کلاسیک: SPF به mail.yourdomain.com اضافه شده در حالی که ایمیل ادعا می‌کند از yourdomain.com می‌آید، یا برعکس. SPF به پایین ارث نمی‌برد — یک رکورد در apex چیزی درباره subdomain ها نمی‌گوید، و برعکس. دقیقاً در نامی که در Return-Path شما است منتشر کنید. یک فروشنده که از subdomain bounce خودش ارسال می‌کند به یک رکورد روی آن subdomain نیاز دارد — معمولاً یک CNAME یا TXT که فروشنده تأمین می‌کند (راهنمای تنظیم SPF در GoDaddy نشان می‌دهد این فیلدها کجا هستند).

۲. آیا دو رکورد SPF دارید؟

دلیل اصلی، و گمراه‌کننده‌ترین پیام خطا در احراز هویت ایمیل. RFC 7208 §3.2 صریح است: یک دامنه باید دقیقاً یک رکورد SPF داشته باشد. دو یا بیشتر یک PermError است — گیرندگان SPF شما را باطل می‌دانند. برخی ابزارها آن حالت را به‌درستی گزارش می‌کنند («چند رکورد پیدا شد»)؛ دیگران نتیجه نهایی را گزارش می‌کنند: هیچ رکورد SPF معتبری پیدا نشد. شما یک رکورد در panel خود می‌بینید و نتیجه می‌گیرید ابزار خراب است. نیست — یک رکورد اضافه دارید.

سرشماری 1,013,416 دامنه با دو یا چند رکورد SPF را یافت — تقریباً یک از هر 138 دامنه‌ای که SPF را تلاش می‌کنند — هر یک با SPF عملاً خاموش. معمولاً در طول تغییر ارائه‌دهنده اتفاق می‌افتد: wizard ارائه‌دهنده جدید به‌جای ویرایش رکورد قدیمی، یک رکورد جدید اضافه می‌کند. راه‌حل یک ادغام است، نه یک رکورد دوم: همه چیز را در یک خط v=spf1 … ~all ترکیب کنید و بقیه را حذف کنید. گزارش داده ما دو رکورد SPF برابر با هیچ نشان می‌دهد چطور یک میلیون دامنه به اینجا رسیده‌اند؛ اگر بعد از مهاجرت شروع شده، SPF بعد از تغییر ارائه‌دهنده از کار افتاد را ببینید. در حین ادغام، کورکورانه هر include: را الحاق نکنید — هر کدام یک lookup DNS در برابر محدودیت سخت ۱۰ تایی SPF هزینه دارد که «پیدا نشد» را با PermError: بیش از حد DNS lookup جایگزین می‌کند.

۳. آیا نوع رکورد اشتباه منتشر کردید — یا UI آن را خراب کرد؟

SPF اولیه نوع رکورد DNS مخصوص خودش داشت (نوع ۹۹، با نام واقعی «SPF»). منسوخ شد: RFC 7208 TXT را الزامی می‌کند، و گیرندگان نوع ۹۹ را query نمی‌کنند. برخی panel های DNS هنوز «SPF» را در dropdown نوع رکورد ارائه می‌دهند؛ آن را انتخاب کنید و رکورد شما واقعی، خوش‌شکل، و نامرئی است. ستون نوع را بررسی کنید و به‌عنوان TXT دوباره منتشر کنید.

مشکل ظریف‌تر نقل‌قول است. paste کردن یک مقدار با نقل‌قول در یک فیلدی که خودش نقل‌قول اضافه می‌کند، ""v=spf1 …"" تولید می‌کند — که دیگر با v=spf1 شروع نمی‌شود، پس برای یک verifier وجود ندارد. خروجی dig شما حقیقت را نشان می‌دهد؛ panel DNS اغلب آن را به‌صورت زیبایی پنهان می‌کند.

۴. آیا واقعاً «هنوز در حال انتشار» است؟

«۲۴-۴۸ ساعت برای انتشار صبر کنید» رایج‌ترین توصیه بیش‌تجویزشده در DNS است. انتشار فقط انقضای کش‌ها است: وقتی TTL رکورد گذشت (معمولاً ۱ ساعت، به‌ندرت بیشتر از ۲۴)، هر resolver می‌تواند پاسخ جدید را ببیند. بعد از ۲۴ ساعت هنوز پیدا نمی‌شود؟ انتشار دلیل نیست.

دو مقصر واقعی: کش منفی — یک resolver که شما را قبل از اینکه رکورد اضافه کنید جستجو کرد، پاسخ «چنین رکوردی وجود ندارد» را تا انقضای TTL منفی کش می‌کند — و name server های ناسازگار بعد از مهاجرت، جایی که دامنه هنوز name server های ارائه‌دهنده قدیمی را در کنار جدید فهرست می‌کند و نیمی از دنیا zone ای را می‌خواند که دیگر ویرایش نمی‌کنید. هر name server فهرست‌شده را مستقیماً query کنید؛ اگر پاسخ‌ها متفاوت باشند، پیدایش کردید. delegation NS در registrar را رفع کنید تا فقط ارائه‌دهنده‌ای که واقعاً ویرایش می‌کنید معتبر باشد.

۵. آیا رکورد خیلی طولانی است، یا یک CNAME آن را مسدود کرده؟

یک رشته در یک رکورد TXT حداکثر ۲۵۵ کاراکتر دارد. رکوردهای SPF طولانی‌تر قانونی هستند اما باید در یک رکورد به چند رشته نقل‌قول‌شده تقسیم شوند — و رابط‌های ارائه‌دهنده DNS به‌طور منظم تقسیم را خراب می‌کنند، مقدار را کوتاه می‌کنند یا آن را در میان یک مکانیزم می‌شکنند تا دیگر parse نشود. اگر رکوردتان طولانی است، خروجی dig را برای مقداری که ناگهان قطع می‌شود بررسی کنید.

جداگانه، DNS یک رکورد TXT را در نامی که قبلاً یک CNAME دارد ممنوع می‌کند. اگر mail.yourdomain.com یک CNAME به ارائه‌دهنده شماست، نمی‌توانید SPF را هم آنجا قرار دهید — برخی panel ها آن را قبول می‌کنند و سپس فقط CNAME را سرو می‌کنند. رکورد را جایی قرار دهید که CNAME به آن اشاره می‌کند (اگر کنترل دارید)، یا ساختار را طوری بچینید که نام ارسال‌کننده CNAME شده نباشد. ارائه‌دهندگان با مدیریت TXT تمیز هر دو را آسان‌تر می‌کنند — راهنمای تنظیم SPF در Cloudflare را ببینید.

چطور آن را مرحله به مرحله رفع کنید؟

۱. اسکن رایگان را در defaults.exposed اجرا کنید — DNS زنده شما را می‌خواند و قبل از هر تغییری می‌گوید در کدام‌یک از پنج حالت هستید. ۲. تأیید کنید کدام name server ها معتبر هستند (dig NS) و همه موافق هستند. ۳. TXT را از name server معتبر برای دامنه Return-Path دقیق query کنید. ۴. خطوط v=spf1 را بشمارید: صفر ← یکی منتشر کنید؛ دو یا بیشتر ← در یکی ادغام کنید. ۵. تأیید کنید نوع TXT است، مقدار دقیقاً با v=spf1 شروع می‌شود، و هیچ نقل‌قول اضافه یا کوتاه‌شدگی وارد نشده. ۶. یک TTL صبر کنید، سپس دوباره اسکن کنید تا مطمئن شوید در همه‌جا به‌درستی بارگذاری می‌شود.

پرسش‌های متداول

چرا ابزار می‌گوید «پیدا نشد» در حالی که رکورد را در panel DNS خودم می‌بینم؟ معمولاً دلیل ۲ یا ۴: یک رکورد دوم v=spf1 هر دو را باطل می‌کند — یک PermError که برخی ابزارها آن را به‌عنوان «پیدا نشد» گزارش می‌کنند، حالتی که 1,013,416 دامنه تا 2026-06-29 در آن هستند — یا panel شما DNS ای نیست که واقعاً معتبر است.

تا کی ابزارها رفع من را می‌بینند؟ یک TTL — معمولاً یک ساعت، حداکثر ۲۴. بعد از آن، «انتشار» توضیح نیست؛ پنج دلیل را مجدداً بررسی کنید، با سازگاری name server شروع کنید.

آیا باید از نوع رکورد «SPF» که panel DNS من ارائه می‌دهد استفاده کنم؟ خیر. نوع ۹۹ منسوخ شده؛ RFC 7208 فقط TXT را الزامی می‌کند. یک رکورد نوع ۹۹ برای گیرندگان مدرن نامرئی است.

رکورد الان پیدا می‌شود — چرا ایمیلم هنوز SPF را شکست می‌خورد؟ چون SPF در برابر دامنه Return-Path بررسی می‌شود، نه header From، و رکورد باید واقعاً سرورهایی که برای شما ارسال می‌کنند را فهرست کند. پیدا شدن مرحله اول است؛ راهنمای رفع رکورد SPF پاس شدن را پوشش می‌دهد.

آیا نداشتن رکورد SPF واقعاً آنقدر رایج است؟ بله — 121,145,609 دامنه، 46.4% از 261,086,232 درجه‌بندی‌شده در سرشماری Defaults.Exposed (تا 2026-06-29)، اصلاً SPF منتشر نمی‌کنند. «پیدا نشد» حالت پیش‌فرض اینترنت است.

گزارش را برای صاحب دامنه بفرستید

وقتی رکورد به‌درستی بارگذاری شد، اسکن را دوباره اجرا کنید و گزارش درجه‌بندی‌شده را برای صاحب کسب‌وکار یا مشتری‌ای که دامنه برای اوست بفرستید. به زبان ساده نشان می‌دهد چه چیزی خراب بود، چه چیزی رفع شد، و دامنه الان کجا ایستاده — دقیقاً همان مدرکی که در تمدید بیمه سایبری و پرسشنامه‌های امنیتی تامین‌کنندگان از آن‌ها خواسته می‌شود. گزارش رسید کار است.

رکورد SPF خود را رایگان بررسی کنید

ببینید دامنه‌تان در کدام‌یک از پنج حالت «پیدا نشد» است — به‌صورت خصوصی و فقط برای صاحب.

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