कोई भी डोमेन दर्ज करें और उसका SPF रिकॉर्ड प्राप्त कर सत्यापित करें। पूरा रिकॉर्ड मान, प्रत्येक मैकेनिज़्म की व्याख्या और कॉन्फ़िगरेशन सही है या नहीं, देखें।
SPF (Sender Policy Framework) रिकॉर्ड एक DNS TXT रिकॉर्ड है जो किसी डोमेन की ओर से ईमेल भेजने के लिए विशिष्ट मेल सर्वरों को अधिकृत करता है। यह DKIM और DMARC के साथ तीन मुख्य ईमेल प्रमाणीकरण प्रोटोकॉल में से एक है। जब संदेश आता है, प्राप्तकर्ता मेल सर्वर भेजने वाले डोमेन का SPF रिकॉर्ड क्वेरी करता है ताकि पुष्टि हो कि डिलीवर करने वाला IP पता अधिकृत है।
SPF ईमेल डिलिवरेबिलिटी के लिए आधारभूत है। वैध SPF रिकॉर्ड के बिना, आपके डोमेन की ईमेल के स्पैम चिह्नित होने या पूरी तरह अस्वीकृत होने की संभावना अधिक होती है। अधिकांश प्रमुख इनबॉक्स प्रदाता — Gmail, Outlook, Yahoo — SPF परिणामों को प्राथमिक विश्वास संकेत मानते हैं। Google और Yahoo अब अपनी बल्क प्रेषक आवश्यकताओं के भाग के रूप में SPF अनिवार्य करते हैं।
SPF रिकॉर्ड अधिकृत प्रेषकों का वर्णन करने के लिए मैकेनिज़्म का एक सेट उपयोग करता है। आम मैकेनिज़्म में ip4 और ip6 (विशिष्ट IP पते या रेंज), mx (डोमेन के मेल सर्वर) और include (किसी अन्य डोमेन के SPF रिकॉर्ड को सौंपना) शामिल हैं। रिकॉर्ड all मैकेनिज़्म पर समाप्त होता है, जो स्पष्ट रूप से सूचीबद्ध न किए गए प्रेषकों के साथ क्या करना है यह तय करता है: ~all (softfail), -all (hardfail), या ?all (neutral)।
किसी विशिष्ट IPv4 पते या CIDR रेंज को अधिकृत करता है। उदाहरण: ip4:203.0.113.1 या ip4:203.0.113.0/24।
किसी विशिष्ट IPv6 पते या रेंज को अधिकृत करता है। उदाहरण: ip6:2001:db8::1।
डोमेन के MX रिकॉर्ड में सूचीबद्ध मेल सर्वरों को अधिकृत करता है। तब उपयोगी जब आपके आउटगोइंग और इनकमिंग मेल सर्वर एक ही हों।
किसी अन्य डोमेन के SPF रिकॉर्ड को शामिल कर उसका मूल्यांकन करता है। Google Workspace या SendGrid जैसे तृतीय-पक्ष प्रेषकों को अधिकृत करने के लिए उपयोग होता है।
डोमेन के A या AAAA रिकॉर्ड से IP पतों को अधिकृत करता है। उन वेब सर्वरों के लिए उपयोगी जो मेल भी भेजते हैं।
एक Catch-All जो किसी अन्य मैकेनिज़्म से मेल न खाने वाले प्रेषकों पर लागू होता है। उपसर्ग ~(softfail), -(hardfail), या ?(neutral) के साथ।
लाइव DNS साक्ष्य
SPF चेकर सार्वजनिक TXT नीति प्राप्त करता है और उन अधिकरण नियमों को दिखाता है जिनका प्राप्तकर्ता मूल्यांकन कर सकते हैं। यह एक कॉन्फ़िगरेशन निदान है, इस बात की गारंटी नहीं कि हर वास्तविक संदेश पास होगा।
बिना SPF नीति वाले डोमेन से कोई SPF अधिकरण साक्ष्य नहीं मिलता। कई v=spf1 TXT रिकॉर्ड वाले डोमेन उन्हें स्वतः मिलाने के बजाय स्थायी SPF त्रुटि पैदा करते हैं।
वापस आए रिकॉर्ड को ठीक वैसे पढ़ें जैसे DNS उसे प्रकाशित करता है। पुराने प्रदाता के include, आकस्मिक रिक्त स्थान और गलत सबडोमेन पर रखी नीति — ये सभी परिणाम बदल सकते हैं।
ip4 और ip6 नेटवर्क की सीधे पहचान करते हैं। include, a, mx, exists और redirect अतिरिक्त DNS कार्य ट्रिगर कर सकते हैं और किसी अन्य प्रदाता द्वारा नियंत्रित रिकॉर्ड पर निर्भर हो सकते हैं।
कोई नीति सिंटैक्स की दृष्टि से वैध होते हुए भी गलत सिस्टम अधिकृत कर सकती है। सफल पार्स को व्यावसायिक कॉन्फ़िगरेशन की मंज़ूरी न समझें; प्रत्येक मैकेनिज़्म की वर्तमान प्रेषक सूची से तुलना करें।
नीति पढ़ें
उपयोगी प्रश्न केवल यह नहीं है कि रिकॉर्ड मौजूद है या नहीं। प्रश्न यह है कि रिकॉर्ड का मूल्यांकन हो सकता है या नहीं, और उसकी अधिकरण सीमा आपके वास्तविक मेल प्रवाह से मेल खाती है या नहीं।
SPF MAIL FROM या HELO में प्रयुक्त डोमेन का मूल्यांकन करता है, न कि ज़रूरी तौर पर दृश्य From हेडर का। इसलिए पास करने वाला स्रोत तकनीकी रूप से अधिकृत हो सकता है, जबकि प्राप्तकर्ता को दिखने वाले पते के साथ DMARC संरेखण में विफल हो सकता है।
~all और -all बेमेल स्रोतों के लिए अलग नीति-शक्ति दर्शाते हैं। ?all कोई सकारात्मक दावा नहीं करता। अमान्य सिंटैक्स, डुप्लिकेट नीतियाँ या अत्यधिक DNS मूल्यांकन permerror पैदा कर सकते हैं; इन्हें साधारण fail न समझें, बल्कि ठीक करें।
पूरी include श्रृंखला में DNS ट्रिगर करने वाले मैकेनिज़्म गिनें। शीर्ष-स्तरीय रिकॉर्ड में केवल दो include हो सकते हैं, जबकि वे प्रदाता इतने a, mx, include, exists या redirect ऑपरेशन में फैल जाते हैं कि RFC सीमा पार हो जाती है।
+all हर प्रेषक को अधिकृत करता है। बड़े IP रेंज या अनावश्यक include भी स्पूफिंग को आसान बना सकते हैं। SPF चेकर को अधिकरण सीमित करने में मदद करनी चाहिए, न कि केवल यह पुष्टि करनी कि TXT स्ट्रिंग v=spf1 से शुरू होती है।
निदान वर्कफ़्लो
अनुशासित जाँच प्रकाशित नीति को वास्तविक प्रेषण पहचानों से जोड़ती है।
return-path डोमेन पता करने के लिए कोई वास्तविक भेजा गया संदेश या प्रदाता सेटिंग देखें, फिर उसी डोमेन को क्वेरी करें — यह न मानें कि संगठनात्मक रूट का मूल्यांकन होता है।
प्रत्येक include, IP रेंज, a और mx अधिकरण के स्वामी की पहचान करें। पुराने स्रोतों को तभी हटाएँ जब पुष्टि हो जाए कि वे अब वैध मेल नहीं भेजते।
हर प्रोडक्शन प्लेटफ़ॉर्म से भेजें और प्राप्त हेडर में spf=, smtp.mailfrom और DMARC संरेखण जाँचें। इससे वे पहचान बेमेल पकड़ में आते हैं जिन्हें अकेले DNS लुकअप नहीं देख सकता।
यदि रिकॉर्ड गायब है या संरचनात्मक रूप से गलत है, तो SPF रिकॉर्ड जनरेटर से एक संयुक्त नीति का मसौदा बनाएँ, उसे प्रकाशित करें, और DNS कैश समाप्त होने के बाद इस चेकर को फिर चलाएँ।
परिणाम की सीमाएँ
SPF एक डोमेन-स्तरीय संकेत है। यह अकेले प्राप्तकर्ता, सामग्री या पूर्ण प्रमाणीकरण के प्रश्नों का उत्तर नहीं दे सकता।
DMARC को संरेखित SPF या DKIM पहचान चाहिए। अलग return-path डोमेन SPF पास कर सकता है, जबकि दृश्य From डोमेन असुरक्षित रह सकता है।
उन विशिष्ट DNS रिकॉर्ड और नीतियों के लिए DKIM चेकर और DMARC चेकर का उपयोग करें।
प्राप्तकर्ता प्रमाणीकरण को प्रेषण प्रतिष्ठा, शिकायत दर, सामग्री, सहभागिता और अपने फ़िल्टर के साथ जोड़ते हैं। कई प्रेषकों के लिए SPF pass आवश्यक साक्ष्य है, इनबॉक्स की गारंटी नहीं।
रिकॉर्ड बताता है कि किसी डोमेन के लिए कौन भेज सकता है। गंतव्य पता मेल प्राप्त कर सकता है या नहीं, जाँचने के लिए ईमेल वेरिफ़ायर का उपयोग करें।
प्रोटोकॉल संदर्भ
प्रदाता डैशबोर्ड SPF को सरल बनाते हैं, लेकिन प्राप्तकर्ता प्रकाशित नीति का मूल्यांकन प्रोटोकॉल के अनुसार करते हैं।
IETF का RFC 7208 SPF पहचान, TXT रिकॉर्ड, मैकेनिज़्म, क्वालिफ़ायर, DNS सीमाएँ और परिणाम कोड परिभाषित करता है। डुप्लिकेट रिकॉर्ड और permerror व्यवहार के लिए यही आधिकारिक संदर्भ है।
SPF सुधारने के बाद DKIM जनरेटर से संदेश हस्ताक्षर जोड़ें और DMARC जनरेटर से संरेखित नीति प्रकाशित करें।
साक्ष्य प्रकार के अनुसार अगला टूल चुनें: प्राप्तकर्ता, खोज, DNS और इंफ्रास्ट्रक्चर, या प्रेषक वर्कफ़्लो।
मुफ़्त उपकरण
सेकंडों में अपने डोमेन के लिए मान्य SPF DNS रिकॉर्ड बनाएँ। मेल सर्वर, include निर्देश जोड़ें और नीति चुनें। मुफ्त, साइनअप नहीं।
डोमेन या इंफ्रास्ट्रक्चर साक्ष्य — मेलबॉक्स प्रमाण नहीं।
मुफ़्त उपकरण
किसी भी डोमेन और सेलेक्टर का DKIM रिकॉर्ड जाँचें। पूरा पब्लिक की रिकॉर्ड देखें और पुष्टि करें कि DKIM साइन सही कॉन्फ़िगर है। मुफ्त, बिना साइनअप।
डोमेन या इंफ्रास्ट्रक्चर साक्ष्य — मेलबॉक्स प्रमाण नहीं।
मुफ़्त उपकरण
किसी भी डोमेन का DMARC रिकॉर्ड जाँचें। नीति, अलाइनमेंट सेटिंग, रिपोर्टिंग पते और सही कॉन्फ़िगरेशन देखें। मुफ़्त, साइनअप नहीं।
डोमेन या इंफ्रास्ट्रक्चर साक्ष्य — मेलबॉक्स प्रमाण नहीं।
मुफ़्त उपकरण
किसी भी डोमेन के A, AAAA, MX, TXT, NS या CNAME रिकॉर्ड जाँचें। तुरंत परिणाम के साथ लाइव DNS लुकअप चलाएँ। मुफ़्त, साइनअप की ज़रूरत नहीं।
डोमेन या इंफ्रास्ट्रक्चर साक्ष्य — मेलबॉक्स प्रमाण नहीं।
ईमेल उपकरण
वास्तविक संदेश नमूने पर ईमेल डिलिवरेबिलिटी टेस्ट चलाएँ। SPF, DKIM, DMARC, DNS, ब्लॉकलिस्ट, स्पैम-फ़िल्टर, हेडर और सामग्री साक्ष्य देखें।
प्रेषक या संदेश निदान — पता खोज नहीं।
ईमेल सत्यापन उपकरण
मुफ़्त ईमेल वेरिफ़ायर से जाँचें कि ईमेल पता मान्य है — सिंटैक्स, MX, SMTP मेलबॉक्स, disposable, role और catch-all जाँचें चलाता है।
प्राप्तकर्ता साक्ष्य — प्रेषक या DNS कॉन्फ़िगरेशन नहीं।
बिना SPF रिकॉर्ड वाले डोमेन SPF जाँच में विफल होते हैं। प्राप्तकर्ता सर्वर इसे तटस्थ परिणाम मानते हैं, लेकिन अन्य संकेतों के साथ यह स्पैम की संभावना बढ़ाता है। Google और Yahoo अब सभी बल्क प्रेषकों के लिए SPF रिकॉर्ड अनिवार्य करते हैं। जो भी डोमेन ईमेल भेजता है, उसे SPF रिकॉर्ड प्रकाशित करना चाहिए।
एक ही डोमेन पर v=spf1 से शुरू होने वाले दो या अधिक TXT रिकॉर्ड SPF स्थायी त्रुटि (permerror) पैदा करते हैं। SPF मूल्यांकन पूरी तरह विफल हो जाता है, और उस डोमेन की सभी ईमेल SPF में फेल हो जाती हैं। आपको सभी नियमों को एक ही SPF रिकॉर्ड में मिलाना होगा।
SPF fail का मतलब है कि डिलीवर करने वाला IP पता डोमेन के SPF रिकॉर्ड में अधिकृत नहीं है। परिणाम all मैकेनिज़्म पर निर्भर करता है: ~all softfail देता है (संदिग्ध, लेकिन आमतौर पर फिर भी डिलीवर होता है), जबकि -all hardfail देता है (आमतौर पर अस्वीकृत या स्पैम में भेजा जाता है)। तटस्थ ?all परिणाम किसी भी दिशा में प्रभाव नहीं डालता।
permerror (स्थायी त्रुटि) तब होता है जब कॉन्फ़िगरेशन समस्या के कारण SPF का मूल्यांकन नहीं हो पाता — सबसे आम कारण यह है कि डोमेन पर एक से अधिक SPF रिकॉर्ड हैं, या रिकॉर्ड में बहुत ज़्यादा DNS-लुकअप मैकेनिज़्म हैं (10 से अधिक)। permerror तुरंत ठीक करें, क्योंकि इनसे आपके डोमेन की सभी ईमेल SPF में विफल हो जाती हैं।
SPF मूल्यांकन के दौरान अधिकतम 10 DNS लुकअप की अनुमति देता है। प्रत्येक include, a, mx, ptr और exists मैकेनिज़्म एक लुकअप गिना जाता है, और उनके अंदर नेस्टेड include भी गिने जाते हैं। कुल 10 से अधिक लुकअप होने पर permerror होता है।
यदि आपका SPF रिकॉर्ड 10-लुकअप सीमा के करीब है, तो SPF फ़्लैटनिंग पर विचार करें — सभी include को उनके वास्तविक IP पतों में हल करें और include मैकेनिज़्म को सीधे ip4/ip6 प्रविष्टियों से बदलें। इससे उन प्रविष्टियों का लुकअप काउंट शून्य हो जाता है, लेकिन जब भी आपका प्रदाता अपने IP रेंज बदले, रिकॉर्ड अपडेट करना होगा।
SPF पहला कदम है। अपने डोमेन की पूरी सुरक्षा के लिए इसे DKIM और DMARC के साथ जोड़ें। फिर BillionVerify ईमेल सत्यापन से अपनी सूची साफ़ रखें।
600 मुफ़्त क्रेडिट/माह + 20/दिन लॉगिन बोनस · 99.9% SMTP सटीकता · तुरंत API एक्सेस · क्रेडिट कार्ड की आवश्यकता नहीं
