SPF, DKIM और DMARC: ईमेल प्रमाणीकरण की पूरी गाइड

ईमेल उस दौर में बना था जब किसी ने यह सोचा ही नहीं था कि भेजने वाले का पता झूठा हो सकता है। मूल प्रोटोकॉल में ऐसा कुछ नहीं है जो इंटरनेट की किसी भी मशीन को मेल सर्वर से जुड़कर यह दावा करने से रोके कि वह आप हैं। यही खाई फ़िशिंग को काम करने देती है, और इसी वजह से आज DNS पर आधारित तीन मानक — SPF, DKIM और DMARC — तय करते हैं कि आपका ईमेल इनबॉक्स में जाएगा या स्पैम फ़ोल्डर में।

तीनों आपके डोमेन के DNS रिकॉर्ड में रहते हैं, इसलिए किसी भी डोमेन का — आपके अपने सहित — ईमेल प्रमाणीकरण सेटअप सिर्फ़ एक DNS लुकअप से देखा जा सकता है। यह गाइड बताती है कि हर रिकॉर्ड क्या करता है, उसे कैसे पढ़ें, और सख़्त DMARC नीति तक कैसे पहुँचें — बिना गलती से अपने ही चालान ब्लॉक किए।

तीनों रिकॉर्ड एक साथ जाँचने के लिए, SPF लुकअप की गिनती और आपकी DKIM कुंजी के आकार समेत, हमारा SPF, DKIM और DMARC चेकर इस्तेमाल करें।

ईमेल प्रमाणीकरण क्यों ज़रूरी है

पिछले कुछ वर्षों में दो चीज़ें बदलीं। हमलावर भरोसेमंद ब्रांडों की नकल करने में कहीं बेहतर हो गए, और बड़े मेलबॉक्स प्रदाताओं ने जवाब में प्रमाणीकरण को व्यावहारिक रूप से अनिवार्य बना दिया। Gmail और Yahoo अब थोक भेजने वालों से SPF, DKIM और DMARC माँगते हैं, और Microsoft ने भी यही रास्ता अपनाया। अगर आपके रिकॉर्ड गायब या टूटे हुए हैं, तो नतीजे तुरंत और बहुत व्यावहारिक होते हैं:

• आपका मेल फ़िल्टर हो जाता है। बिना प्रमाणीकरण वाले संदेश कहीं ज़्यादा बार क्वारंटीन होते हैं, और कभी-कभी किसी मेलबॉक्स तक पहुँचने से पहले ही अस्वीकार कर दिए जाते हैं।
• कोई भी आपका डोमेन स्पूफ कर सकता है। DMARC नीति के बिना, प्राप्तकर्ता सर्वर के पास आपके नाम से आए जाली मेल को ठुकराने का कोई निर्देश नहीं होता।
• दुरुपयोग दिखता ही नहीं। DMARC रिपोर्टिंग ही एकमात्र तरीका है जिससे पता चलता है कि कोई आपके नाम से फ़िशिंग भेज रहा है।
• सौदे अटक जाते हैं। सुरक्षा प्रश्नावलियाँ और वेंडर समीक्षाएँ नियमित रूप से DMARC नीति माँगती हैं, और «none» को अब तेज़ी से एक कमी माना जाने लगा है।

तीनों रिकॉर्ड एक नज़र में

ये परतें हैं, विकल्प नहीं। SPF भेजने वाले सर्वर की जाँच करता है, DKIM संदेश की, और DMARC दोनों को उस डोमेन से जोड़ता है जो इंसान वास्तव में From हेडर में देखता है, और विफलता पर क्या करना है यह बताता है। तीनों चाहिए।

SPF: आपके डोमेन से कौन भेज सकता है

Sender Policy Framework उन सर्वरों की प्रकाशित सूची है जिन्हें आपके डोमेन से मेल भेजने की अनुमति है। प्राप्तकर्ता सर्वर जुड़ने वाले IP पते को लेता है, आपका SPF रिकॉर्ड देखता है, और जाँचता है कि वह पता सूची में है या नहीं।

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

एक सामान्य रिकॉर्ड ऐसा दिखता है:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

इसे बाएँ से दाएँ पढ़ें। v=spf1 संस्करण है और सबसे पहले आना चाहिए। हर include: किसी दूसरे डोमेन का SPF रिकॉर्ड खींच लाता है — इसी तरह Google Workspace या किसी ट्रांज़ैक्शनल मेल सेवा को अधिकृत किया जाता है। ip4: और ip6: विशिष्ट पते या रेंज अधिकृत करते हैं, आमतौर पर आपका अपना सर्वर। आख़िरी मैकेनिज़्म कैच-ऑल है, और यही सबसे ज़्यादा गलत सेट किया जाता है:

• -all हार्ड फ़ेल है। जो सूचीबद्ध नहीं, वह अनधिकृत है और प्राप्तकर्ता से उसे अस्वीकार करने की अपेक्षा है।
• ~all सॉफ़्ट फ़ेल है। असूचीबद्ध भेजने वाले संदिग्ध हैं पर स्वीकार किए जाते हैं, आमतौर पर स्पैम दंड के साथ।
• ?all तटस्थ है और प्राप्तकर्ता को कुछ नहीं बताता, जिससे रिकॉर्ड प्रकाशित करने का अर्थ ही ख़त्म हो जाता है।

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

दस लुकअप की सीमा

SPF एक रिकॉर्ड के मूल्यांकन में अधिकतम दस DNS लुकअप की अनुमति देता है। हर include:, a, mx और redirect गिना जाता है, नेस्टेड वाले भी। सीमा पार होते ही परिणाम स्थायी त्रुटि है, जिसे अधिकांश प्राप्तकर्ता SPF के बिल्कुल न होने जैसा मानते हैं। तीन-चार मेल प्रदाता ही अक्सर सीमा तोड़ने को काफ़ी होते हैं, इसलिए हर नई भेजने वाली सेवा जोड़ते समय रिकॉर्ड की समीक्षा करें और जिन्हें छोड़ चुके हैं उन्हें हटाएँ।

एक और नियम लोगों को चौंकाता है: एक डोमेन केवल एक SPF रिकॉर्ड प्रकाशित कर सकता है। एक ही नाम पर दो v=spf1 TXT रिकॉर्ड स्थायी त्रुटि हैं, विलय नहीं।

DKIM: अपने ईमेल पर हस्ताक्षर करना

DomainKeys Identified Mail हर बाहर जाते संदेश में एक क्रिप्टोग्राफ़िक हस्ताक्षर जोड़ता है। आपका मेल सर्वर एक निजी कुंजी रखता है और चुने हुए हेडर तथा बॉडी पर हस्ताक्षर करता है; उससे मेल खाती सार्वजनिक कुंजी DNS में प्रकाशित होती है। प्राप्तकर्ता सार्वजनिक कुंजी लाता है, हस्ताक्षर सत्यापित करता है, और दो बातें जान जाता है: संदेश वाकई आपके डोमेन ने हस्ताक्षरित किया था, और जिस हिस्से को हस्ताक्षर ढकता था वह रास्ते में बदला नहीं गया।

सार्वजनिक कुंजी एक सेलेक्टर से बने नाम पर रहती है, जैसे google._domainkey.example.com या s1._domainkey.example.com। सेलेक्टर इसलिए हैं ताकि आप एक साथ कई कुंजियाँ चला सकें, और इसी से कुंजी-रोटेशन आसान हो जाता है: नया सेलेक्टर प्रकाशित करें, हस्ताक्षर उस पर ले जाएँ, पुराना बाद में हटा दें।

चूँकि हस्ताक्षर संदेश के साथ चलता है, DKIM उन स्थितियों में फ़ॉरवर्डिंग झेल जाता है जहाँ SPF नहीं झेलता। अगर कोई मेलिंग लिस्ट आपका मेल आगे भेजती है, तो जुड़ने वाला IP बदल जाता है और SPF विफल हो जाता है, पर DKIM हस्ताक्षर तब तक मान्य रहता है जब तक लिस्ट ने हस्ताक्षरित हेडर या बॉडी दोबारा न लिखी हो। यही मज़बूती मुख्य वजह है कि SPF पहले से होने पर भी DKIM मायने रखता है।

DMARC: प्राप्तकर्ता को क्या करना है बताना

SPF और DKIM दोनों पास या फ़ेल देते हैं, पर कोई यह नहीं कहता कि प्राप्तकर्ता करे क्या, और कोई उस From पते को नहीं देखता जो आपका पाठक असल में पढ़ता है। DMARC दोनों कमियाँ भरता है। एक रिकॉर्ड ऐसा दिखता है:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=r

p= नीति है: none (केवल निगरानी), quarantine (विफलताओं को स्पैम मानें), या reject (दरवाज़े पर ही ठुकराएँ)। rua= वह पता है जिस पर रोज़ाना समेकित रिपोर्ट आती हैं, और यही रिकॉर्ड का सबसे मूल्यवान हिस्सा है। pct= रोलआउट के दौरान नीति को मेल के एक प्रतिशत हिस्से पर लागू करने देता है।

अलाइनमेंट — वह हिस्सा जो सब चूक जाते हैं

DMARC सिर्फ़ यह नहीं माँगता कि SPF या DKIM पास हो। वह माँगता है कि पास होने वाला डोमेन दिखने वाले From हेडर के डोमेन से अलाइन हो। एक संदेश mailer.vendor.com के लिए SPF पास कर सकता है और फिर भी example.com के लिए DMARC विफल हो सकता है, क्योंकि दोनों मेल नहीं खाते। सही दिखने वाला सेटअप फिर भी विफल क्यों होता है — इसका यही सबसे आम कारण है।

adkim और aspf तय करते हैं कि मिलान कितना सख़्त हो। रिलैक्स्ड (r, डिफ़ॉल्ट) mail.example.com जैसे सबडोमेन को स्वीकार करता है; स्ट्रिक्ट (s) हूबहू मिलान माँगता है। रिलैक्स्ड से शुरू करें। DMARC तब पास होता है जब SPF या DKIM में से कोई एक पास हो और अलाइन हो, इसलिए एक अलाइन DKIM हस्ताक्षर ही काफ़ी है।

नीति को सुरक्षित तरीके से लागू करना

1. रिपोर्टिंग पते के साथ p=none प्रकाशित करें। आपके मेल प्रवाह में कुछ नहीं बदलता, पर रिपोर्ट आनी शुरू हो जाती हैं।
2. दो से चार हफ़्ते रिपोर्ट पढ़ें। वे भूली हुई भेजने वाली सेवाएँ उजागर करेंगी: CRM, हेल्पडेस्क, बिलिंग टूल, पुराना मार्केटिंग प्लेटफ़ॉर्म।
3. खाइयाँ भरें। हर वैध भेजने वाले को SPF में जोड़ें, अलाइन डोमेन के साथ DKIM हस्ताक्षर चालू करें, और अगली रिपोर्ट में बदलाव की पुष्टि करें।
4. p=quarantine पर जाएँ। बड़े वॉल्यूम पर pct= से धीरे-धीरे बढ़ाएँ।
5. p=reject पर पूरा करें। तभी, जब रिपोर्ट में कोई वैध मेल विफल न दिखे। यही वह नीति है जो स्पूफिंग को वास्तव में रोकती है।

अपने रिकॉर्ड खुद कैसे जाँचें

तीनों सार्वजनिक TXT रिकॉर्ड हैं, इसलिए जाँच में कुछ सेकंड लगते हैं:

1. SPF. DNS लुकअप टूल से अपने सादे डोमेन पर TXT लुकअप चलाएँ और v=spf1 से शुरू होने वाली स्ट्रिंग ढूँढ़ें। पक्का करें कि वह ठीक एक है, और लुकअप गिनें।
2. DMARC. _dmarc. और अपने डोमेन पर TXT लुकअप चलाएँ। कुछ न लौटे तो आपके पास न नीति है, न रिपोर्टिंग।
3. DKIM. selector._domainkey. और अपने डोमेन पर TXT लुकअप चलाएँ। आपके मेल प्रदाता के दस्तावेज़ में सेलेक्टर का नाम होता है।
4. आद्योपांत सत्यापित करें। किसी बड़े प्रदाता के खाते पर संदेश भेजें और प्राप्त हेडर देखें। Gmail का «मूल दिखाएँ» दृश्य अभी-अभी भेजे गए संदेश के SPF, DKIM और DMARC परिणाम बताता है, और यही एकमात्र परीक्षण है जो पूरी शृंखला को ढकता है।

DNS में हैं ही, तो बाकी मेल सेटअप भी पक्का कर लें: देखें कि MX रिकॉर्ड वहीं इशारा करते हैं जहाँ आप सोचते हैं, और सर्वर के प्रमाणपत्र का होस्टनाम मेल खाता है — जिसे आप SSL प्रमाणपत्र जाँचकर्ता से सत्यापित कर सकते हैं।

आम गलतियाँ जिनसे बचें

• दो SPF रिकॉर्ड। उन्हें एक में मिलाएँ। दो स्थायी त्रुटि हैं।
• DMARC को हमेशा p=none पर छोड़ना। निगरानी शुरुआत है, मंज़िल नहीं। स्पूफिंग केवल quarantine या reject रोकता है।
• रिपोर्टिंग पता न देना। rua= के बिना DMARC रिकॉर्ड वही जानकारी फेंक देता है जो नीति सुरक्षित रूप से कसने के लिए चाहिए।
• पार्क किए डोमेन भूलना। जो डोमेन मेल नहीं भेजते उन्हें v=spf1 -all और p=reject प्रकाशित करना चाहिए — ठीक इसलिए कि हमलावर अनुपयोगी डोमेन पसंद करते हैं।
• सीधे स्ट्रिक्ट अलाइनमेंट पर कूदना। रिपोर्ट साफ़ होने से पहले adkim=s और aspf=s सबडोमेन से आने वाला वैध मेल तोड़ देंगे।
• TTL की अनदेखी। TXT रिकॉर्ड पर लंबा TTL यानी सुधार फैलने में घंटों लगेंगे। माइग्रेशन से पहले घटाएँ और बाद में बढ़ाएँ।

आज ही अपना ईमेल प्रमाणित करें

ईमेल प्रमाणीकरण उन गिनी-चुनी सुरक्षा कार्यों में है जिनका लाभ स्पष्ट है: बेहतर डिलीवरेबिलिटी, दुरुपयोग पर नज़र, और ऐसा डोमेन जिसे यूँ ही स्पूफ नहीं किया जा सकता। यह पूरी तरह बाहर से पढ़ा जा सकता है, इसलिए अपनी ही व्यवस्था के बारे में अंदाज़ा लगाने की कोई वजह नहीं। मुफ़्त DNS लुकअप टूल से अपने डोमेन पर TXT लुकअप से शुरू करें, पढ़ें कि असल में क्या प्रकाशित है, और ऊपर दिए रोलआउट को एक-एक कदम पूरा करें।

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

• DNS लुकअप — किसी भी डोमेन के TXT, MX, SPF और बाकी सभी रिकॉर्ड देखें।
• DNS लुकअप: पूरी गाइड — हर रिकॉर्ड प्रकार की व्याख्या।
• SSL प्रमाणपत्र जाँचकर्ता — अपने मेल या वेब सर्वर का प्रमाणपत्र देखें।
• HTTP स्टेटस कोड — हर प्रतिक्रिया कोड का त्वरित संदर्भ।
• आपका SPF रिकॉर्ड बार-बार फेल क्यों होता है (और कैसे ठीक करें) - दस-लुकअप सीमा, टूटे include और SPF विफल होने के अन्य कारण।

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