सर्वर और एप्लिकेशन द्वारा इन्वेंटरी डोमेन
सर्वर या उप-खाते के लिए सॉकेटलैब्स प्रमाणीकरण की समीक्षा की जानी चाहिए जो वास्तव में संदेश भेजता है। प्रत्येक एप्लिकेशन द्वारा उपयोग किए जाने वाले डोमेन और सॉकेटलैब्स कॉन्फ़िगरेशन से दृश्यमान एप्लिकेशन की सूची से प्रारंभ करें। उपडोमेन, ग्राहक ब्रांड और फ़ॉलबैक मार्गों से अलग शामिल करें। एक कार्यशील ब्रांड एक सर्वर के लिए अपर्याप्त साक्ष्य है जो कई संगठनों की ओर से भेजता है।
जब किसी पते की अनुमति नहीं होती है तो प्रदाता को सत्यापित भेजने वाले डोमेन और दस्तावेज़ों में त्रुटि की आवश्यकता होती है। यह पता-पुष्टि प्रक्रिया या योग्य DNS प्रमाणीकरण सुविधाओं के माध्यम से स्वामित्व सत्यापन का समर्थन करता है, जबकि यह ध्यान में रखता है कि खाता कॉन्फ़िगरेशन और योजना भेजने-डोमेन नियंत्रण के अनुप्रयोग को प्रभावित करती है। सॉकेटलैब्स डोमेन भेज रहा है, भेजने वाले डोमेन को जोड़ रहा है और सत्यापित कर रहा है.
रिसीवर पर प्रमाणीकरण से सबमिट करने की अलग अनुमति। किसी डोमेन को वांछित ग्राहक-डोमेन के बिना भेजने की अनुमति दी जा सकती है DKIM या लिफाफा पहचान का उपयोग किया जा रहा है। इन्हें स्वतंत्र जांच के रूप में रिकॉर्ड करें और किसी ग्राहक या भागीदार की पहचान को अधिकृत करने से पहले डोमेन मालिक की अनुमति प्राप्त करें।
कुंजी स्वामी के साथ DKIM विधि चुनें
सॉकेटलैब्स तीन तरीकों का दस्तावेजीकरण करता है: एक ग्राहक द्वारा प्रदत्त TXT कुंजी, एक प्रदाता-जनित TXT कुंजी, और एक प्रदाता-प्रबंधित CNAME. यह विकल्प बदल जाता है कि कुंजियों को कौन प्रबंधित करता है और उन्हें सर्वर पर कैसे बनाए रखा जाता है। इसका वर्तमान अवलोकन कहता है कि हस्ताक्षर करने के लिए प्रेषक पहचान के साथ मिलान की आवश्यकता होती है। सॉकेटलैब्स DKIM सिंहावलोकन, तीन हस्ताक्षर विधियां.
DNS कार्य प्रारंभ होने से पहले निर्णय रिकॉर्ड करें. प्रदाता-प्रबंधित विधि के लिए, पहचानें कि हस्ताक्षर कॉन्फ़िगरेशन को कौन बदल सकता है। ग्राहक-नियंत्रित पद्धति के लिए, निजी-कुंजी संरक्षक और अनुमोदित रोटेशन प्रक्रिया की पहचान करें। कुंजियों से भरी स्प्रेडशीट एक स्वीकार्य स्वामित्व रिकॉर्ड नहीं है। वर्कशीट में साक्ष्य संदर्भ और जिम्मेदार व्यक्ति होना चाहिए, गुप्त सामग्री नहीं।
स्वचालित रूप से सबसे जटिल विधि का चयन न करें क्योंकि यह अधिक नियंत्रणों को उजागर करता है। समर्थित दृष्टिकोण को प्राथमिकता दें जो संगठन की आवश्यकताओं को पूरा करता हो और उसके वास्तविक ऑपरेटरों द्वारा बनाए रखा जा सके। यदि नीति के लिए किसी विशेष कुंजी-प्रबंधन व्यवस्था या असामान्य हस्ताक्षर पहचान की आवश्यकता होती है, तो कॉन्फ़िगरेशन को समर्थित के रूप में प्रस्तुत करने से पहले प्रदाता की पुष्टि प्राप्त करें।
चयनित हस्ताक्षर विधि कॉन्फ़िगर करें
CNAME हस्ताक्षर के लिए, आधिकारिक मार्गदर्शिका सुविधा को सक्षम करने से पहले एक प्रत्यायोजित DNS रिकॉर्ड और खाता-पक्ष सत्यापन का वर्णन करती है। CNAME गाइड dkim को सूचीबद्ध करता है। भेजने वाले डोमेन के अंतर्गत _domainkey dkim._domainkey.email-od.com की ओर इशारा करता है। उस सार्वजनिक प्रलेखित जोड़ी की तुलना चालू खाता निर्देशों से करें; किसी अधिगृहीत को अधिलेखित न करें चयनकर्ता केवल इसलिए कि उदाहरण इसके नाम से मेल खाता है। यदि DNS होस्ट CNAME स्वामी में आवश्यक अंडरस्कोर का समर्थन नहीं कर सकता है, तो मार्गदर्शिका उपयोगकर्ताओं को आविष्कारित वर्तनी के बजाय TXT दृष्टिकोण की ओर निर्देशित करती है। सॉकेटलैब्स CNAME हस्ताक्षर गाइड.
जांचें कि क्या इच्छित चयनकर्ता स्वामी पहले से ही किसी अन्य सेवा द्वारा उपयोग किया जा रहा है। किसी CNAME किसी असंबद्ध चयनकर्ता पर सुरक्षित रूप से चिपकाया नहीं जा सकता। इसके बजाय किसी समर्थित विकल्प या स्वीकृत माइग्रेशन का अनुरोध करें। कार्यान्वयन टिकट में मौजूदा रिकॉर्ड, उस पर निर्भर सेवाओं और परिवर्तन निर्णय को सुरक्षित रखें।
TXT गाइड प्लेटफ़ॉर्म में कुंजी उत्पन्न करने को कुंजी जोड़ी लाने से अलग करता है। इसके लिए DNS में सार्वजनिक कुंजी की आवश्यकता होती है और प्रासंगिक सेटिंग्स को सहेजने से पहले उस कुंजी को सत्यापित किया जाता है। जनरेट किया गया कुंजी प्रवाह अपने निजी घटक को खाते में रखता है। सॉकेटलैब्स TXT साइनिंग गाइड.
यदि चयनित विधि में निजी सामग्री आयात करना शामिल है तो अनुमोदित गुप्त-हैंडलिंग वर्कफ़्लो का उपयोग करें। केवल सार्वजनिक कुंजी प्रकाशित करें. सटीक डोमेन और चयनकर्ता को रिकॉर्ड करें और किसी भी DNS-संपादक स्ट्रिंग विभाजन के बाद परिणामी तार्किक TXT मान का निरीक्षण करें। जनरेट की गई कुंजी मार्गदर्शिका कहती है कि सफल DNS प्रकाशन और बचत के बाद सार्वजनिक कुंजी अब पोर्टल में उपलब्ध नहीं है। समीक्षा बंडल में निजी कुंजी को बनाए रखे बिना, सेटअप टिकट को बंद करने से पहले सार्वजनिक रिकॉर्ड और उसकी उत्पत्ति को सुरक्षित रखें।
बाउंस डोमेन को एक अलग मैपिंग के रूप में कॉन्फ़िगर करें
सॉकेटलैब्स ग्राहक-डोमेन लागू करता है SPF अपने कस्टम बाउंस-डोमेन मॉडल के माध्यम से मौजूदा दृश्यमान-से जोड़ने की आवश्यकता के बिना SPF रिकॉर्ड. इसकी मार्गदर्शिका चयनित बाउंस उपडोमेन से tracking.socketlabs.com तक एक CNAME निर्दिष्ट करती है। एकाधिक बाउंस प्रविष्टियाँ कॉन्फ़िगर की जा सकती हैं; बेजोड़ मेल चयनित डिफ़ॉल्ट या प्रदाता फ़ॉलबैक का उपयोग करता है। सॉकेटलैब्स कस्टम बाउंस गाइड, सेटअप और मल्टीपल कस्टम बाउंस डोमेन.
DNS व्यवस्थापक के साथ एक अप्रयुक्त नाम चुनें और वास्तविक सर्वर में समर्थित मैपिंग की पुष्टि करें। डोमेन के सामान्य इनबाउंड-मेल कॉन्फ़िगरेशन को बरकरार रखें। बाउंस होस्टनाम एक एप्लिकेशन डिलीवरी पहचान है और इसे उपयोगकर्ता के उत्तर मेलबॉक्स या वेबसाइट के ट्रैकिंग एंडपॉइंट के साथ भ्रमित नहीं किया जाना चाहिए।
प्रत्येक फ्रॉम डोमेन के लिए इच्छित मिलान रिकॉर्ड करें, फिर डिफ़ॉल्ट व्यवहार रिकॉर्ड करें। मल्टी-ब्रांड सर्वर पर डिफ़ॉल्ट स्पष्ट व्यावसायिक समीक्षा के लायक हैं: सफल डिलीवरी अभी भी एक अप्रत्याशित ब्रांड या प्रदाता पहचान को उजागर कर सकती है। अकेले कॉन्फ़िगरेशन में नामों से सक्रिय मैपिंग का अनुमान न लगाएं। उत्सर्जित Return-Path बाद में तुलना करने का प्रमाण है।
सार्वजनिक रिकॉर्ड प्रकाशित करें और तुलना करें
स्वीकृत परिवर्तन करने से पहले प्रासंगिक DNS रिकॉर्ड निर्यात करें। आधिकारिक सेवा और DNS संपादक द्वारा संबंधित नामों को संभालने की पुष्टि करें। प्रत्येक प्रकाशित स्वामी का स्वतंत्र रूप से निरीक्षण करें, जिसमें उसकी CNAME श्रृंखला या TXT उत्तर भी शामिल है। एक सही DKIM रिकॉर्ड यह साबित नहीं करता है कि बाउंस नाम कॉन्फ़िगर किया गया है, और एक सही बाउंस रिकॉर्ड यह साबित नहीं करता है कि DKIM हस्ताक्षर सक्रिय है।
SPF मूल्यांकन SMTP लिफाफा पहचान का उपयोग करके किया जाता है, न कि केवल दृश्यमान से। यदि किसी अन्य सेवा को अभी भी रूट डोमेन की SPF नीति की आवश्यकता है, तो उसे सुरक्षित रखें। किसी भी मालिक के लिए जहां SPF नीति की आवश्यकता है, एक नीति बनाए रखें और प्रोटोकॉल की डीएनएस-क्वेरी अवधि सीमा की जांच करें। RFC 7208 , अनुभाग 2.4, 4.5 और 4.6.4.
जहां कैश शामिल है, वहां लगातार आधिकारिक और पुनरावर्ती उत्तरों की प्रतीक्षा करें। यदि प्रदाता सत्यापित नहीं कर सकता एक अभिलिखित, नाम को बार-बार बदलने के बजाय समर्थन के लिए जारी मूल्य और समयबद्ध DNS अवलोकनों को सहेजें। DNS-होस्ट सीमा को दस्तावेज़ समर्थित विधि के माध्यम से नियंत्रित किया जाना चाहिए।
डोमेन और बाउंस मैच से प्रत्येक सटीक परीक्षण करें
नियंत्रित बाहरी प्राप्तकर्ताओं को प्रत्येक सामग्री एप्लिकेशन और सर्वर के माध्यम से हानिरहित सामग्री भेजें। समय, संदेश-आईडी और प्रदाता या एप्लिकेशन ईवेंट संदर्भ सुरक्षित रखें। मूल डोमेन के लिए एक प्रविष्टि मानने के बजाय उपडोमेन से अलग से परीक्षण करें, जो उन्हें कवर करता है।
पुराना CNAME पृष्ठ अपने प्रयोज्यता विवरण में PRA और प्रेषक का उल्लेख करता है, जबकि वर्तमान अवलोकन और TXT पृष्ठ सटीक मेल का वर्णन करता है। यदि एप्लिकेशन एक अलग प्रेषक हेडर या अन्य असामान्य पहचान का उपयोग करता है, तो स्पष्टीकरण प्राप्त करें और उस सटीक फॉर्म का परीक्षण करें। उन भिन्न कथनों को चुपचाप एक सार्वभौमिक नियम में परिवर्तित न करें।
प्राप्तकर्ता पर, दृश्यमान रिकॉर्ड, Return-Path , विश्वसनीय SPF पहचान और परिणाम, प्रत्येक DKIM डी और एस, और DMARC परिणाम। DKIM सत्यापन सार्वजनिक कुंजी का पता लगाने के लिए वास्तविक हस्ताक्षर में डोमेन और चयनकर्ता का उपयोग करता है। RFC 6376 , धारा 3.5 और 6.1.
प्रत्येक गुजरती पहचान की तुलना लागू के अंतर्गत दृश्यमान से करें संरेखण तरीका। एक कस्टम बाउंस उपडोमेन सख्त समानता को पूरा किए बिना आरामदेह SPF संरेखण को पूरा कर सकता है। एक संरेखित गुजर DKIM हस्ताक्षर DMARC स्वतंत्र रूप से संतुष्ट कर सकता है। संपूर्ण परिणाम का अनुमान लगाने के लिए न तो सफल डोमेन सत्यापन और न ही प्रदाता-डोमेन प्रमाणीकरण पास पर्याप्त है। RFC 9989 , पहचानकर्ता संरेखण की व्याख्या और DMARC मूल्यांकन.
असफल परत का निदान करें
प्रेषक-अनुमत त्रुटि के लिए, DNS कुंजी बदलने से पहले सत्यापन और सही सर्वर के डोमेन नियंत्रण का निरीक्षण करें। किसी अप्रत्याशित हस्ताक्षरित डोमेन के लिए, कॉन्फ़िगर की गई DKIM प्रविष्टि के साथ सटीक की तुलना करें। अप्रत्याशित Return-Path के लिए, बाउंस मैच और डिफ़ॉल्ट का निरीक्षण करें। इन जांचों को अलग-अलग रखें ताकि एक की मरम्मत से दूसरे की समस्या न छुप जाए।
यदि सही DNS के बावजूद क्रिप्टोग्राफ़िक सत्यापन विफल हो जाता है, तो पथ पर हस्ताक्षरित सामग्री या हेडर में परिवर्तनों की जांच करें। यदि प्रमाणीकरण और संरेखण पास हो जाता है लेकिन इनबॉक्स प्लेसमेंट खराब है, तो प्राप्तकर्ता की फ़िल्टरिंग, प्रतिष्ठा और संदेश के उद्देश्य की जांच करें। प्रमाणीकरण डिलीवरी का वादा नहीं करता है या अधिकृत खाते के हर उपयोग को वैध नहीं बनाता है।
रिलीज़ से पहले रिकॉर्ड पुनर्प्राप्ति
सॉकेटलैब्स डोमेन और सर्वर वर्कशीट को पूरा करें (यहां वर्णित फ़ील्ड के साथ एक अलग समीक्षा रिकॉर्ड बनाएं)। अनुमति, हस्ताक्षर करने की विधि, बाउंस मैपिंग और प्राप्त साक्ष्य का रूट-दर-रूट मैट्रिक्स बनाए रखें। पहचानें कि परीक्षण विफल होने पर कौन एप्लिकेशन को रोक सकता है या पहले से स्वीकृत सर्वर कॉन्फ़िगरेशन को पुनर्स्थापित कर सकता है।
पुरानी सार्वजनिक कुंजियाँ न हटाएँ या रिकॉर्ड बाउंस न करें जबकि पंक्तिबद्ध संदेश या अन्य सर्वर उन पर निर्भर हों। एप्लिकेशन स्वामी के साथ सेवानिवृत्ति की योजना बनाएं और डोमेन, सर्वर, कुंजी विधि, बाउंस डिफ़ॉल्ट या DNS प्रदाता में परिवर्तन के बाद पुनः परीक्षण करें।
डिफ़ॉल्ट बाउंस प्रविष्टि से जुड़ा काल्पनिक निदान मामला
केवल काल्पनिक लिखित मामला: SOCK-01 मानता है कि एक सर्वर से news@alpha.example लिफाफा bounces.alpha.example और एक उत्तीर्ण SPF परिणाम के साथ भेजता है। दूसरा मार्ग from news@beta.example का उपयोग करता है लेकिन वापस bounces.alpha.example example पर आ जाता है, वह भी SPF पास के साथ। शिथिल संरेखण के तहत पहला निर्धारित लिफाफा संरेखित होता है; दूसरा नहीं. दोनों DKIM परिणाम अज्ञात हैं, इसलिए न तो पूर्ण दूसरे संदेश की विफलता और न ही सफल मरम्मत का दावा किया गया है। सर्वर स्वामी को बीटा की मैपिंग को स्वीकृत और सत्यापित करना होगा, फिर उसके उत्सर्जित Return-Path और DKIM निरीक्षण करना होगा। कोई सर्वर, DNS या संदेश परीक्षण नहीं किया गया.
स्वीकृति लंबित है
जब इच्छित सर्वर डोमेन को अनुमति देता है तो रूट स्वीकार करें, चयनित हस्ताक्षर विधि सत्यापित करती है, प्रत्येक बाउंस मैपिंग स्वीकृत के रूप में व्यवहार करती है और प्राप्तकर्ता साक्ष्य आवश्यक संरेखित पास स्थापित करता है। इस अप्रकाशित मसौदे के लिए मूल-दायरे की स्वीकृति, लाइव किरायेदार और DNS जांच, स्वतंत्र तकनीकी समीक्षा, दृश्य समीक्षा और मानव एसएमई अनुमोदन लंबित हैं।
पारित संदेश को प्रवर्तन तत्परता से अलग करें
RFC 9989 धारा 7.4 को डोमेन प्रकाशन के लिए वैध DKIM आवश्यकता है p=reject और अप्रत्यक्ष-मेल अंतरसंचालनीयता के बारे में सावधान करता है। एक एकल संरेखित SPF परिणाम अपने आप में अस्वीकार-नीति रोलआउट को उचित नहीं ठहराता है। इस प्रदाता सेटअप से सभी वैध मार्गों और नीति स्वामित्व की अलग से समीक्षा करें।