सेंडलूप प्रमाणीकरण कॉन्फ़िगर करें और वास्तविक भेजने वाली पहचान सत्यापित करें

आरंभिक बिंदु के रूप में खाता कॉन्फ़िगरेशन का उपयोग करें

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

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

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

प्रेषक डोमेन नियंत्रण कक्ष खोलें

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

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

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

असंबद्ध अनुमतियों का विस्तार किए बिना SPF समीक्षा करें

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

किसी भी मालिक के बदले जाने पर, एक ही SPF नीति बनाए रखें और अन्य सक्रिय प्रेषकों द्वारा आवश्यक प्राधिकरणों को सुरक्षित रखें। नए शब्द जोड़ने से पहले नेस्टेड DNS लुकअप की समीक्षा करें। SPF की दस-अवधि की सीमा उन तंत्रों और संशोधकों पर लागू होती है जो मूल्यांकन के दौरान DNS लुकअप का कारण बनते हैं, रिकॉर्ड में दिखाई देने वाले शब्दों की संख्या पर नहीं। मौजूदा अनुमेय तंत्र भी समीक्षा के लायक हैं, लेकिन उन्हें हटाना एक अलग निर्भरता निर्णय है। RFC 7208 , अनुभाग 4.5 और 4.6.4.

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

केवल जारी सार्वजनिक DKIM सामग्री ही प्रकाशित करें

इस खाते के लिए दिए गए स्वामी और सार्वजनिक मूल्य का उपयोग करें। सार्वजनिक मार्गदर्शिका DKIM TXT सेटअप दिखाती है, लेकिन इसकी प्रदर्शन कुंजी ग्राहक की कुंजी नहीं है। यदि पैनल या समर्थन एक अलग समर्थित रिकॉर्ड फॉर्म प्रदान करता है, तो बिना सबूत के इसे परिवर्तित करने के बजाय उस निर्देश को बनाए रखें। सेंडलूप गाइड, DKIM रिकॉर्ड सेट करें.

DNS में केवल सार्वजनिक सत्यापन कुंजी शामिल है। DKIM एक निजी कुंजी के साथ एक क्रिप्टोग्राफ़िक हस्ताक्षर बनाता है; यह निजी कुंजी को आउटगोइंग संदेश में एम्बेड नहीं करता है। सार्वजनिक गाइड की अनौपचारिक व्याख्या को हस्ताक्षर संबंधी रहस्य साझा करने के अनुरोध के रूप में नहीं पढ़ा जाना चाहिए। संदेश में एक हस्ताक्षर होता है, और सत्यापनकर्ता अपने हस्ताक्षर डोमेन द्वारा पहचानी गई सार्वजनिक कुंजी का उपयोग करता है चयनकर्ता. RFC 6376 , धारा 3.5 और 6.1.

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

संरेखण निष्कर्ष के बाहर लिंक ब्रांडिंग रखें

प्रदाता की मार्गदर्शिका एक वैकल्पिक का वर्णन करती है CNAME उपनामित संदेश लिंक के लिए. इसका उद्देश्य लिंक ब्रांडिंग है, न कि सबूत कि SPF या DKIM संरेखित है। इसे केवल तभी लागू करें जब प्रासंगिक ट्रैकिंग परिवर्तन स्वीकृत हो और खाता सटीक लक्ष्य प्रदान करता हो। सेंडलूप गाइड, वैकल्पिक: CNAME रिकॉर्ड सेट करें.

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

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

प्राप्त संदेश पहचान रिकॉर्ड एकत्र करें

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

साक्ष्य रिकॉर्ड में दृश्यमान डोमेन, प्रमाणित लिफाफा पहचान शामिल होनी चाहिए। Return-Path, DKIM d= और s= मान, SPF और DKIM परिणाम और रिसीवर का DMARC परिणाम। स्थापित करें कि कौन सा पासिंग तंत्र फ्रॉम डोमेन के साथ संरेखित है। शिथिल और सख्त संरेखण विभिन्न डोमेन तुलनाएँ लागू करता है; उपयोग में आने वाले मोड को रिकॉर्ड करें. RFC 9989 , पहचानकर्ता संरेखण समझाया गया.

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

अगले चेक का चयन करने के लिए विफलता का उपयोग करें

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

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

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

वर्कशीट पुनर्प्राप्ति और स्वीकृति

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

यदि परिवर्तन विफल हो जाता है, तो प्रभावित प्रेषण को रोकें और रिकॉर्ड किए गए परिवर्तन योजना के माध्यम से पहले से स्वीकृत कॉन्फ़िगरेशन को पुनर्स्थापित करें। प्रदाता सक्रियण के साथ DKIM परिवर्तनों का समन्वय करें; सार्वजनिक कुंजी को हटाना, जबकि सेवा अभी भी इसके साथ हस्ताक्षर कर रही है, एक नई विफलता उत्पन्न करती है। सेंडलूप को रिटायर करते समय, पुष्टि करें कि सभी अभियान और ऑटोमेशन बंद हो गए हैं और ट्रस्ट या ट्रैकिंग रिकॉर्ड को हटाने से पहले साझा SPF निर्भरता की समीक्षा करें।

SPF विसंगति का काल्पनिक उदाहरण

केवल काल्पनिक लिखित मामला: SLP-01 का उद्देश्य offers@workshop.example से है। सार्वजनिक उदाहरण में दो प्रदाता शामिल हैं जबकि इसके मौजूदा-नीति निर्देश में एक का नाम शामिल है; चालू खाता प्राधिकरण, लिफाफा पहचान और DKIM / SPF परिणाम अज्ञात हैं। DNS स्वामी परिवर्तन रखता है और खाता स्वामी से मार्ग-विशिष्ट पुष्टिकरण प्राप्त करने के लिए कहता है। एक टेक्स्ट फ़ाइल और एक ब्रांडेड लिंक प्रमाणीकरण स्थापित नहीं करते हैं। स्पष्टीकरण के बाद, टीम एक नीति की समीक्षा करेगी और एक नियंत्रित अभियान संदेश एकत्र करेगी। कोई खाता, DNS या भेजने का परीक्षण निष्पादित नहीं किया गया था।

वृत्तचित्र कवरेज और शेष द्वार

यह ड्राफ्ट सार्वजनिक खाता वर्कफ़्लो और सुरक्षित सत्यापन को कवर करता है। यह एक सार्वभौमिक समर्पित-डीकेआईएम या कस्टम Return-Path सेटअप स्थापित नहीं करता है, और यह दावा नहीं करता है कि लाइव संरेखित सेंडलूप संदेश का निरीक्षण किया गया है। वे खाता-निर्भर विवरण, लाइव DNS और हेडर साक्ष्य, स्वतंत्र समीक्षा, दृश्य समीक्षा और मानव एसएमई अनुमोदन लंबित हैं। मूल पूर्ण कार्यान्वयन के दायरे को तब तक रोक कर रखें जब तक कि आवश्यक खाता साक्ष्य कमियों को पूरा न कर दे।

पारित संदेश को प्रवर्तन तत्परता से अलग करें

RFC 9989 धारा 7.4 को डोमेन प्रकाशन के लिए वैध DKIM आवश्यकता है p=reject और अप्रत्यक्ष-मेल अंतरसंचालनीयता के बारे में सावधान करता है। एक एकल संरेखित SPF परिणाम अपने आप में अस्वीकार-नीति रोलआउट को उचित नहीं ठहराता है। इस प्रदाता सेटअप से सभी वैध मार्गों और नीति स्वामित्व की अलग से समीक्षा करें।