आपका SPF रिकॉर्ड बार-बार फेल क्यों होता है (और कैसे ठीक करें)

SPF असल में क्या जाँचता है

SPF — Sender Policy Framework — आपके डोमेन पर एक TXT रिकॉर्ड है जो बताता है कि आपकी ओर से मेल भेजने की अनुमति किन सर्वरों को है। प्राप्त करने वाला सर्वर वह रिकॉर्ड देखता है, उसकी तुलना उस IP पते से करता है जो अभी जुड़ा है, और तय करता है कि कनेक्शन अधिकृत है या नहीं।

वह किसकी तुलना करता है, इसकी दो बातें SPF की ज़्यादातर उलझन समझा देती हैं:

• SPF लिफ़ाफ़े के प्रेषक को जाँचता है, उस From: पते को नहीं जो आपका प्राप्तकर्ता देखता है। लिफ़ाफ़े का प्रेषक (SMTP बातचीत का MAIL FROM, जिसे रिटर्न पाथ भी कहते हैं) मेल क्लाइंट में अदृश्य होता है। कोई संदेश SPF पास कर सकता है और साथ ही पूरी तरह अलग, जाली From: पता दिखा सकता है — इसीलिए अकेला SPF स्पूफ़िंग नहीं रोकता।
• SPF जुड़ने वाले IP पते को जाँचता है, और कुछ नहीं। वह संदेश, हेडर या सामग्री नहीं देखता। एक ही सवाल है: इस IP को आपकी ओर से जुड़ने की अनुमति थी या नहीं?

इसलिए SPF का फेल होना लगभग कभी यह नहीं बताता कि आपका रिकॉर्ड गलत लिखा है। आम तौर पर इसका मतलब है कि मेल वहाँ से निकला जो रिकॉर्ड में नहीं है, या रिकॉर्ड को पूरी तरह आँका नहीं जा सका। ये अलग समस्याएँ हैं और इनके हल भी अलग हैं, और यह गाइड आगे उन्हें अलग-अलग देखती है।

अपना SPF रिकॉर्ड कैसे पढ़ें

SPF रिकॉर्ड TXT की एक ही पंक्ति है, और चार हिस्से जान लेने पर वह पढ़ा जा सकता है।

मेकेनिज़्म: किसे अनुमति है

हर पद अनुमत प्रेषक जोड़ता है। ip4: और ip6: पते या रेंज सीधे बताते हैं। a उसे अधिकृत करता है जिस पर आपके डोमेन का A रिकॉर्ड इशारा करता है। mx आपके अपने मेल सर्वरों को अधिकृत करता है। include: व्यवहार में सबसे ज़्यादा मायने रखता है: वह किसी दूसरे डोमेन का पूरा SPF रिकॉर्ड खींच लेता है, और इसी तरह आप Google, Microsoft या बल्क भेजने वाली सेवा को उनके पते जाने बिना अधिकृत करते हैं।

include: प्रत्यायोजन है, नकल नहीं। दूसरा पक्ष अपनी सूची कभी भी बदल सकता है और आपका रिकॉर्ड साथ चलता है — यही मक़सद है, और यही वजह भी कि आपका रिकॉर्ड आपके छुए बिना टूट सकता है।

क्वालिफ़ायर: मिलान होने पर क्या होता है

हर मेकेनिज़्म पर एक उपसर्ग लग सकता है। + का मतलब पास है और वही डिफ़ॉल्ट है, इसलिए अकेला mx का अर्थ +mx है। - कठोर फेल है: ठुकराओ। ~ नरम फेल है: स्वीकार करो, पर निशान लगाओ। ? तटस्थ है: कोई राय नहीं, जो असल में कोई नीति न होने के बराबर है।

आख़िर में आने वाला all

अंतिम पद लगभग हमेशा all मेकेनिज़्म होता है, और वह तय करता है कि जिन प्रेषकों को रिकॉर्ड ने सूचीबद्ध नहीं किया उनका क्या होगा। -all कहता है: बाकी सब ठुकरा दो। ~all कहता है: स्वीकार करो, पर निशान लगाओ। +all पूरे इंटरनेट को अधिकृत कर देता है और हमेशा गलती है।

जब तक आप यह पता कर रहे हैं कि आपके लिए वैध रूप से कौन भेजता है, ~all से शुरू करें, और DMARC रिपोर्ट साफ़ होने पर -all पर कस लें। उस सबूत के बिना सीधे -all पर जाना वही रास्ता है जिस पर कोई भूला-बिसरा बिलिंग सिस्टम या हेल्पडेस्क किसी तक पहुँचना बंद कर देता है।

ठीक एक रिकॉर्ड, कोई अपवाद नहीं

एक डोमेन एक SPF रिकॉर्ड प्रकाशित कर सकता है। v=spf1 से शुरू होने वाले दो TXT रिकॉर्ड permerror हैं, और permerror का मतलब है कि जाँच को आँका ही नहीं जा सकता — सख़्त प्राप्तकर्ता पर यह सादे फेल से बुरा है। यह लगातार होता है: किसी नए प्रोवाइडर का सेटअप विज़र्ड आपका रिकॉर्ड संपादित करने की जगह अपना जोड़ देता है। उन्हें मिलाने का मतलब है एक रिकॉर्ड जिसमें दोनों सेट के मेकेनिज़्म हों, दो रिकॉर्ड नहीं।

दस लुकअप की सीमा, चुपचाप मारने वाली

यह उस SPF रिकॉर्ड की सबसे आम वजह है जो देखने में बेदाग़ है और फिर भी फेल होता है।

विनिर्देश SPF के आँकने को दस DNS लुकअप तक सीमित करता है। हर include:, a, mx, ptr और exists: एक लुकअप लेता है — और हर शामिल रिकॉर्ड के अंदर के लुकअप भी गिने जाते हैं। एक include: जिसमें खुद तीन include हों, आपके दस में से चार ले लेता है। सीमा पार होने पर नतीजा permerror होता है: फेल नहीं, बल्कि न आँका जा सकने वाला रिकॉर्ड, जिसे कई प्राप्तकर्ता अप्रमाणित मानते हैं।

इसे खतरनाक बनाता है यह कि वह अदृश्य है और खुद-ब-खुद बढ़ता है। जब आपने लिखा था तब आपका रिकॉर्ड पास होता था। महीनों बाद आपके किसी प्रोवाइडर ने अपने रिकॉर्ड में एक include: जोड़ा, आपका जोड़ दस के पार गया, और आपका मेल निशान लगने लगा — आपकी तरफ़ कुछ भी बदले बिना। ip4: और ip6: कोई लुकअप नहीं लेते, और यही आपका सबसे बड़ा औज़ार है।

रिकॉर्ड को ठीक मानने से पहले अपने गिनें। अपने डोमेन का TXT रिकॉर्ड क्वेरी करें, फिर हर शामिल डोमेन का रिकॉर्ड, और तब तक चलें जब तक फैलाने को कुछ न बचे। एक DNS लुकअप टूल इसे तेज़ कर देता है: TXT रिकॉर्ड देखें, फिर हर include: को एक-एक करके देखें।

रिकॉर्ड सही लगने पर भी मेल क्यों फेल होता है

अगर रिकॉर्ड वाक्य-रचना के लिहाज़ से वैध है और लुकअप सीमा के भीतर है, तो इन्हें क्रम से देखें।

• कोई चीज़ बिन-सूचीबद्ध सेवा से भेज रही है। आम संदिग्ध हैं CRM, बिलिंग या टिकटिंग सिस्टम, मार्केटिंग प्लैटफ़ॉर्म, मॉनिटरिंग टूल, या अपने लोकल मेल एजेंट से भेजने वाला ऐप्लिकेशन सर्वर। हर एक को एक include: या उसकी IP रेंज चाहिए।
• लिफ़ाफ़े का प्रेषक कोई दूसरा डोमेन है। «आपकी ओर से» भेजने वाला प्लैटफ़ॉर्म अक्सर अपना रिटर्न पाथ इस्तेमाल करता है, तो SPF उसके डोमेन पर जाँचा जाता है और पास हो जाता है, जबकि आपका DMARC अलाइनमेंट फिर भी फेल रहता है। संदेश एक ही समय पर प्रमाणित और असंरेखित हो सकता है।
• अपने रिकॉर्ड के बिना कोई सबडोमेन। SPF विरासत में नहीं मिलता। mail.example.com से आया मेल ठीक उसी नाम पर जाँचा जाता है, और TXT रिकॉर्ड न होने पर नतीजा none होता है, आपकी एपेक्स नीति नहीं। हर भेजने वाले सबडोमेन के लिए रिकॉर्ड प्रकाशित करें, और जिन्हें कभी नहीं भेजना चाहिए उन पर खाली v=spf1 -all।
• रिकॉर्ड बदला और कैश ने पकड़ा नहीं। आपके TXT रिकॉर्ड पर भी बाकी की तरह TTL होती है, इसलिए सुधार सेव करते ही हर जगह लागू नहीं होता — TTL और प्रोपेगेशन कैसे काम करते हैं समय-सीमा बताता है।
• पुराना पड़ा include:। जिस प्रोवाइडर का इस्तेमाल आपने छोड़ दिया और जिसका डोमेन अब हल नहीं होता, वह permerror दे सकता है, और यह बताने में किसी का फ़ायदा नहीं है।

फ़ॉरवर्डिंग SPF को तोड़ती है, बनावट से ही

यह आपकी गलती नहीं है और आपके रिकॉर्ड में इसे ठीक नहीं किया जा सकता, इसलिए इस पर एक दिन लगाने से पहले समझ लेना ठीक है।

जब कोई प्राप्तकर्ता आपका संदेश आगे भेजता है — किसी विश्वविद्यालय का अलियास, कोई .forward नियम, कोई मेलिंग लिस्ट — तब फ़ॉरवर्ड करने वाला सर्वर अंतिम ठिकाने से अपने IP पते से जुड़ता है और लिफ़ाफ़े के प्रेषक में आपका डोमेन बनाए रखता है। प्राप्तकर्ता आपके SPF रिकॉर्ड को उस IP पर जाँचता है जिसका आपने नाम भी नहीं सुना, और वह फेल हो जाता है। ठीक ही: वह IP सचमुच आपके द्वारा अधिकृत नहीं है।

दो उपाय हैं, और दोनों में से कोई SPF का बदलाव नहीं है। DKIM संदेश पर क्रिप्टोग्राफ़िक हस्ताक्षर करता है और फ़ॉरवर्डिंग से बच जाता है, इसलिए SPF में फेल हुआ फ़ॉरवर्ड संदेश DKIM और इस तरह DMARC पास कर सकता है — दोनों चलाने की यह मुख्य वजह है। SRS (Sender Rewriting Scheme) फ़ॉरवर्ड करने वाले का काम है: वह लिफ़ाफ़े के प्रेषक को अपने डोमेन में बदल देता है, जिससे SPF उसी पर जाँचा जाता है। किसी दूर के फ़ॉरवर्डर को यह करने पर आप मजबूर नहीं कर सकते।

व्यावहारिक नतीजा: SPF की जाँच कभी किसी फ़ॉरवर्ड हुई प्रति से न करें, और यह मानकर -all पर न जाएँ कि आपको दिखता हर फेल कोई हमलावर है।

SPF पास होना DMARC पास होना नहीं है

हेडर में pass और फिर भी DMARC का फेल होना लगभग सबको चकरा देता है, और वजह का नाम है अलाइनमेंट।

SPF लिफ़ाफ़े के प्रेषक को प्रमाणित करता है। DMARC इसके अलावा यह भी माँगता है कि प्रमाणित डोमेन दिखने वाले From: डोमेन से मेल खाए। अपने रिटर्न पाथ से भेजने वाला प्लैटफ़ॉर्म आपको अपने डोमेन पर बेदाग़ SPF पास दे सकता है, जो आपके From: डोमेन के लिए कुछ नहीं करता: SPF जाँच पास हुई, अलाइनमेंट जाँच नहीं, और DMARC उसी आधार पर फेल हो जाता है।

तो SPF कभी स्पूफ़िंग से बचाव था ही नहीं: हमलावर अपने डोमेन के लिए पूरी तरह वैध SPF प्रकाशित कर सकता है और फिर भी From: में आपका नाम डाल सकता है। DMARC ही वह है जो प्रमाणीकरण को उस पते से बाँधता है जो प्राप्तकर्ता सचमुच देखता है, और वही आपको वे रिपोर्ट भेजता है जो बताती हैं कि आपके नाम से कौन भेज रहा है। SPF, DKIM और DMARC की गाइड बताती है कि तीनों कैसे जुड़ते हैं और नीति कैसे लागू करें।

फेल होते रिकॉर्ड को कैसे ठीक करें

इसी क्रम में, क्योंकि हर चरण उन वजहों को हटाता है जिन्हें बाद के चरण वरना छिपा देते।

• पक्का करें कि ठीक एक रिकॉर्ड है। अपने TXT रिकॉर्ड क्वेरी करें और गिनें कि कितने v=spf1 से शुरू होते हैं। एक से ज़्यादा permerror है — कुछ और जाँचने से पहले मेकेनिज़्म को एक रिकॉर्ड में मिलाएँ।
• लुकअप गिनें, भीतर वाले भी। अगर आप दस पर या उसके पास हैं, तो सबसे भारी include: की जगह उन ip4: रेंज डालें जिन पर वह हल होता है, और जिन प्रोवाइडर का इस्तेमाल नहीं करते उनके include हटा दें। एक लावारिस include हटाना अक्सर पूरी गिनती को फिर सीमा के नीचे ले आता है।
• असल में आपके लिए कौन भेजता है, इसकी सूची बनाएँ। यहाँ DMARC की समेकित रिपोर्ट ही भरोसेमंद स्रोत हैं: वे हर उस IP को गिनाती हैं जो आपके डोमेन के नाम से भेजता है, उन सिस्टम समेत जिन्हें कोई याद नहीं रखता। अंदाज़ा लगाने से रिकॉर्ड अधूरा बनता है।
• ptr पूरी तरह हटा दें। वह अप्रचलित है, धीमा है, भरोसेमंद नहीं है, और कुछ प्राप्तकर्ता उसका इस्तेमाल करने वाले रिकॉर्ड को नज़रअंदाज़ कर देते हैं।
• रिपोर्ट साफ़ होने तक ~all पर रहें, फिर -all पर जाएँ। अधूरे रिकॉर्ड पर कठोर फेल आपका ही मेल बाउंस कराता है।
• संपादन से पहले TTL घटाएँ, फिर बाहर से जाँचें। अपने DNS पैनल पर भरोसा करने के बजाय लाइव TXT रिकॉर्ड को DNS लुकअप टूल से देखें, और पुरानी TTL बीतने के बाद दोबारा जाँचें।

आम गलतियाँ

• दो SPF रिकॉर्ड, क्योंकि किसी प्रोवाइडर के विज़र्ड ने अपना जोड़ दिया। permerror, और फेल से बुरा।
• दस लुकअप पार करना और कभी पता न चलना, क्योंकि वह फेल किसी और के लॉग में permerror होता है।
• हर वैध प्रेषक जानने से पहले -all पर कूदना। जिसे आप भूल गए, वही सिस्टम आम तौर पर आपके ग्राहकों को बिल भेजता है।
• यह उम्मीद करना कि सबडोमेन विरासत पाएँगे। वे नहीं पाते। हर भेजने वाले सबडोमेन के लिए रिकॉर्ड प्रकाशित करें।
• ptr इस्तेमाल करना, या +all, जो सबको अधिकृत कर देता है।
• फ़ॉरवर्ड हुए संदेश से जाँच करना। फ़ॉरवर्डिंग SPF में जायज़ रूप से फेल होती है और आपके रिकॉर्ड के बारे में कुछ नहीं बताती।
• यह मान लेना कि SPF पास होने का मतलब DMARC पास है। दिखने वाले From: डोमेन से अलाइनमेंट के बिना ऐसा नहीं है।
• रिकॉर्ड बदलकर तुरंत टेस्ट करना। पुराना TXT रिकॉर्ड अपनी पूरी TTL तक कैश में रहता है।

संक्षेप में

SPF जुड़ने वाले IP की तुलना एक TXT रिकॉर्ड से करता है और लिफ़ाफ़े के अदृश्य प्रेषक को जाँचता है, उस From: पते को नहीं जो आपका प्राप्तकर्ता पढ़ता है। ठीक एक रिकॉर्ड प्रकाशित करें, कुल DNS लुकअप — हर include: के अंदर वाले समेत — दस या उससे कम रखें, आपके लिए वैध रूप से भेजने वाली हर सेवा सूचीबद्ध करें, हर भेजने वाले सबडोमेन को उसका अपना रिकॉर्ड दें, और जब तक आपकी DMARC रिपोर्ट यह साबित न करें कि सूची पूरी है, ~all पर रहें। फ़ॉरवर्ड हुआ मेल आप जो भी करें SPF में फेल होगा, और इसीलिए उसके साथ DKIM और DMARC मौजूद हैं। किसी भी डोमेन का लाइव TXT रिकॉर्ड पढ़ें, हर include: फैलाएँ और बची हुई TTL देखें मुफ़्त DNS लुकअप टूल से।

संबंधित टूल और गाइड:

• DNS लुकअप — मान और TTL के साथ A, AAAA, MX, TXT, NS और अधिक DNS रिकॉर्ड क्वेरी करें, साथ ही रिवर्स DNS।
• DMARC रिपोर्ट कैसे पढ़ें, XML में डूबे बिना — DMARC एग्रीगेट रिपोर्ट में क्या होता है

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