SPF रिकॉर्ड जनरेटर: अपना SPF TXT रिकॉर्ड बनाएँ

इसका इस्तेमाल कैसे करें

अगर डोमेन अपना मेल खुद भेजता है, तो डोमेन के अपने पते और डोमेन के मेल सर्वर पर निशान लगाएँ।
अपने सर्वरों के नेटवर्क IPv4 नेटवर्क और IPv6 नेटवर्क में लिखें, और किसी प्रदाता का डोमेन ये डोमेन शामिल करें में लिखें।
बाकी सभी भेजने वाले के नीचे दूसरे भेजने वालों का परिणाम चुनें। -all सख्त विकल्प है।
SPF रिकॉर्ड (TXT) कॉपी करें और उसे डोमेन पर TXT रिकॉर्ड के रूप में प्रकाशित करें। जाँचें कि DNS लुकअप (सीमा 10) 10 या उससे कम रहे।

रिसीवर SPF रिकॉर्ड कैसे पढ़ता है

SPF रिकॉर्ड उस डोमेन पर एक TXT रिकॉर्ड है जिसका वह वर्णन करता है। वह v=spf1 से शुरू होता है और फिर पद सूचीबद्ध करता है: a, mx, ip4, ip6 और include, हर एक के वैकल्पिक qualifier के साथ। रिसीवर उन्हें बाएँ से दाएँ जाँचता है, और पहला मेल खाने वाला पद परिणाम देता है: + पास, - विफल, ~ soft fail या ? neutral। + डिफ़ॉल्ट है (RFC 7208, खंड 4.6.2)।

all हर दूसरे भेजने वाले से मेल खाता है, और उसके बाद के पद अनदेखे रहते हैं (RFC 7208, खंड 5.1)। यह पेज all को हमेशा अंत में लिखता है।
जब कोई पद मेल न खाए और कोई redirect न हो, तो परिणाम neutral होता है, जैसे रिकॉर्ड के अंत में ?all हो (खंड 4.7)।

DNS लुकअप की 10 की सीमा

a, mx, ptr, exists, include और redirect पद हर एक एक DNS लुकअप लेते हैं, और उसी तरह वे लुकअप भी जो कोई शामिल किया गया रिकॉर्ड करता है। एक रिसीवर जो एक जाँच के लिए 10 से ज्यादा लुकअप चाहता है, त्रुटि लौटाता है (RFC 7208, खंड 4.6.4)। ip4 और ip6 पद कोई लुकअप नहीं लेते, इसलिए जो प्रदाता अपनी नेटवर्क रेंज प्रकाशित करता है, उसे include की जगह ip4 और ip6 पदों में लिखा जा सकता है।

लंबाई और TXT स्ट्रिंग

TXT रिकॉर्ड की एक character-string में अधिकतम 255 वर्ण होते हैं। लंबा रिकॉर्ड कई स्ट्रिंग में लिखा जाता है, और रिसीवर उन्हें बिना स्पेस के जोड़ते हैं (RFC 7208, खंड 3.3)। प्रकाशित रिकॉर्ड का DNS जवाब 512 ऑक्टेट से छोटा रहना चाहिए (खंड 3.4)।

उदाहरण: एक डोमेन जो अपने सर्वरों और एक प्रदाता से भेजता है

रिकॉर्ड v=spf1 a mx ip4:192.0.2.0/24 ip6:2001:db8:1::/48 include:_spf.example.net -all डोमेन के अपने एड्रेस रिकॉर्ड और मेल सर्वरों को भेजने देता है, दोनों नेटवर्कों को भेजने देता है, और उन भेजने वालों को भी जिन्हें _spf.example.net का रिकॉर्ड अनुमति देता है। बाकी हर भेजने वाला विफल होता है (-all)।

a, mx और include पद हर एक एक लुकअप लेते हैं, और दो नेटवर्क पद कोई नहीं लेते, इसलिए रिकॉर्ड 3 लुकअप करता है। _spf.example.net के रिकॉर्ड के अपने लुकअप जुड़ते हैं, जिन्हें यह पेज नहीं गिनता।

माप	मान
रिकॉर्ड	v=spf1 a mx ip4:192.0.2.0/24 ip6:2001:db8:1::/48 include:_spf.example.net -all
DNS लुकअप	3 DNS लुकअप, 10 की सीमा में
वर्ण	78

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

-all या ~all इस्तेमाल करूँ?

-all रिसीवरों से कहता है कि वे हर उस भेजने वाले को विफल करें जो आपके रिकॉर्ड में नहीं है, इसलिए यह सख्त विकल्प है। ~all बाकी भेजने वालों को soft fail देता है, जिसे कई डोमेन तब इस्तेमाल करते हैं जब वे जाँच रहे हों कि सूची पूरी है। अगर आप निश्चित नहीं हैं कि सूची पूरी है, तो ~all से शुरू करें।

10 से ज्यादा लुकअप वाला रिकॉर्ड विफल क्यों होता है?

रिसीवर एक जाँच में अधिकतम 10 DNS लुकअप करता है, और जो जाँच इससे ज्यादा माँगे वह त्रुटि लौटाती है (RFC 7208, खंड 4.6.4)। जो include अब इस्तेमाल नहीं होते उन्हें हटाएँ, या अपने प्रदाता की प्रकाशित रेंज को ip4 और ip6 पदों में लिखें, जिन पर कोई लुकअप नहीं लगता।

क्या SPF रिकॉर्ड का एक ही स्ट्रिंग में होना जरूरी है?

नहीं। TXT स्ट्रिंग में अधिकतम 255 वर्ण होते हैं, और लंबा रिकॉर्ड कई उद्धरण वाली स्ट्रिंग में प्रकाशित होता है, जिन्हें रिसीवर बिना स्पेस के जोड़ता है (RFC 7208, खंड 3.3)। इस पेज का बाँटा गया परिणाम उन स्ट्रिंग को दिखाता है, जब रिकॉर्ड एक में नहीं समाता।

include क्या करता है?

include:domain रिसीवर से कहता है कि आपके रिकॉर्ड के हिस्से के रूप में उस डोमेन का SPF रिकॉर्ड भी जाँचे (RFC 7208, खंड 5.2)। उस रिकॉर्ड के लुकअप आपकी 10 की सीमा में गिने जाते हैं, इसलिए किसी प्रदाता का include यहाँ दिखने वाले एक लुकअप से ज्यादा लग सकता है।

क्या सिर्फ SPF रिकॉर्ड नकली मेल रोकने के लिए काफी है?

नहीं। SPF उस सर्वर की जाँच करता है जिसने संदेश भेजा, और DMARC फिर जाँचता है कि From लाइन का डोमेन मेल खाता है (RFC 7489, खंड 3.1)। DKIM सिग्नेचर और DMARC नीति भी प्रकाशित करें।

क्या यह जनरेटर मेरा डोमेन किसी को भेजता है?

नहीं। रिकॉर्ड आपके ब्राउज़र में उसी से बनता है जो आप लिखते हैं, और नेटवर्क पर कुछ भी न खोजा जाता है न सहेजा जाता है।

स्रोत

आँकड़े और टेक्स्ट आखिरी बार मंगलवार, 10 नवंबर 2026 को जाँचे गए।

परिणाम

रिकॉर्ड कैसे पढ़ा जाता है