Defaults.Exposed › रिपोर्ट

SPF ptr Mechanism क्या है — और यह अभी भी 950,631 रिकॉर्ड में क्यों है? (2026)

प्रकाशित 2026-07-03

आंकड़े 2026-06-29 तक · कार्यप्रणाली v7. 261 मिलियन ग्रेड किए गए डोमेन में समग्र जनगणना। सभी आंकड़े समग्र हैं — कभी भी किसी व्यक्तिगत व्यवसाय का रिकॉर्ड नहीं। देखें हम कैसे ग्रेड करते हैं।

ptr एक SPF mechanism है जो reverse-DNS lookup द्वारा senders को अधिकृत करता है — और SPF मानक ने खुद 2014 से कहा है कि “इसका उपयोग न करें”। 12 साल बाद, 950,631 डोमेन अभी भी इसे प्रकाशित करते हैं। यह इंटरनेट पर 139 मिलियन SPF रिकॉर्डों में से लगभग 146 में 1 है जो specification से deprecated mechanism वहन कर रहा है इससे पहले कि कुछ डोमेन पंजीकृत हुए।

ptr क्या करने वाला था

ptr कहता है: “किसी भी सर्वर से मेल स्वीकार करें जिसका reverse DNS मेरे डोमेन पर वापस हल हो।” यह elegant लगता है — कोई IP सूचियाँ बनाए रखने की जरूरत नहीं। व्यवहार में इसके लिए रिसीवर को connecting IP पर reverse lookup करना होगा, फिर हर उस hostname को forward-confirm करना होगा जो वापस आती है। RFC 7208 (§5.5) ने इसे सरल शब्दों में deprecated किया: mechanism “धीमी है, DNS errors के मामलों में अन्य mechanisms की तरह विश्वसनीय नहीं है, और .arpa name servers पर एक बड़ी resource requirement रखती है” — और निर्देश देती है कि इसे “SHOULD NOT उपयोग किया जाना चाहिए।“

यह 2026 में अभी भी एक trap क्यों है

एक mechanism के 12 साल पहले deprecated होने के तीन कारण:

• यह आपका lookup budget जलाता है। हर ptr SPF के 10 DNS lookups की hard ceiling के विरुद्ध गिनता है — वह सीमा जो, एक बार exceeded होने पर, PermError के साथ पूरे रिकॉर्ड को शून्य करती है। एक mechanism जो कुछ भी विश्वसनीय नहीं करती, फिर भी आपको वह budget खर्च करती है जिसकी आपकी वास्तविक include: mechanisms को जरूरत है।
• यह अप्रत्याशित रूप से विफल होती है। Reverse DNS अधिकांश networks का सबसे कम-maintained कोना है। जब ptr lookup timeout होता है या forward-confirm विफल होता है, आपका legitimate mail SPF pass खो देता है।
• कुछ receivers इसे पूरी तरह skip करते हैं। क्योंकि standard इसे deprecated करता है, कुछ implementations simply ptr को ignore करते हैं।

यह कहाँ से आता है

आज लगभग कोई भी ptr नहीं चुनता। यह inheritance द्वारा आता है: 2009 में लिखी गई एक setup guide, एक पुरानी server config से copied template, तीन hosting moves के माध्यम से intact migrate किया गया “working” रिकॉर्ड। पुरानी सलाह नहीं मरती, वह copy-paste हो जाती है। ptr वहन करने वाले domains लापरवाह नहीं हैं — वे 12 साल पहले retire किए गए instructions का पालन कर रहे हैं।

इसे ठीक करें — मुफ्त, पाँच मिनट

1. अपना SPF रिकॉर्ड खोजें (dig TXT yourdomain.com या मुफ्त जाँच करें)।
2. अगर इसमें ptr है, तो पहचानें कि कौन से servers इस पर rely कर रहे थे।
3. ptr को सटीक form से बदलें: आप जो servers control करते हैं उनके लिए ip4:/ip6: block, या आपके provider द्वारा documented include:।
4. जब आप वहाँ हों, confirm करें कि रिकॉर्ड एक वास्तविक qualifier में समाप्त होता है — देखें ~all बनाम -all।

अक्सर पूछे जाने वाले प्रश्न

SPF रिकॉर्ड में ptr का क्या मतलब है? यह किसी भी सर्वर को अधिकृत करता है जिसका reverse DNS आपके डोमेन में हल होता है। RFC 7208 §5.5 ने इसे 2014 में slow और unreliable के रूप में deprecated किया, और कहता है कि इसे SHOULD NOT उपयोग किया जाना चाहिए।

क्या SPF ptr mechanism कभी valid है? यह अभी भी parse होती है, और कुछ receivers अभी भी इसे evaluate करते हैं — लेकिन standard सभी मामलों में इसके विरुद्ध सलाह देता है। कोई आधुनिक configuration नहीं है जहाँ ptr सही जवाब है।

ptr के बजाय मुझे क्या उपयोग करना चाहिए? आप जो servers control करते हैं उनके लिए ip4:/ip6: blocks, या आपके provider का documented include:।

क्या ptr SPF 10-lookup limit की ओर गिनता है? हाँ — हर ptr receiver द्वारा PermError के साथ छोड़ने से पहले perform किए जाने वाले दस DNS lookups में से कम से कम एक खर्च करता है।

ghost के लिए अपना रिकॉर्ड जाँचें

12 साल पहले deprecated एक mechanism, अभी भी आपके DNS में बैठी है, वही है जिसे कोई नहीं ढूंढता। देखने में आधा मिनट लगता है।

अपना डोमेन जाँचें → · SPF ठीक करें → · दो SPF रिकॉर्ड = कुछ नहीं → · SPF परिपक्वता मॉडल → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित किया गया।