Cloudflare में SPF, DKIM, और DMARC कैसे सेट करें

यदि आप Cloudflare में SPF DKIM और DMARC सेट करने का तरीका सीखने की कोशिश कर रहे हैं, तो एक साधारण तथ्य से शुरू करें: Cloudflare DNS रिकॉर्ड्स को स्टोर करता है, लेकिन आपके मेल प्रदाता मान प्रदान करते हैं। यह छोटा लगता है। यह छोटा नहीं है।

Cloudflare वह स्थान है जहाँ रिकॉर्ड रहते हैं, और इसका मतलब है कि आप इसके DNS पैनल में TXT या CNAME प्रविष्टियों को संपादित करेंगे। वास्तविक SPF शामिल स्ट्रिंग, DKIM चयनकर्ता, सार्वजनिक कुंजी, और DMARC नीति उस सेवा से आती है जो आपका मेल भेजती है, चाहे वह Google Workspace, Microsoft 365, SendGrid, Mailgun, या कोई अन्य प्लेटफ़ॉर्म हो। बिना उन मानों के, आप अनुमान लगा रहे हैं।

1. पुष्टि करें कि Cloudflare ईमेल प्रमाणीकरण के लिए क्या कर सकता है और क्या नहीं कर सकता

Cloudflare SPF, DKIM, या DMARC मानों का आविष्कार नहीं करता। यह केवल उन्हें प्रकाशित करता है। यदि आपका प्रदाता SPF के लिए TXT रिकॉर्ड जोड़ने के लिए कहता है, तो Cloudflare इसे होस्ट कर सकता है। यदि प्रदाता आपको एक DKIM चयनकर्ता और एक CNAME लक्ष्य देता है, तो Cloudflare उसे भी होस्ट कर सकता है। लेकिन यह यह तय नहीं कर सकता कि कौन से सर्वर आपके लिए मेल भेज सकते हैं।

यह महत्वपूर्ण है क्योंकि लोग अक्सर पहले Cloudflare खोलते हैं और एक जादुई बटन की तलाश करते हैं। ऐसा कोई नहीं है। आपको DNS को छूने से पहले अपने प्रेषक से सटीक रिकॉर्ड सामग्री की आवश्यकता है, या आप एक ऐसा रिकॉर्ड प्रकाशित करने का जोखिम उठाते हैं जो डैशबोर्ड जांच में पास होता है और वास्तविक मेलबॉक्स में विफल होता है।

2. अपने ईमेल भेजने वाले प्लेटफ़ॉर्म से DNS मान एकत्र करें

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

मानों को एक स्थान पर लिखें। सटीक चयनकर्ता नामों का उपयोग करें। यदि आपका प्रदाता आपको दो चयनकर्ता देता है, तो उन्हें फिर से नामित न करें क्योंकि वे गंदे लगते हैं। यदि दस्तावेज़ कहता है कि रिकॉर्ड `_spf.example.net` होना चाहिए, तो इसे वैसे ही रखें। छोटे फॉर्मेटिंग गलतियाँ लंबे दोपहर का कारण बनती हैं।

यहाँ एक उपयोगी आदत है: प्रेषक का नाम, होस्टनेम, रिकॉर्ड प्रकार, और गंतव्य स्ट्रिंग को एक तालिका में कैप्चर करें इससे पहले कि आप Cloudflare में लॉग इन करें। इससे संपादन चरण तेज़ हो जाता है, और यह गलत नाम फ़ील्ड में सही मान चिपकाने की सामान्य गलती को भी रोकता है।

3. Cloudflare DNS में एक SPF रिकॉर्ड जोड़ें

Cloudflare में, DNS खोलें और यदि आपका प्रदाता नग्न डोमेन से मेल भेजता है तो डोमेन की जड़ में TXT रिकॉर्ड बनाएं या संपादित करें। कुछ सेवाएँ इसके बजाय उपडोमेन का उपयोग करती हैं, जैसे `mail.example.com`, इसलिए उस होस्टनेम का उपयोग करें जो आपका प्रदाता निर्दिष्ट करता है, न कि वह जो आप मानते हैं। एक होस्टनेम। एक रिकॉर्ड।

एक SPF रिकॉर्ड आमतौर पर एक होस्टनाम के लिए केवल एक बार होना चाहिए। यही वह बिंदु है जो लोग चूक जाते हैं। यदि आपके पास पहले से एक SPF TXT रिकॉर्ड है, तो इसके बगल में दूसरा SPF TXT रिकॉर्ड न बनाएं। अधिकृत प्रेषकों को एकल स्ट्रिंग में मिलाएं ताकि प्राप्त करने वाला सर्वर एक नीति देखे, न कि दो प्रतिस्पर्धी उत्तर।

एक सामान्य SPF मान में `include:` या `ip4:` जैसे तंत्र शामिल होते हैं। यदि आपकी सेवा बाद में एक दूसरा प्रेषक जोड़ती है, तो एक और जोड़ने के बजाय मौजूदा रिकॉर्ड को अपडेट करें। एक डुप्लिकेट SPF रिकॉर्ड एक permerror का कारण बन सकता है, जिसका अर्थ है कि प्राप्त करने वाली प्रणालियाँ जांच को असफल मान सकती हैं, भले ही व्यक्तिगत भाग सही दिखें।

अपने प्रदाता द्वारा दिए गए रिकॉर्ड नाम का उपयोग करें। रूट डोमेन के लिए, Cloudflare अक्सर नाम क्षेत्र के रूप में `@` दिखाता है। एक उपडोमेन के लिए, उस सटीक लेबल को दर्ज करें। जब तक आपका प्रदाता आपको स्पष्ट रूप से ऐसा करने के लिए न कहे, तब तक मान के चारों ओर उद्धरण चिह्न न जोड़ें। Cloudflare पाठ को सामान्य DNS सामग्री के रूप में संग्रहीत करता है।

4. Cloudflare में DKIM TXT या CNAME रिकॉर्ड प्रकाशित करें

DKIM वह जगह है जहाँ चयनकर्ता महत्वपूर्ण होता है। प्रदाता आपको एक TXT रिकॉर्ड दे सकता है जैसे `selector1._domainkey` जिसमें एक लंबा सार्वजनिक कुंजी हो, या यह आपको एक CNAME रिकॉर्ड दे सकता है जो किसी अन्य होस्टनाम की ओर इशारा करता है। Cloudflare दोनों का समर्थन करता है, लेकिन प्रकार को प्रदाता द्वारा बताए गए अनुसार मेल खाना चाहिए। CNAME फ़ील्ड में एक TXT मान आपकी मदद नहीं करेगा।

कई सेवाएँ दो चयनकर्ताओं का उपयोग करती हैं। यह सामान्य है। Google Workspace अक्सर घुमाव के दौरान दो कुंजी का उपयोग करता है, और अन्य प्रदाता कुछ समान करते हैं ताकि एक कुंजी को बिना डिलीवरी में रुकावट डाले बदला जा सके। यदि प्रेषक आपको `s1` और `s2` देता है, तो दोनों रिकॉर्ड प्रकाशित करें। यदि एक दूसरा प्रेषक एक अलग चयनकर्ता परिवार का उपयोग करता है, तो उन रिकॉर्ड को भी अलग रखें। नाम दोहराए हुए लग सकते हैं; रिकॉर्ड अधिशेष नहीं हैं।

DKIM होस्टनाम को ठीक उसी तरह दर्ज करें जैसे दिया गया है। यदि प्रदाता आपको `selector1._domainkey.example.com` बनाने के लिए कहता है, तो Cloudflare में उस पूर्ण लेबल का उपयोग करें। यदि प्रदाता एक CNAME लक्ष्य देता है, तो गंतव्य को ठीक उसी तरह चिपकाएँ जैसे लिखा गया है। Cloudflare को अनुवाद की आवश्यकता नहीं है। इसे सटीकता की आवश्यकता है।

टीमों के लिए जो DKIM SPF DMARC सेटअप के लिए लेनदेनात्मक का पालन कर रही हैं, वही नियम लागू होता है जब मेल मात्रा छोटी हो: DNS में चयनकर्ता को संदेश हेडर में चयनकर्ता से मेल खाना चाहिए। यदि वे भिन्न होते हैं, तो DKIM विफल हो जाता है। कोई नाटक नहीं, बस विफलता।

5. _dmarc

पर एक DMARC रिकॉर्ड बनाएं

DMARC `_dmarc.yourdomain.com` पर होना चाहिए। Cloudflare में, उस सटीक नाम के साथ एक TXT रिकॉर्ड बनाएं। मान `v=DMARC1` से शुरू होता है, फिर आपकी नीति और वैकल्पिक टैग जोड़ता है। एक सामान्य प्रारंभिक नीति `p=none` है, क्योंकि यह आपको कुछ भी ब्लॉक करने से पहले रिपोर्ट एकत्र करने की अनुमति देती है। यह सबसे कम आक्रामक प्रारंभिक बिंदु है।

यदि आपकी संगठन रिपोर्ट प्राप्त करने के लिए तैयार है, तो समग्र रिपोर्टिंग पते के साथ `rua` टैग जोड़ें और, यदि आवश्यक हो, तो फोरेंसिक रिपोर्ट के लिए `ruf` टैग जोड़ें। एक ऐसा पता उपयोग करें जिसे कोई वास्तव में मॉनिटर करता हो। एक मृत मेलबॉक्स एक रणनीति नहीं है। यह एक जाल है।

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

Cloudflare DMARC TXT रिकॉर्ड को किसी अन्य टेक्स्ट प्रविष्टि की तरह संग्रहीत करेगा, लेकिन विवरण महत्वपूर्ण हैं। रिकॉर्ड नाम `_dmarc` होना चाहिए, `dmarc` नहीं, `_dmarc1` नहीं, और न ही रूट डोमेन। नीति स्ट्रिंग को उस सिंटैक्स का पालन करना चाहिए जिसकी आपके प्रदाता को अपेक्षा है। यदि आपका मेल प्लेटफ़ॉर्म `sp`, `adkim`, या `aspf` जैसे टैग का सुझाव देता है, तो उन्हें केवल तभी जोड़ें जब आप प्रभाव को समझते हों।

6. उन Cloudflare-विशिष्ट DNS सेटिंग्स की जांच करें जो मान्यता को रोक सकती हैं

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

रिकॉर्ड नाम एक और सामान्य विफलता बिंदु हैं। एक DKIM चयनकर्ता जो `selector1._domainkey` होना चाहिए, उसे `selector1._domainkey.` के रूप में एक बेतरतीब बिंदु के साथ या `selector1 domainkey` के रूप में एक स्थान के साथ दर्ज किया जा सकता है जो एक प्रदाता पृष्ठ से कॉपी किया गया है। Cloudflare कई DNS प्रविष्टियों को स्वीकार करता है, लेकिन प्राप्त करने वाली प्रणालियाँ इंटरफ़ेस की तुलना में कम सहिष्णु होती हैं।

पुराने रिकॉर्ड भी हस्तक्षेप कर सकते हैं। यदि एक पुराना SPF TXT रिकॉर्ड नए के बगल में रहता है, या यदि एक पुराना DKIM CNAME अभी भी एक सेवानिवृत्त सेवा की ओर इशारा करता है, तो मान्यता ऐसे तरीकों से विफल हो सकती है जो यादृच्छिक लगते हैं। मृत प्रविष्टि को केवल तब हटाएं जब आप पुष्टि करें कि इसकी अब आवश्यकता नहीं है। इससे सक्रिय प्रेषक सुरक्षित रहता है।

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

7. Cloudflare-प्रबंधित DNS से प्रसार और मेल प्रमाणीकरण की पुष्टि करें

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

फिर उस सेवा से एक वास्तविक परीक्षण संदेश भेजें जो रिकॉर्ड का उपयोग करती है। अपने सामान्य मेल प्रवाह को बायपास करने वाले किसी यादृच्छिक इनबॉक्स से परीक्षण न करें। प्राप्त करने वाले मेलबॉक्स में संदेश हेडर खोलें और SPF पास, DKIM पास, और DMARC संरेखण पास की तलाश करें। संदेश अन्य कारणों से स्पैम में जा सकता है, लेकिन प्रमाणीकरण परिणाम आपको बताएगा कि DNS पक्ष सही है या नहीं।

पहले पास के लिए एक त्वरित जांच पर्याप्त है, लेकिन एक अलग मेलबॉक्स से दूसरी जांच आपको बेहतर संकेत देती है। यदि एक रिसोल्वर पुराने रिकॉर्ड को संक्षेप में देखता है जबकि दूसरा नए को देखता है, तो Gmail परीक्षण और Microsoft 365 परीक्षण अलग-अलग व्यवहार कर सकते हैं। यह असामान्य नहीं है। यह होता है।

यदि डिलीवरबिलिटी उसी परियोजना का हिस्सा है, तो इस काम को ईमेल डिलीवरबिलिटी सर्वोत्तम प्रथाओं के साथ जोड़ें। प्रमाणीकरण पूरी कहानी नहीं है, लेकिन यह वह हिस्सा है जो रिसीवर्स को यह तय करने देता है कि आपका डोमेन अपने लिए बोल रहा है या नहीं।

8. जब आपका मेल प्रदाता बदलता है तो रिकॉर्ड अपडेट करें

मेल सेटअप बदलते हैं। एक प्रदाता DKIM कुंजियों को घुमाता है, एक मार्केटिंग प्लेटफॉर्म जोड़ा जाता है, या एक लेनदेन सेवा माइग्रेशन के बाद स्थानांतरित की जाती है। जब ऐसा होता है, तो ट्रैफ़िक स्विच करने से पहले Cloudflare में DNS रिकॉर्ड अपडेट करें, न कि बाद में। यह क्रम आपको टूटे हुए हस्ताक्षरों के एक दिन से बचाता है।

DKIM घुमाव आमतौर पर सबसे साफ बदलाव होता है। प्रदाता आपको एक नया चयनकर्ता और कुंजी देता है, आप इसे Cloudflare में प्रकाशित करते हैं, और आप पुराने को रिटायर करने से पहले नए चयनकर्ता के मान्य होने की प्रतीक्षा करते हैं। यदि प्रदाता इसका समर्थन करता है तो संक्रमण के दौरान दोनों को सक्रिय रखें। दो चयनकर्ता एक आउटेज से आसान होते हैं।

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

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

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

रिकॉर्ड प्रकार	Cloudflare में यह कहाँ जाता है	सामान्य प्रदाता इनपुट	पर ध्यान दें
SPF TXT	रूट डोमेन या भेजने वाला उपडोमेन	मैकेनिज्म, आईपी और प्रेषक सूची शामिल करें	डुप्लिकेट SPF रिकॉर्ड
DKIM TXT या CNAME	चयनकर्ता आधारित होस्टनेम	चुनावकर्ता का नाम और सार्वजनिक कुंजी या लक्षित होस्टनाम	गलत रिकॉर्ड प्रकार
DMARC TXT	_dmarc.hostname	नीति स्ट्रिंग और रिपोर्टिंग टैग	गलत रिकॉर्ड नाम

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