Defaults.Exposed › रिपोर्ट
मेरा SPF विफल क्यों हो रहा है? UK और EU प्रेषकों के लिए SaaS 10-लुकअप समस्या (2026)
प्रकाशित 2026-07-09
2026-06-29 तक के आंकड़े · कार्यप्रणाली v7। 261 मिलियन ग्रेड किए गए डोमेन में समग्र जनगणना डेटा। देखें हम कैसे ग्रेड करते हैं।
जब UK या EU में SaaS टूल का उपयोग करने वाले व्यवसाय के लिए SPF विफल होता है, तो सबसे संभावित कारण एक एकल RFC नियम है जिसके बारे में आपको कभी सोचना नहीं पड़ा: 10 DNS लुकअप से आगे, SPF “fail” नहीं लौटाता — यह PermError लौटाता है, जिसका अर्थ है कि रिकॉर्ड ऐसे माना जाता है जैसे कि यह मौजूद नहीं है। कम से कम 797,263 डोमेन पहले से ही उस रेखा को पार कर चुके हैं। एक और 2,119,539 ठीक 9–10 लुकअप पर बैठे हैं — एक नए टूल से उसी चट्टान पर।
SaaS टूल जोड़ने पर SPF क्यों टूटता है?
SPF यह सूचीबद्ध करके काम करता है कि कौन से मेल सर्वर आपके डोमेन की ओर से भेजने के लिए अधिकृत हैं। आधुनिक व्यवसाय अपने खुद के मेल सर्वर नहीं चलाते — वे आंतरिक ईमेल के लिए Google Workspace, अभियानों के लिए Mailchimp, बिक्री अनुक्रमों के लिए HubSpot, CRM आउटरीच के लिए Pipedrive उपयोग करते हैं। प्रत्येक प्लेटफ़ॉर्म आपको अपने DNS में पेस्ट करने के लिए एक include: लाइन देता है।
समस्या: हर include: स्वयं एक DNS लुकअप है। और उस include के अंदर प्रत्येक रिकॉर्ड पुनरावर्ती रूप से अधिक लुकअप ट्रिगर कर सकता है। RFC 7208 §4.6.4 दस की कठोर सीमा निर्धारित करता है। दस से आगे, प्राप्तकर्ता मेल सर्वर मूल्यांकन बंद कर देता है और PermError लौटाता है — और PermError एक नरम विफलता नहीं है जो स्पैम में समाप्त होती है। इसका मतलब है कि आपका SPF रिकॉर्ड अनुपस्थित माना जाता है। ईमेल प्रमाणीकरण SPF पर विफल होता है।
आप इसे अपने DNS पैनल में नहीं देखेंगे। काउंटर केवल लाइव मूल्यांकन के दौरान चलता है। आपके दृश्यमान रिकॉर्ड में तीन include: लाइनें हो सकती हैं और फिर भी बारह लुकअप गहरी हो सकती हैं, क्योंकि प्रत्येक विक्रेता का SPF रिकॉर्ड अपने स्वयं के उप-includes में खींचता है।
कितने डोमेन पहले से ही सीमा से अधिक हैं?
कम से कम 797,263. यह उस गिनती के बाद है जब हमने 100 या अधिक बार संदर्भित प्रत्येक SPF include: लक्ष्य को हल किया — 10,842 विशिष्ट लक्ष्य 95.2% सभी include संदर्भों को कवर करते हुए — और प्रत्येक डोमेन की पूरी श्रृंखला का मूल्यांकन किया। सतह गिनती (केवल रिकॉर्ड में दृश्यमान लाइनें गिनकर पाई जाने वाली) लगभग 7,958 पाती है। श्रृंखला-मूल्यांकन आंकड़ा 100 गुना बड़ा है, क्योंकि लगभग सभी नुकसान include लक्ष्यों के अंदर अदृश्य है।
एक यूरोपीय व्यवसाय को सबसे अधिक प्रभावित करने वाली स्थिति:
| परिदृश्य | क्या होता है |
|---|---|
| Google Workspace + Mailchimp + HubSpot + एक अन्य | संभवतः 10 लुकअप पर या उससे अधिक |
| IONOS होस्टिंग + कोई भी तीन SaaS टूल | उच्च जोखिम: IONOS का अपना SPF लक्ष्य कई हॉप जोड़ता है |
| OVH होस्टिंग + दो ट्रांज़ैक्शनल टूल + एक CRM | जोखिम मूल्यांकन समय पर OVH SPF गहराई पर निर्भर करता है |
| केवल Microsoft 365 | कम जोखिम: Microsoft का SPF कॉम्पैक्ट और अच्छी तरह से बनाए रखा है |
यूरोपीय होस्टिंग प्रदाता और कमजोर SPF डिफ़ॉल्ट
आप जिस होस्टिंग प्रदाता से शुरू हुए वह मायने रखता है — क्योंकि कुछ SPF डिफ़ॉल्ट सेट करते हैं जो पहले से ही आपके दस लुकअप में से कई उपभोग करते हैं इससे पहले कि आप एकल SaaS टूल जोड़ें।
हमारी जनगणना में यूरोपीय डोमेन द्वारा उपयोग किए जाने वाले सबसे बड़े होस्टिंग प्रदाताओं में:
| प्रदाता | इसका उपयोग करने वाले डोमेन | SPF सख्त (-all) | DMARC लागू करना |
|---|---|---|---|
| IONOS (EU) | 4,346,526 | 0.3% | 1.0% |
| OVH | 2,132,049 | 43.7% | 2.2% |
| Microsoft 365 | 10,205,070 | 85.0% | 21.7% |
| Google Workspace | 12,145,313 | 8.0% | 18.5% |
IONOS उल्लेखनीय है: 1.0% IONOS-होस्टेड डोमेन में DMARC लागू है, जिसका अर्थ है कि भारी बहुमत में बिल्कुल कोई सार्थक प्रेषक प्रमाणीकरण नहीं है। OVH डोमेन SPF सख्त सेटिंग (43.7%) पर बेहतर करते हैं लेकिन फिर भी DMARC प्रवर्तन पर 2.2% पर गिरते हैं — DMARC के बिना केवल SPF From: हेडर को नहीं बल्कि केवल एनवलप को सुरक्षित करता है जिसे प्राप्तकर्ता देखता है।
Microsoft 365 एक अच्छे तरीके से आउटलायर है: 85.0% Microsoft-होस्टेड डोमेन सख्त SPF का उपयोग करते हैं, मुख्यतः क्योंकि Microsoft का मेल-फ्लो विज़ार्ड डिफ़ॉल्ट रूप से -all सेट करता है। Google Workspace डिफ़ॉल्ट रूप से ~all (सॉफ़्टफेल) सेट करता है, जिससे 92% इसके डोमेन सख्त सुरक्षा के बिना रहते हैं।
60 सेकंड से कम में अपनी SPF विफलता का निदान कैसे करें
सबसे तेज़ जाँच एक मुफ्त टूल है जो पूरी लुकअप श्रृंखला का मूल्यांकन करता है — न कि केवल दृश्यमान रिकॉर्ड। कमांड लाइन पर nslookup -type=TXT yourdomain.com चलाएं और आप जो भी include: देखते हैं उन्हें गिनें। फिर प्रत्येक रिकॉर्ड को देखें और उनकी गिनें। यदि includes खत्म होने से पहले आपकी उंगलियाँ खत्म हो जाती हैं, तो आप खतरे के क्षेत्र में हैं।
एक अधिक विश्वसनीय दृष्टिकोण: अपना डोमेन यहाँ जाँचें — स्कैनर पूरी हल की गई श्रृंखला का मूल्यांकन करता है, PermError को फ्लैग करता है, और दिखाता है कि कौन से तंत्र आपके लुकअप बजट का उपभोग कर रहे हैं।
तीन नैदानिक परिणाम:
- PermError — आप पहले से ही दस से ऊपर हैं। आप जो भी ईमेल भेजते हैं वह प्राप्तकर्ता पर SPF जाँच में विफल होता है।
- 9–10 लुकअप पर — आप चट्टान पर हैं। अगला SaaS एकीकरण आपको आगे धकेल देता है।
- हार्डफेल (-all) के बजाय सॉफ़्टफेल (~all) — आप सीमा से कम हैं लेकिन रिकॉर्ड वास्तविक सुरक्षा प्रदान करने के लिए बहुत अनुमोदक ढंग से सेट है। पूरी तस्वीर के लिए
-allबनाम~allपर SPF गलत कॉन्फ़िगरेशन रिपोर्ट देखें।
एकाधिक SaaS टूल उपयोग करने पर SPF कैसे ठीक करें
तीन दृष्टिकोण हैं, स्थायित्व के क्रम में:
1. ऑडिट और छँटाई। अपने वर्तमान रिकॉर्ड में प्रत्येक include: सूचीबद्ध करके शुरू करें। किसी भी प्लेटफ़ॉर्म को हटाएं जिसका आप अब उपयोग नहीं करते — पुराने ESP, पिछले अनुबंधों से CRM टूल, प्लेटफ़ॉर्म जिन्हें आपने परीक्षण किया लेकिन छोड़ दिया। यह मुफ्त है और अक्सर कई लुकअप पुनः प्राप्त करता है। प्रत्येक हटाया गया include: 1–3 उप-लुकअप को समाप्त कर सकता है।
2. अपना SPF रिकॉर्ड फ्लैट करें। SPF फ्लैटनिंग सभी include: लक्ष्यों को उनकी अंतर्निहित IP श्रेणियों में हल करती है और उन्हें ip4: और ip6: तंत्र के रूप में सीधे आपके रिकॉर्ड में लिखती है। IP तंत्र लुकअप ट्रिगर नहीं करते, इसलिए एक फ्लैट रिकॉर्ड दर्जनों भेजने के स्रोतों को सूचीबद्ध कर सकता है और फिर भी शून्य लुकअप पर बैठता है। नकारात्मक पक्ष: आपको हर बार विक्रेता अपने भेजने IP अपडेट करता है तो फिर से फ्लैट करना होगा, जो बिना सूचना के होता है। अधिकांश व्यवसाय एक भुगतान किए SPF फ्लैटनिंग सेवा (PowerDMARC, EasyDMARC, Dmarcian, और अन्य यह प्रदान करते हैं) का उपयोग करते हैं या एक निगरानी कार्यप्रवाह बनाते हैं।
3. SPF मैक्रो का उपयोग करें। RFC 7208 मैक्रो आपको ऐसे रिकॉर्ड बनाने देते हैं जो includes की श्रृंखला के बजाय प्रति जाँच एकल DNS लुकअप करते हैं और गतिशील रूप से उत्तर देते हैं। मैक्रो DNS होस्टिंग समर्थन और कुछ कार्यान्वयन प्रयास की आवश्यकता है, लेकिन वे कई SaaS प्रेषकों वाले संगठनों के लिए वास्तुकला रूप से स्वच्छ समाधान हैं।
SPF ठीक करने के बाद, इसे DMARC प्रवर्तन के साथ जोड़ें — DMARC के बिना SPF केवल एनवलप प्रेषक को प्रमाणित करता है, न कि From: हेडर पते को जो प्राप्तकर्ता देखते हैं।
अक्सर पूछे जाने वाले प्रश्न
मेरा SPF रिकॉर्ड मेरे DNS टूल में पास क्यों होता है लेकिन ईमेल हेडर में अभी भी विफल होता है?
अधिकांश DNS लुकअप टूल केवल आपके अपने रिकॉर्ड में दृश्यमान तंत्र गिनते हैं, वे उप-लुकअप नहीं जो वे तंत्र ट्रिगर करते हैं। आपके पास दो include: लाइनें हो सकती हैं और फिर भी सीमा से अधिक हो सकते हैं यदि प्रत्येक विक्रेता के रिकॉर्ड में कई और हैं। केवल एक श्रृंखला-मूल्यांकन टूल (या एक प्राप्तकर्ता मेल सर्वर) पूरी गहराई गिनता है। अपना डोमेन जाँचें वास्तविक श्रृंखला गिनती देखने के लिए।
क्या SPF विफल होने का मतलब है कि मेरे ईमेल स्पैम में जाते हैं?
PermError (बहुत अधिक लुकअप) का मतलब है कि प्रमाणीकरण का SPF पैर एक गैर-परिणाम लौटाता है — प्रभावी रूप से अनुपस्थित। DMARC SPF और DKIM दोनों का मूल्यांकन करता है; यदि DKIM पास होता है, तो SPF PermError के बावजूद DMARC पास हो सकता है। यदि कोई भी पास नहीं होता, DMARC विफल होता है, और परिणाम आपकी DMARC नीति पर निर्भर करता है। p=none पर, ईमेल फिर भी डिलीवर होता है लेकिन विफलता लॉग की जाती है। p=quarantine या p=reject पर, ईमेल फ़िल्टर या बाउंस हो जाता है। SPF ठीक करें ताकि आप केवल DKIM पर निर्भर न हों।
एक सामान्य SaaS स्टैक कितने लुकअप उपयोग करता है? हमारी जनगणना में p99 SPF रिकॉर्ड पहले से ही 9 लुकअप पर बैठता है — कुछ भी जोड़ने से पहले सीमा पर। एक Google Workspace रिकॉर्ड 3–4 लुकअप जोड़ता है; Mailchimp 1–2 जोड़ता है; HubSpot 1–3 जोड़ता है उनके वर्तमान कॉन्फ़िगरेशन के आधार पर। आपके होस्टिंग प्रदाता के डिफ़ॉल्ट के साथ तीन मुख्यधारा टूल अक्सर दस से अधिक होने के लिए पर्याप्त होते हैं।
क्या SPF फ्लैटनिंग सुरक्षित है?
हाँ, बशर्ते आप इसे वर्तमान रखें। फ्लैटनिंग include: श्रृंखलाओं को स्थिर IP श्रेणियों में परिवर्तित करती है — यदि कोई विक्रेता अपने भेजने IP घुमाता है और आप फिर से फ्लैट नहीं करते, तो आप उनकी मेल अस्वीकार करना शुरू कर देंगे। अधिकांश संगठन एक प्रबंधित फ्लैटनिंग सेवा का उपयोग करते हैं जो IP परिवर्तनों की निगरानी करती है बजाय इसे मैन्युअल रूप से बनाए रखने के।
मेरा SPF वर्षों से ऐसा ही है — यह अचानक क्यों विफल हो रहा है? क्योंकि आपके विक्रेताओं ने अपने SPF रिकॉर्ड अपडेट किए, आपने नहीं। हर बार जब कोई SaaS प्लेटफ़ॉर्म एक नई IP श्रेणी जोड़ता है या एक और include नेस्ट करता है, तो आपकी श्रृंखला लागत आपके अंत पर बिना किसी बदलाव के बढ़ जाती है। 10-लुकअप सीमा संदेश प्राप्ति पर लाइव मूल्यांकन की जाती है, इसलिए मंगलवार सुबह विक्रेता का बदलाव मंगलवार दोपहर तक आपके SPF को तोड़ सकता है।
क्या SPF ठीक करने से ईमेल वितरण में सुधार होता है? यह प्रमाणीकरण विफलता के एक स्रोत को हटाता है, जो सुसंगत वितरण के लिए एक पूर्व शर्त है — विशेष रूप से चूंकि Google और Yahoo अब बल्क प्रेषकों के लिए DMARC संरेखण को लागू करते हैं। SPF अकेला पूरी तस्वीर नहीं है: पूर्ण ईमेल प्रमाणीकरण के लिए इसे DKIM और DMARC के साथ जोड़ें।
अपना SPF मुफ्त में जाँचें
यदि आप निश्चित नहीं हैं कि आपका SPF रिकॉर्ड लुकअप सीमा से अधिक है या नहीं — या अपने डोमेन की रक्षा करने के लिए बहुत कमजोर ढंग से सेट है — एक मुफ्त जाँच चलाएं। यह पूरी हल की गई श्रृंखला का मूल्यांकन करती है और दिखाती है कि बजट कहाँ खर्च हो रहा है।
अपना डोमेन जाँचें → · SPF ठीक करें → · SPF PermError रिपोर्ट → · SPF गलत कॉन्फ़िगरेशन रिपोर्ट → · SPF अपनाने परिपक्वता मॉडल → · DMARC ठीक करें → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।