एक डोमेन के लिए DKIM SPF DMARC सेटअप

एक डोमेन के लिए DKIM SPF DMARC सेटअप: ईमेल प्रमाणीकरण के लिए एक संपूर्ण गाइड

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

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

DKIM, SPF और DMARC क्या हैं और ये क्यों महत्वपूर्ण हैं

DKIM, SPF और DMARC एक समान समस्या का समाधान करते हैं, लेकिन वे इसे अलग-अलग तरीकों से करते हैं। यदि आप योजना बना रहे हैं डोमेन के लिए ईमेल प्रमाणीकरण सेटअप.

SPF इस प्रश्न का उत्तर देता है: “कौन से सर्वर वास्तव में इस डोमेन की ओर से मेल भेजने की अनुमति है?” DNS में, आप अनुमोदित प्रेषकों की एक सूची प्रकाशित करते हैं, और प्राप्तकर्ता का मेल सर्वर इसे उस वास्तविक IP पते के साथ तुलना करता है जिससे संदेश आया था।

DKIM संदेश में एक क्रिप्टोग्राफिक हस्ताक्षर जोड़ता है। प्राप्तकर्ता यह जांचता है कि क्या ईमेल वास्तव में आपके डोमेन द्वारा हस्ताक्षरित था और क्या इसे रास्ते में बदला गया था। यह केवल एक अनुमति सूची से अधिक है — यह प्रेषक की पहचान और संदेश की अखंडता का प्रमाण है।

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

इसलिए ये तंत्र केवल जाली ईमेल को रोकने के बारे में नहीं हैं। ये सीधे डिलीवरी पर प्रभाव डालते हैं। मेल सेवाएँ अब केवल संदेश की सामग्री पर नहीं, बल्कि इसकी प्रमाणीकरण की सेटअप पर भी ध्यान देती हैं। एक व्यवसाय डोमेन के लिए, यह महत्वपूर्ण है: कुछ संदेश खोना एक बात है, लेकिन ग्राहकों, भागीदारों और सेवाओं के लिए बार-बार स्पैम में जाना पूरी तरह से अलग बात है।

DKIM SPF DMARC एक साथ कैसे काम करते हैं

प्रत्येक प्रोटोकॉल अपने आप में उपयोगी है, लेकिन मिलकर वे एक अधिक विश्वसनीय सत्यापन प्रणाली बनाते हैं।

SPF पुष्टि करता है कि संदेश एक अनुमोदित सर्वर से आया है। लेकिन इसकी एक सीमा है: यदि ईमेल को अग्रेषित किया जाता है, तो SPF "टूट" सकता है क्योंकि अंतिम प्रेषक का IP पता बदल जाता है। DKIM अक्सर उन मामलों में मदद करता है क्योंकि हस्ताक्षर अग्रेषण के बाद भी मान्य रहता है, जब तक कि संदेश स्वयं को संशोधित नहीं किया गया।

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

साधारण शब्दों में कहें: SPF प्रवेश पर एक मेहमान सूची है, DKIM दस्तावेज़ पर एक मुहर है, और DMARC उन आगंतुकों के लिए सुरक्षा नियम है जिनके पास न तो पास है और न ही मुहर। एक उपाय बिना अन्य के एक अंतर छोड़ देता है।

इसलिए इन्हें एक साथ लागू किया जाना चाहिए। यह विशेष रूप से उन कंपनियों के लिए महत्वपूर्ण है जो कई ईमेल स्रोतों का उपयोग करती हैं: CRM सिस्टम, न्यूज़लेटर सेवाएँ, टिकटिंग प्लेटफ़ॉर्म, संपर्क फ़ॉर्म, लेनदेन संबंधी सूचनाएँ। यदि ये मेल नहीं खाते हैं, तो ईमेल अवसंरचना एक असंबंधित द्वीपों के संग्रह की तरह व्यवहार करने लगती है।

सेटअप के लिए तैयारी: डोमेन, DNS और ईमेल सेवा

कोई भी रिकॉर्ड बनाने से पहले, आपको यह समझने की आवश्यकता है कि वास्तव में डोमेन की ओर से मेल कौन भेजता है। यह एक ईमेल सेवा हो सकती है, या कई: कॉर्पोरेट ईमेल, एक मेलिंग प्लेटफ़ॉर्म, एक सूचना प्रणाली, वेबसाइट के लिए एक अलग SMTP सेवा। बिना इस चित्र के, आप बहुत अधिक अनुमति देने या इसके विपरीत, आवश्यक प्रेषक को गलती से ब्लॉक करने का जोखिम उठाते हैं।

आपको डोमेन के DNS पैनल तक पहुंच की आवश्यकता होगी। आमतौर पर यह रजिस्ट्रार का इंटरफ़ेस, आपका होस्टिंग प्रदाता, या एक अलग DNS प्रदाता होता है। यह जानना महत्वपूर्ण है कि रिकॉर्ड कहां संपादित किए जाते हैं: कभी-कभी एक व्यक्ति मेल सेवा में समस्या की तलाश करता है, जबकि रिकॉर्ड वास्तव में किसी अन्य प्रदाता के पास होता है।

एक और आवश्यक कदम ईमेल प्रदाता से विवरण एकत्र करना है। आमतौर पर आपको आवश्यकता होगी:

• SPF डेटा या एक अनुशंसित SPF रिकॉर्ड;
• एक DKIM कुंजी या एक उत्पन्न करने के लिए निर्देश;
• DKIM चयनकर्ता का नाम, यदि प्रदाता इसका उपयोग करता है;
• DMARC अनुशंसाएँ;
• भेजने के लिए उपयोग किए जाने वाले डोमेन और उपडोमेन की एक सूची;
• यह समझना कि कौन सी सेवाएँ अब मेल भेजती हैं और कौन सी बाद में जोड़ी जाएंगी।

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

डोमेन के लिए SPF सेटअप करना

एक SPF रिकॉर्ड DNS में TXT रिकॉर्ड के रूप में प्रकाशित होता है। इसका काम अनुमोदित भेजने वाले स्रोतों की सूची बनाना है। मूल विचार सरल है: आप निर्दिष्ट करते हैं कि कौन से सेवाएँ और सर्वर डोमेन की ओर से मेल भेजने की अनुमति है, और बाकी सब कुछ अनधिकृत माना जाता है।

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

टिपिकल SPF लॉजिक ऐसे तंत्रों के चारों ओर बनाया गया है जैसे कि include, ip4, ip6 और mx। व्यावहारिक रूप से, इसका मतलब है कि आप एक तृतीय-पक्ष मेलिंग सेवा, विशिष्ट IP पते, या डोमेन के मेल सर्वरों को शामिल कर सकते हैं। लेकिन एक पकड़ है: हर अतिरिक्त प्रविष्टि रिकॉर्ड को लंबा और अधिक जटिल बनाती है।

एक और सामान्य गलती बहुत व्यापक होना है। कभी-कभी लोग केवल "कुछ भी तोड़ने से बचने" के लिए अत्यधिक उदार नियमों का उपयोग करते हैं। परिणामस्वरूप, आवश्यक से अधिक भेजने वालों को अनुमति दी जाती है। यह पहले सुविधाजनक है, लेकिन सुरक्षा के लिए खराब है, और यदि आपको जाली संदेशों के खिलाफ सुरक्षा की परवाह है, तो SPF को सटीक होना चाहिए, केवल "लगभग सही" नहीं।

रिकॉर्ड प्रकाशित करने के बाद, जांचें कि यह वास्तव में DNS में दिखाई दे रहा है और आपके वर्तमान भेजने वाले स्रोतों से मेल खाता है। यदि आप कई प्लेटफार्मों के माध्यम से मेल भेजते हैं, तो प्रत्येक एक की पुष्टि करें। अन्यथा, आप आसानी से ऐसी स्थिति में समाप्त हो सकते हैं जहाँ CRM ईमेल पास होते हैं, लेकिन वेबसाइट सूचनाएँ नहीं होतीं।

DKIM सेटअप करना: एक कुंजी उत्पन्न करना और DNS रिकॉर्ड प्रकाशित करना

DKIM एक कुंजी जोड़ी के साथ काम करता है: निजी कुंजी प्रेषक के पास रहती है, और सार्वजनिक कुंजी DNS में प्रकाशित होती है, और जब एक संदेश भेजा जाता है, तो सर्वर इसे निजी कुंजी के साथ हस्ताक्षरित करता है। प्राप्तकर्ता DNS से सार्वजनिक कुंजी लेता है और हस्ताक्षर की पुष्टि करता है। यदि सब कुछ मेल खाता है, तो संदेश को प्रामाणिक माना जाता है।

DKIM आमतौर पर ईमेल सेवा के माध्यम से कॉन्फ़िगर किया जाता है। प्रदाता के डैशबोर्ड में, आप डोमेन का चयन करते हैं, एक कुंजी उत्पन्न करते हैं या तैयार सेटिंग्स प्राप्त करते हैं, और फिर कुंजी के सार्वजनिक भाग के साथ एक TXT रिकॉर्ड प्रकाशित करते हैं। रिकॉर्ड में अक्सर एक चयनकर्ता शामिल होता है - एक विशेष नाम जो एक कुंजी को दूसरी से अलग करने में मदद करता है। यह विशेष रूप से उपयोगी है यदि डोमेन में कई प्रेषण प्रणाली हैं या आप कुंजी को घुमाने की योजना बना रहे हैं।

DNS रिकॉर्ड प्रकाशित करने के बाद, आपको सेवा में आउटगोइंग संदेशों के लिए हस्ताक्षर सक्षम करने की आवश्यकता है, और इसके बिना, DNS रिकॉर्ड बेकार है: कुंजी क्षेत्र में रहेगी, लेकिन ईमेल बिना हस्ताक्षरित रहेंगे। समस्या निवारण के दृष्टिकोण से, यह एक सामान्य जाल है: “रिकॉर्ड जोड़ा गया, लेकिन DKIM काम नहीं करता।” वास्तव में, हस्ताक्षर बस प्रेषक की ओर से सक्षम नहीं किया गया था, इसलिए डोमेन के लिए ईमेल प्रमाणीकरण सेटअप अधूरा रहता है।

तकनीकी रूप से, यह जांचना महत्वपूर्ण है:

• क्या चयनकर्ता DNS और सेवा सेटिंग्स के बीच मेल खाता है;
• क्या TXT रिकॉर्ड सही ढंग से प्रकाशित किया गया था;
• क्या कुंजी को पेस्ट करते समय गलती से काट दिया गया था;
• क्या सभी आवश्यक संदेश प्रकार हस्ताक्षरित हैं, न कि केवल कुछ;
• क्या हस्ताक्षर के बाद संदेश में परिवर्तन होता है, उदाहरण के लिए, एक मध्यवर्ती सेवा द्वारा अतिरिक्त प्रसंस्करण के कारण।

DKIM विशेष रूप से लेन-देन संबंधी ईमेल के लिए उपयोगी है: पंजीकरण पुष्टि, पासवर्ड रीसेट, आदेश सूचनाएँ। इन संदेशों को लगातार पहुंचना आवश्यक है। यदि साइट की संरचना अच्छी तरह से व्यवस्थित है और लॉन्च के बाद ठोस समर्थन है, जैसे लॉन्च के बाद वेबसाइट समर्थन, ईमेल प्रमाणीकरण आमतौर पर उन चीजों में से एक है जो "बाद में" नहीं टाली जाती। और यही सही दृष्टिकोण है।

DMARC नीति और रिपोर्ट सेटअप करना

DMARC नियंत्रण जोड़ता है। इसके बिना, आप SPF और DKIM को अलग-अलग देख सकते हैं, लेकिन आपके पास संदिग्ध संदेशों के साथ क्या करना है, इसके लिए कोई स्पष्ट नियम नहीं है। एक DMARC रिकॉर्ड भी DNS में TXT रिकॉर्ड के रूप में प्रकाशित होता है, आमतौर पर _dmarc उपडोमेन के तहत।

शुरुआत में, कई लोग कोई नीति चुनते हैं। यह एक निगरानी मोड है: संदेशों को अवरुद्ध नहीं किया जाता है, लेकिन डोमेन के मालिक को रिपोर्ट मिलती है और वह देख सकता है कि कौन मेल भेज रहा है, क्या जांचें पास हो रही हैं, और कहां अंतराल हैं। यह एक समझदारी भरा पहला कदम है, विशेष रूप से यदि बुनियादी ढांचा जटिल है और आप अचानक वैध संदेशों को बंद नहीं करना चाहते।

निगरानी अवधि के बाद, नीति को कड़ा किया जा सकता है: क्वारंटाइन संदिग्ध संदेशों को स्पैम या क्वारंटाइन में भेजता है, जबकि अस्वीकार उन्हें सीधे ब्लॉक करता है। कौन सा विकल्प चुनना है, यह इस पर निर्भर करता है कि आपकी ईमेल सेटअप कितनी परिपक्व है और आप कितने आत्मविश्वासी हैं कि सभी वैध स्रोत पहले से ही शामिल हैं।

DMARC रिपोर्ट में, केवल त्रुटियों की तलाश करना ही उपयोगी नहीं है, बल्कि अप्रत्याशित भेजने वाले स्रोतों के लिए भी देखना है, और कभी-कभी पुराने सेवाएँ, परीक्षण प्लेटफार्म, या भूले हुए एकीकरण वहाँ दिखाई देते हैं। यह चीजों को साफ करने का एक अच्छा अवसर है।

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

तैनाती के बाद सत्यापन और समस्या निवारण

सेटअप के बाद, इस भावना पर निर्भर न रहें कि “यह काम करता है।” सत्यापन जानबूझकर और विधिपूर्वक होना चाहिए।

पहले, सुनिश्चित करें कि SPF रिकॉर्ड DNS में दिखाई दे रहा है और केवल वर्तमान स्रोतों को शामिल करता है। फिर एक परीक्षण संदेश भेजें और प्राप्तकर्ता पक्ष पर हेडर की जांच करें: वे आमतौर पर दिखाते हैं कि क्या SPF पास हुआ, क्या DKIM हस्ताक्षर है, और क्या DMARC सक्रिय हुआ।

यदि संदेश सत्यापन में विफल होता है, तो कारण को चरण दर चरण देखें:

1. क्या DNS रिकॉर्ड सही ढंग से दर्ज किए गए हैं;
2. क्या DNS प्रसार के लिए पर्याप्त समय बीत चुका है;
3. क्या From में डोमेन हस्ताक्षरित डोमेन से मेल खाता है;
4. क्या संदेश उस सेवा द्वारा हस्ताक्षरित किया जा रहा है जिसकी आप अपेक्षा करते हैं;
5. क्या कोई मध्यवर्ती प्रणाली हस्ताक्षर के बाद संदेश को संशोधित कर रही है।

यह परीक्षण करना बहुत उपयोगी है कि केवल एक संदेश नहीं, बल्कि कई परिदृश्यों का परीक्षण करें: वेबसाइट पर एक फॉर्म, एक CRM ईमेल, एक पंजीकरण सूचना, एक ईमेल मार्केटिंग सेवा के माध्यम से भेजा गया न्यूज़लेटर। कभी-कभी समस्या केवल एक चैनल में प्रकट होती है जबकि अन्य सही दिखते हैं।

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

सेटअप को स्वस्थ रखने के लिए सामान्य प्रश्न और सिफारिशें

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

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

क्या सेटिंग्स को नियमित जांच की आवश्यकता है? हाँ। विशेष रूप से यदि आपने होस्टिंग बदली है, डोमेन को स्थानांतरित किया है, एक नया CRM जोड़ा है, या अपने मेलिंग सिस्टम को अपडेट किया है। कभी-कभी DNS रिकॉर्ड पुराने रह जाते हैं बस इसलिए क्योंकि कोई उन्हें याद नहीं रखता। और भूले हुए रिकॉर्ड अक्सर त्रुटियों का एक छिपा हुआ स्रोत होते हैं।

यदि आप सुनिश्चित नहीं हैं कि आपकी वर्तमान ईमेल-भेजने की सेटअप पारदर्शी है, तो इसे एक संपूर्णता के रूप में देखना समझदारी है: कौन भेजता है, कौन हस्ताक्षर करता है, रिकॉर्ड कहाँ संग्रहीत हैं, और परिवर्तन के लिए कौन जिम्मेदार है। अधिक जटिल परियोजनाओं में, यह समग्र समर्थन और तकनीकी वास्तुकला का हिस्सा बन जाता है, न कि पांच मिनट का "IT कार्य।"

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

यदि आप एक ऐसा डोमेन चाहते हैं जो न केवल पते की पट्टी में अच्छा दिखता है बल्कि मेल जांचों को आत्मविश्वास के साथ पास भी करता है, तो SPF, DKIM और DMARC को परियोजना का अनिवार्य हिस्सा माना जाना चाहिए। यह एक सजावटी उपाय नहीं है - यह आपके ब्रांड की रक्षा करने, विश्वास बनाने और ईमेल वितरण को पूर्वानुमानित बनाने का एक तरीका है। और पूर्वानुमानिता, जैसा कि प्रथा दिखाती है, किसी भी चमकदार लेकिन नाजुक सेटअप से अधिक मूल्यवान है।