Defaults.Exposed › रिपोर्ट

SPF PermError रिपोर्ट: 100× अधिक डोमेन 10-लुकअप सीमा तोड़ते हैं जितना Surface काउंट दिखाते हैं (2026)

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

आंकड़े 2026-06-29 तक · कार्यप्रणाली v7, साथ ही 2026-07-03 को चलाई गई chain-pricing pass। 261 मिलियन ग्रेड किए गए डोमेन की जनगणना से, हमने 100 या अधिक बार संदर्भित हर SPF include: target को हल किया — 10,842 targets जो सभी include संदर्भों के 95.2% को कवर करते हैं — और उस मानचित्र के विरुद्ध प्रत्येक डोमेन की बनाए रखी गई chain की कीमत लगाई। अनहल tail targets को शून्य के रूप में गिना गया इसलिए शीर्षक एक रूढ़िवादी, फर्श-पक्षपाती अनुमान है: हम “कम से कम” कहते हैं। केवल समग्र; कभी किसी व्यक्तिगत व्यवसाय का रिकॉर्ड नहीं। देखें हम कैसे ग्रेड करते हैं।

कितने डोमेन SPF 10-लुकअप सीमा तोड़ते हैं?

कम से कम 797,263 — क्योंकि SPF में मानक में एक आत्म-विनाश बना हुआ है, और ट्रिगर वहाँ छुपा है जहाँ मालिक इसे नहीं देख सकते। RFC 7208 §4.6.4 एक SPF जाँच को 10 DNS लुकअप पर सीमित करता है; दस के बाद, रिसीवर रुक जाता है और PermError लौटाता है, और PermError रिकॉर्ड कुछ भी सुरक्षित नहीं करता। केवल रिकॉर्ड में दिखाई देने वाले लुकअप गिनें — जैसा कि अधिकांश टूलिंग करती है — और आपको लगभग 8,000 अपराधी मिलेंगे (सटीक रूप से 7,958)। उन रिकॉर्डों द्वारा वास्तव में खींची गई include: chains की कीमत लगाएं, और गिनती 797,263 तक पहुँचती है: लगभग 100 गुना बड़ी।

मालिक इसे आते हुए क्यों नहीं देख सकते?

क्योंकि बजट दूसरे लोगों के रिकॉर्ड द्वारा खर्च किया जाता है। include:onetool.example.com आपके DNS पैनल में एक लाइन के रूप में पढ़ता है — लेकिन रिसीवर को उस रिकॉर्ड को भी प्राप्त करना होगा, और हर लुकअप तंत्र को गिनना होगा जो इसमें शामिल है, पुनरावर्ती रूप से। तीन includes वाला एक रिकॉर्ड ग्यारह की लागत लगा सकता है। आपके अपने ज़ोन में उस दिन कुछ नहीं बदला जब आप सीमा से अधिक गए; एक प्रदाता ने एक और include nested किया, और आपका SPF बिना चेतावनी के मर गया।

इससे भी बुरा, DMARC एक PermError को SPF leg पर fail के रूप में मानता है — इसलिए एक डोमेन जिसने इस तरह अपना SPF तोड़ा अब अपने स्वयं के प्रमाणीकरण का आधा हिस्सा विफल कर रहा है।

Chain-pricing ने क्या पाया

निष्कर्ष	डोमेन
10-लुकअप सीमा से अधिक, chains की कीमत लगाई	797,263
केवल दृश्यमान तंत्र गिनकर सीमा से अधिक	7,958
सीमा से अधिक सख्त `-all` में समाप्त करते हुए	112,215
ठीक 9–10 लुकअप पर — cliff edge	2,119,539

उस तालिका में दो कहानियाँ — तीसरी, cliff edge, का अपना अनुभाग नीचे है:

Surface काउंट ~99% टूटना चूक जाते हैं। दृश्यमान-तंत्र गिनती 7,958 पाती है; chains की कीमत लगाने से 797,263 मिलते हैं। लगभग सभी नुकसान includes द्वारा inherited है।
टूटे हुए रिकॉर्डों में से 112,215 -all में समाप्त होते हैं। उनके मालिकों ने सब कुछ सही किया — दीवार चढ़ी, सख्त एंडिंग चुनी — और एक include ने सब कुछ शून्य कर दिया।

2.1 मिलियन डोमेन एक टूल से cliff से दूर हैं

वह संख्या जो वर्तमान में ठीक पाठकों को चिंतित करनी चाहिए: 2,119,539 डोमेन ठीक 9 या 10 लुकअप तक हल होते हैं — आज सीमा के अंदर, उस दिन मृत जब कोई एक और प्लेटफ़ॉर्म कनेक्ट करता है। यह सभी SPF प्रकाशकों में से लगभग 66 में 1 है, और यह distribution के आकार से मेल खाता है: 99वें-percentile SPF record पहले से ही 9 lookups पर बैठा है। एक और marketing tool के लिए sign up करें, इसकी “बस यह include जोड़ें” लाइन paste करें, और एक record जो नाश्ते पर सीमा के अंदर था वह दोपहर के खाने तक शून्य है।

किसकी गलती है? तेजी से, stack की

सबसे बड़े प्रदाताओं ने चुपचाप अपना SPF flatten कर लिया है — Google का _spf.google.com और Microsoft का spf.protection.outlook.com अब plain IP lists तक expand होते हैं जो शून्य internal lookups लागत करते हैं। Blowouts अन्यत्र से आते हैं: hosting-panel chains जो तीन गहरे nest करते हैं, क्षेत्रीय प्रदाता जिनकी include 7–10 lookups खर्च करती है अपने आप, और SaaS का ईमानदार संचय — mailbox plus newsletter plus CRM plus helpdesk, प्रत्येक “बस एक include”।

मुफ्त में जाँचें और ठीक करें

अपना वास्तविक कुल गिनें — हमारी मुफ्त जाँच आपकी chain को हल करती है, या किसी SPF lookup counter का उपयोग करें।
मृत वजन छाँटें: जो tools आपने उपयोग करना बंद कर दिया, duplicate includes, और deprecated ptr mechanism।
केवल वही flatten करें जो आप control करते हैं। एक deep include को उसके IP blocks से बदलना आपके अपने infrastructure के लिए काम करता है; third-party IPs बिना notice के बदलते हैं।
bulk senders को एक subdomain दें। news.yourdomain.com से newsletters का अपना रिकॉर्ड और अपना 10-lookup budget मिलता है।

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

SPF 10 DNS lookup सीमा क्या है? RFC 7208 §4.6.4 एक SPF रिकॉर्ड को evaluate करने के लिए अधिकतम 10 DNS lookups की अनुमति देता है — हर include: के अंदर lookups को पुनरावर्ती रूप से गिनते हुए। इससे अधिक होने पर PermError लौटाता है: रिकॉर्ड invalid माना जाता है और कोई सुरक्षा प्रदान नहीं करता।

SPF PermError का क्या मतलब है? एक permanent evaluation error — रिसीवर आपके रिकॉर्ड को process नहीं कर सका और आपके डोमेन को कोई उपयोगी SPF नहीं होने के रूप में मानता है। DMARC इसे SPF leg पर fail के रूप में गिनता है।

कितने डोमेन SPF lookup सीमा से अधिक हैं? हमारी chain-pricing pass के अनुसार 139 मिलियन SPF प्रकाशकों में से कम से कम 797,263 — chains को हल किए बिना दिखाई देने वाले 7,958 से लगभग 100× अधिक। एक और 2,119,539 9–10 lookups पर बैठे हैं, एक include से सीमा तक।

क्या PermError मेरी email delivery रोकती है? आमतौर पर नहीं — रिसीवर SPF के बिना आगे बढ़ते हैं। जो रुकता है वह सुरक्षा है: forgers को अब अस्वीकार नहीं किया जाता।

मैं अपनी SPF lookup count कैसे कम करूँ? अप्रयुक्त includes और ptr हटाएं, अपने infrastructure को ip4:/ip6: पर flatten करें, bulk senders को subdomains पर ले जाएं, और हर नए tool के बाद पुनः गिनें।

अपना वास्तविक नंबर जानें

जो तंत्र आप देख सकते हैं वे आपकी lookup count नहीं हैं — हल की गई संख्या वह है जो रिसीवर compute करते हैं, और यह 30-second की जाँच है।

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