مکانیزم ptr در SPF چیست — و چرا هنوز در 950,631 رکورد وجود دارد؟ (۲۰۲۶)

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

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

ptr مکانیزمی در SPF است که فرستنده‌ها را از طریق جست‌وجوی معکوس DNS (reverse-DNS) مجاز می‌شمارد — و خودِ استاندارد SPF از سال ۲۰۱۴ گفته است «از آن استفاده نکنید». 12 سال بعد، 950,631 دامنه هنوز آن را منتشر می‌کنند. این تقریباً ۱ از هر 146 از 139 میلیون رکورد SPF موجود در اینترنت است که مکانیزمی را حمل می‌کند که استاندارد آن را پیش از ثبت برخی از همان دامنه‌ها منسوخ کرده بود.

ptr قرار بود چه کاری انجام دهد

ptr می‌گوید: «نامه‌ای را از هر سروری که DNS معکوسش به دامنه‌ی من بازمی‌گردد بپذیر.» این ظاهراً ظریف به نظر می‌رسد — هیچ فهرست IP‌ای برای نگهداری وجود ندارد. اما در عمل، گیرنده را ملزم می‌کند که روی IPِ متصل‌شونده یک جست‌وجوی معکوس انجام دهد و سپس هر نام میزبانی (hostname) را که بازمی‌گردد با تأیید مستقیم (forward-confirm) بررسی کند. RFC 7208 (بند ۵.۵) آن را با کلماتی صریح منسوخ کرد: این مکانیزم «کند است، در موارد بروز خطاهای DNS به اندازه‌ی سایر مکانیزم‌ها قابل‌اعتماد نیست، و بار منابع بزرگی را بر نام‌سرورهای arpa. تحمیل می‌کند» — و دستور می‌دهد که «نباید (SHOULD NOT) استفاده شود.»

چرا در سال ۲۰۲۶ هنوز یک تله است

سه دلیل که چرا مکانیزمی که 12 سال پیش منسوخ شد هنوز اهمیت دارد:

بودجه‌ی جست‌وجوی شما را می‌سوزاند. هر ptr در برابر سقف سخت SPF یعنی ۱۰ جست‌وجوی DNS در هر بررسی محاسبه می‌شود — همان محدودیتی که وقتی از آن فراتر رود، کل رکورد را با یک PermError باطل می‌کند. مکانیزمی که هیچ کار قابل‌اعتمادی انجام نمی‌دهد همچنان بودجه‌ای را که مکانیزم‌های واقعی include: شما به آن نیاز دارند مصرف می‌کند.
به‌طور غیرقابل‌پیش‌بینی شکست می‌خورد. DNS معکوس کم‌نگهداری‌شده‌ترین گوشه‌ی بیشتر شبکه‌هاست. وقتی جست‌وجوی ptr به‌اتمام مهلت (timeout) می‌رسد یا تأیید مستقیم شکست می‌خورد، نامه‌ی مشروع شما پاس شدن SPF‌ای را که روی آن حساب کرده بود از دست می‌دهد.
برخی گیرنده‌ها آن را کاملاً نادیده می‌گیرند. چون استاندارد آن را منسوخ می‌کند، برخی پیاده‌سازی‌ها به‌سادگی ptr را نادیده می‌گیرند — بنابراین فرستنده‌هایی که قرار بود مجاز شمرده شوند، از همان ابتدا هرگز محافظت نشده بودند.

از کجا می‌آید

امروزه تقریباً هیچ‌کس ptr را انتخاب نمی‌کند. این از راه ارث می‌رسد: یک راهنمای پیکربندی نوشته‌شده در سال ۲۰۰۹، یک قالب کپی‌شده از یک پیکربندی قدیمی سرور، یک رکورد «کارآمد» که دست‌نخورده از میان سه جابه‌جایی میزبانی منتقل شده است. این همان الگویی است که سرشماری ما در هر مکانیزمِ منسوخ‌شده اما موجود می‌بیند: توصیه‌ی قدیمی نمی‌میرد، بلکه کپی-پیست می‌شود. دامنه‌هایی که ptr را حمل می‌کنند بی‌دقت نیستند — آن‌ها از دستورالعمل‌هایی پیروی می‌کنند که 12 سال پیش بازنشسته شدند.

چگونه آن را رفع کنیم — رایگان، پنج دقیقه

رکورد SPF خود را پیدا کنید (dig TXT yourdomain.com یا بررسی رایگان).
اگر حاوی ptr است، مشخص کنید کدام سرورها به آن متکی بوده‌اند.
ptr را با شکل دقیق جایگزین کنید: یک بلوک ip4:/ip6: برای سرورهایی که تحت کنترل شما هستند، یا include:‌ای که ارائه‌دهنده‌ی شما مستند کرده است.
حالا که آنجا هستید، تأیید کنید که رکورد به یک واجدشرط (qualifier) واقعی ختم می‌شود — ببینید ~all در برابر -all.

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

ptr در یک رکورد SPF چه معنایی دارد؟ هر سروری را که DNS معکوسش به دامنه‌ی شما بازمی‌گردد مجاز می‌شمارد. RFC 7208 بند ۵.۵ آن را در سال ۲۰۱۴ به‌عنوان مکانیزمی کند و غیرقابل‌اعتماد منسوخ کرد و می‌گوید نباید (SHOULD NOT) استفاده شود — با این حال تا تاریخ 2026-06-29 هنوز 950,631 دامنه آن را منتشر می‌کنند.

آیا مکانیزم ptr در SPF هرگز معتبر است؟ هنوز تجزیه (parse) می‌شود و برخی گیرنده‌ها هنوز آن را ارزیابی می‌کنند — اما استاندارد در همه‌ی موارد آن را توصیه نمی‌کند، برخی گیرنده‌ها نادیده‌اش می‌گیرند، و یکی از ده جست‌وجوی DNS شما را مصرف می‌کند. هیچ پیکربندی مدرنی وجود ندارد که در آن ptr پاسخ درست باشد.

به‌جای ptr از چه چیزی باید استفاده کنم؟ بلوک‌های ip4:/ip6: برای سرورهایی که تحت کنترل شما هستند، یا include: مستندشده‌ی ارائه‌دهنده‌تان. هر دو قطعی، سریع و قابل‌اعتماد هستند — همه‌ی آنچه ptr نیست.

آیا ptr در محدودیت ۱۰ جست‌وجوی SPF محاسبه می‌شود؟ بله — هر ptr دست‌کم یکی از ده جست‌وجوی DNS‌ای را که گیرنده پیش از تسلیم شدن با یک PermError انجام می‌دهد مصرف می‌کند. در رکوردهایی که پیش‌تر با مکانیزم‌های include: انباشته شده‌اند، این مکانیزم مرده می‌تواند همانی باشد که شما را از حد فراتر می‌برد.

رکورد خود را از نظر اشباح بررسی کنید

مکانیزمی که 12 سال پیش منسوخ شد و هنوز در DNS شما نشسته است، دقیقاً از آن دست چیزهایی است که هیچ‌کس دنبالش نمی‌گردد. نگاه کردن نیم دقیقه طول می‌کشد.

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