किसी डोमेन का SPF रिकॉर्ड देखने, DNS लुकअप गिनने और SPF फ़ेल करने वाली गलतियाँ ढूँढने के लिए डोमेन दर्ज करें।
यह रिकॉर्ड को वैसे जाँचता है जैसे वह अभी DNS में प्रकाशित है। यह नहीं परखता कि कोई खास मैसेज SPF में पास हुआ या नहीं। वह देखने के लिए मैसेज के हेडर खोलें और Authentication-Results लाइन पढ़ें। DNS कैशिंग के कारण हाल के बदलाव दिखने में समय लग सकता है।
SPF (Sender Policy Framework) किसी डोमेन को DNS में उन सर्वरों की सूची प्रकाशित करने देता है जिन्हें उसकी ओर से ईमेल भेजने की अनुमति है। मैसेज आने पर रिसीविंग सर्वर एनवेलप सेंडर (Return-Path, जिसे MAIL FROM भी कहते हैं) का डोमेन देखता है और उस डोमेन का SPF रिकॉर्ड पढ़ता है। अगर कनेक्ट करने वाला IP पता सूची में है, तो SPF पास होता है। नहीं है, तो रिकॉर्ड बताता है कि रिसीवर को उसके बारे में क्या करना चाहिए।
SPF उस From पते को नहीं देखता जो आपके प्राप्तकर्ताओं को दिखता है। इसीलिए कोई मैसेज SPF पास करके भी DMARC में फ़ेल हो सकता है: दोनों डोमेन का मेल खाना ज़रूरी है, और अकेला SPF ऐसा नहीं कराता।
SPF रिकॉर्ड टेक्स्ट की एक लाइन होती है जो v=spf1 से शुरू होती है और बाएँ से दाएँ पढ़े जाने वाले टर्म से बनती है। भेजने वाले IP से मेल खाने वाला पहला टर्म नतीजा तय करता है।
| टर्म | इसका मतलब |
|---|---|
| ip4:203.0.113.0/24, ip6:... | एक तय पता या रेंज अनुमति देता है। कोई DNS लुकअप नहीं लगता। |
| include:example.net | example.net का अपना SPF रिकॉर्ड जो अनुमति देता है, वह भी अनुमत करता है। एक लुकअप लगता है, साथ में उसके अंदर के लुकअप भी। |
| a, mx | डोमेन के A या MX रिकॉर्ड के पते अनुमत करता है। हर एक में लुकअप लगते हैं। |
| redirect=example.net | इस रिकॉर्ड की जगह example.net का रिकॉर्ड लगा देता है। तब इस्तेमाल होता है जब सब कुछ किसी दूसरे डोमेन को तय करना हो। |
| exists:, ptr | कम ही ज़रूरी। ptr मानक द्वारा अप्रचलित है और इस्तेमाल नहीं करना चाहिए। |
| -all, ~all, ?all, +all | अंत का कैच-ऑल: अस्वीकार, सॉफ़्ट फ़ेल, न्यूट्रल, या सबको अनुमति। +all किसी को भी आपके नाम से भेजने देता है। |
SPF मानक (RFC 7208) रिसीवर को रिकॉर्ड का मूल्यांकन करने में अधिकतम दस DNS लुकअप खर्च करने देता है। include, a, mx, ptr, exists और redirect टर्म हर एक गिने जाते हैं, और include किए गए रिकॉर्ड के अंदर का हर लुकअप भी। दस से आगे जाने पर नतीजा स्थायी त्रुटि होता है, जिसे रिसीवर विफलता मानते हैं।
कई ईमेल सेवाओं को जोड़ना आम कारण है: मार्केटिंग प्लेटफ़ॉर्म, हेल्पडेस्क, CRM और मेल प्रोवाइडर मिलकर ज़्यादातर बजट खर्च कर सकते हैं। चेकर हर include को वैसे ही फ़ॉलो करता है जैसे रिसीवर करता है और सीमा के मुकाबले गिनती दिखाता है, ताकि आप देख सकें कि कौन-सी शाखा महँगी है।
मानक void लुकअप (ऐसे नाम जो कुछ नहीं लौटाते) को भी दो तक सीमित करता है। ऐसा include जो SPF रिकॉर्ड के बिना डोमेन की ओर इशारा करता है, इसी कारण समस्या गिना जाता है।
जो समाधान काम करते हैं: जो सेवाएँ अब इस्तेमाल नहीं करते उन्हें हटाएँ, जहाँ प्रोवाइडर स्थिर रेंज प्रकाशित करता है वहाँ a, mx और include टर्म की जगह ip4 और ip6 रेंज लगाएँ, और अलग-अलग तरह का मेल अलग सबडोमेन से भेजें ताकि हर एक का अपना रिकॉर्ड हो।
सबसे अधिक दिखने वाली समस्याएँ ये हैं, और चेकर हर एक के लिए सरल भाषा में समाधान बताता है।
साफ़ रिकॉर्ड का मतलब है कि पॉलिसी सही ढंग से बनी है। इससे यह साबित नहीं होता कि कोई खास संदेश पास हुआ। असली संदेश जाँचने के लिए उसके हेडर खोलकर Authentication-Results लाइन पढ़ें, या उन्हें हमारे ईमेल हेडर एनालाइज़र में पेस्ट करें।
मेल फ़ॉरवर्ड होने पर भी SPF टूट जाता है, क्योंकि फ़ॉरवर्ड करने वाले सर्वर का IP आपके रिकॉर्ड में नहीं होता। इसी वजह से DMARC SPF या DKIM में से किसी एक को स्वीकार करता है, और इसीलिए आपको अपने मेल पर DKIM से भी हस्ताक्षर करने चाहिए।
~all (सॉफ़्ट फ़ेल) और -all (हार्ड फ़ेल) दोनों रिसीवर को बताते हैं कि भेजने वाला अधिकृत नहीं था। व्यवहार में ज़्यादातर रिसीवर SPF को कई संकेतों में से एक मानते हैं और अपना निर्णय खुद लेते हैं, और फ़ेल होने वाले मेल का क्या होगा, यह DMARC तय करता है। कई संगठन अपने सभी सेंडर खोजने तक ~all प्रकाशित रखते हैं और सूची पूरी होने पर -all पर चले जाते हैं। दोनों स्वीकार्य हैं; +all और all का न होना स्वीकार्य नहीं।
डोमेन के रूट पर मौजूद TXT रिकॉर्ड पढ़ता है और v=spf1 से शुरू होने वाला रिकॉर्ड चुनता है। रिकॉर्ड न होने पर, या एक से अधिक होने पर चेतावनी देता है।
रिसीविंग सर्वर की तरह हर include और redirect का अनुसरण करता है, और लुकअप को दस की सीमा के विरुद्ध जोड़ता है।
अज्ञात मैकेनिज़्म, अमान्य IP पते और रेंज, कहीं न पहुँचने वाले include, लूप, और कभी मूल्यांकित न होने वाले टर्म खोजता है।
+all और ?all, अप्रचलित ptr मैकेनिज़्म, all का न होना, और DNS के लिए समस्या बनने जितने लंबे रिकॉर्ड पर चेतावनी देता है।
SPF रिकॉर्ड आपके डोमेन पर एक DNS TXT रिकॉर्ड है, जिसमें उन सर्वरों की सूची होती है जिन्हें उसकी ओर से ईमेल भेजने की अनुमति है। संदेश आने पर रिसीविंग सर्वर भेजने वाले IP पते की तुलना इसी सूची से करते हैं।
SPF मूल्यांकन में अधिकतम दस DNS लुकअप हो सकते हैं। हर include, a, mx, ptr, exists और redirect गिना जाता है, और आपके include किए रिकॉर्ड के भीतर के लुकअप भी। अगर किसी रिकॉर्ड को दस से अधिक चाहिए, तो रिसीवर स्थायी त्रुटि लौटाते हैं और उस डोमेन के हर संदेश के लिए SPF फ़ेल हो जाता है।
हर include किसी दूसरे रिकॉर्ड की ओर इशारा करता है, और उस रिकॉर्ड में अपने include हो सकते हैं। चेकर उन सबका अनुसरण करके जोड़ता है, ठीक वैसे ही जैसे रिसीवर गिनता है। चार include वाला रिकॉर्ड आसानी से आठ या अधिक लुकअप इस्तेमाल कर सकता है।
इसका मतलब है कि रिकॉर्ड का मूल्यांकन नहीं हो सका। आम कारण हैं: एक डोमेन पर दो SPF रिकॉर्ड, दस से अधिक लुकअप, सिंटैक्स की गलती, या ऐसे डोमेन की ओर जाता include जिसका SPF रिकॉर्ड नहीं है।
नहीं। SPF एक ही संकेत है। रिसीवर DKIM, DMARC अलाइनमेंट, सेंडर प्रतिष्ठा, शिकायत दर और कंटेंट भी देखते हैं। अच्छी डिलीवरेबिलिटी के लिए SPF पास होना ज़रूरी है, पर पर्याप्त नहीं।
लुकअप हमारे सर्वरों पर चलते हैं, और नतीजे लगभग पाँच मिनट रखे जाते हैं ताकि दोहराई गई जाँचों में DNS क्वेरी दोबारा न हों। जाँचें किसी अकाउंट से जुड़ी नहीं होतीं, और जिन DNS सर्वरों से क्वेरी होती है उनकी सुरक्षा के लिए टूल की रेट लिमिट है।
चरण-दर-चरण गाइड देखें, या जेनरेटर से ऐसा रिकॉर्ड बनाएँ जो लुकअप सीमा के भीतर रहे।
खाता बनाएँ, अपना डोमेन जोड़ें और पहला ईमेल भेजें।