मेलबॉक्स माइग्रेशन को प्रमाणीकरण से अलग करें
Proton Mail , जिसे पहले आमतौर पर प्रोटॉनमेल कहा जाता था, सशुल्क योजनाओं पर कस्टम-डोमेन पते का समर्थन करता है। इसका कस्टम-डोमेन गाइड डोमेन सत्यापन, पता निर्माण, MX परिवर्तन और प्रमाणीकरण को अलग करता है। इन्हें विशिष्ट स्वीकृति मदों के रूप में योजनाबद्ध करें। नए मेलबॉक्स पर एक संदेश प्राप्त करना यह साबित नहीं करता है कि आउटगोइंग मेल में इच्छित हस्ताक्षर हैं, और a DKIM जाँच यह साबित नहीं करती कि प्रत्येक व्यावसायिक पता माइग्रेशन के बाद मौजूद है।
एक पता सूची से प्रारंभ करें: व्यक्तिगत उपयोगकर्ता, उपनाम, साझा व्यावसायिक गंतव्य, स्वचालित प्रेषक और उत्तर पते। किसी भी ऐसी सेवा की पहचान करें जो प्रोटॉन से गुजरे बिना उसी डोमेन का उपयोग करके भेजती है। जहां व्यावहारिक हो वहां एक व्यक्ति को मेलबॉक्स कटओवर और दूसरे को DNS समीक्षा करने के लिए नियुक्त करें। मौजूदा MX और प्रमाणीकरण रिकॉर्ड, स्वीकृत परिवर्तन विंडो और निर्णय लेने वाले को रिकॉर्ड करें जो कटओवर को रोक सकता है।
प्रोटॉन विशेष रूप से आगे बढ़ने से पहले संबंधित पते बनाने की सलाह देता है MX रिकॉर्ड. यह मायने रखता है क्योंकि इनबाउंड रूटिंग बदल जाने के बाद गुम पते के संदेश पिछली सेवा तक नहीं पहुंचेंगे। उपयोग प्रवास क्रम खाते के लिए, और प्राप्तकर्ता पक्ष को पूर्ण घोषित करने से पहले नियंत्रित संदेशों के साथ महत्वपूर्ण गंतव्यों को सत्यापित करें।
सटीक डोमेन और जारी किए गए मान रिकॉर्ड करें
प्रोटॉन की डोमेन सेटिंग्स में इच्छित डोमेन खोलें और इसके लिए प्रदर्शित प्रमाणीकरण निर्देश बनाए रखें। डोमेन-स्वामित्व सत्यापन रिकॉर्ड को अलग करें SPF, DKIM और DMARC. वे अलग-अलग सवालों के जवाब देते हैं और उनके पास अलग-अलग साक्ष्य क्षेत्र होने चाहिए। खाते में मूल्यों के स्थान पर कभी भी किसी अन्य संगठन के प्रकाशित रिकॉर्ड को प्रतिस्थापित न करें।
DNS व्यवस्थापक को प्रत्येक प्रविष्टि के लिए पूर्ण स्वामी का नाम, रिकॉर्ड प्रकार और अपेक्षित मान रिकॉर्ड करना चाहिए। इनकी तुलना DNS संपादक के प्रत्यय प्रबंधन से करें, फिर प्रकाशित उत्तरों का निरीक्षण करें। एक लेबल नियंत्रण कक्ष में दृष्टिगत रूप से सही हो सकता है लेकिन गलत पूर्णतः योग्य नाम पर दिखाई देता है। असंबंधित रखें TXT रिकॉर्ड और परिवर्तन करने से पहले प्रस्तावित DKIM स्वामियों के किसी भी मौजूदा उपयोग को रिकॉर्ड करें।
यदि डोमेन पहले से ही CRM, वेबसाइट या बिलिंग सिस्टम द्वारा उपयोग किया जा रहा है, तो उन प्रेषकों को अभी सूचीबद्ध करें। स्टाफ मेल को प्रोटॉन में ले जाना किसी अलग एप्लिकेशन की सीधी डिलीवरी को प्रमाणित नहीं करता है। या तो उस एप्लिकेशन के स्वीकृत रूट का अपना वैध प्रमाणीकरण होना चाहिए या स्पष्ट रूप से डिज़ाइन किया गया सबमिशन रूट लागू और परीक्षण किया जाना चाहिए। अनिश्चित प्रेषकों को इन्वेंट्री अंतराल के रूप में मानें, न कि डोमेन की नीति को तुरंत कमजोर करने का कारण।
एक सुसंगत SPF नीति बनाए रखें
प्रोटोन का स्पूफ़िंग विरोधी दस्तावेज़ीकरण include:_spf.protonmail.ch इसके SPF प्राधिकरण के रूप में पहचानता है और इसे मौजूदा नीति में शामिल करने की व्याख्या करता है। अंतिम मूल्य तैयार करने के लिए खाते के अनुशंसित रिकॉर्ड और डोमेन की संपूर्ण प्रेषक सूची का उपयोग करें। माइग्रेशन के दौरान एक ही मालिक के लिए दूसरी नीति प्रकाशित न करें या किसी अन्य वैध मार्ग के लिए प्राधिकरण को न छोड़ें।
के विरुद्ध संपूर्ण नीति का मूल्यांकन करें SPF के डीएनएस-लुकअप नियम. कॉपी किए गए उदाहरण को संगठन-व्यापी नीति निर्णय के रूप में मानने के बजाय जानबूझकर अंतिम क्वालीफायर चुनें। SPF परिणाम प्रमाणीकरण साक्ष्य है; प्राप्त करने वाली प्रणालियाँ अपने स्वयं के प्रबंधन निर्णय लेती हैं। पिछली नीति को स्वीकृत पुनर्प्राप्ति परिवर्तन के लिए उपलब्ध रखें और नोट करें कि कैश्ड संस्करण अभी भी उपयोग में हो सकते हैं।
संपूर्ण DKIM रोटेशन सेटअप रखें
प्रोटॉन तीन का उपयोग करता है CNAME स्वचालित DKIM रोटेशन के लिए रिकॉर्ड। इसका डोमेन प्रमाणीकरण मार्गदर्शिका ग्राहकों को इन तीनों को रखने, विज़ार्ड से सटीक मिलान करने और आउटगोइंग कस्टम-डोमेन साइनिंग शुरू होने से पहले पता लगने की प्रतीक्षा करने का निर्देश देता है। जाहिरा तौर पर निष्क्रिय चयनकर्ता बाद के रोटेशन के लिए इसकी आवश्यकता हो सकती है। इसे न हटाएं क्योंकि एक एकल परीक्षण संदेश केवल एक हस्ताक्षर चयनकर्ता का उपयोग करता है।
यदि सत्यापन विफल हो जाता है, तो प्रत्येक स्वामी और लक्ष्य चरित्र की तुलना करें। प्रोटोन का CNAME समस्या निवारण मार्गदर्शिका संभावित समस्याओं के रूप में गलत मानों, पिछली अवधि के रजिस्ट्रार प्रबंधन और पुराने मैन्युअल रूप से प्रबंधित TXT रिकॉर्ड की पहचान करता है। कुछ भी हटाने से पहले वास्तविक विरोध की जांच करें। किसी भिन्न चयनकर्ता पर TXT रिकॉर्ड किसी अन्य वैध प्रेषक का हो सकता है और स्वचालित रूप से अप्रचलित नहीं होता है।
जहां खाता प्रोटॉन की पुरानी मैनुअल-कुंजी व्यवस्था से आगे बढ़ रहा है, वहां दस्तावेजी परिवर्तन की सावधानीपूर्वक योजना बनाएं। जब पुराना TXT रिकॉर्ड हटा दिया जाता है तो प्रोटॉन हस्ताक्षर में रुकावट की चेतावनी देता है। सभी प्रतिस्थापन मान और एक नियंत्रित परीक्षण पहले से तैयार करें, परिवर्तन विंडो का समन्वय करें और आवश्यक प्रतिस्थापन को तुरंत प्रकाशित करें। यह ज़ोन के प्रत्येक DKIM TXT रिकॉर्ड को हटाने की अनुशंसा नहीं है।
टेस्ट स्टाफ मेल और आवेदन जमा करना अलग से
संगठन द्वारा उपयोग किए जाने वाले मार्गों के माध्यम से प्रतिनिधि कस्टम-डोमेन पतों से ताज़ा संदेश भेजें। ग्राहक या एप्लिकेशन को पते, समय और संदेश-आईडी से रिकॉर्ड करें। नियंत्रित बाहरी रिसीवर पर, विश्वसनीय SPF , DKIM और DMARC परिणाम, SMTP कैप्चर करें वापसी का पथ और DKIM d= और s= मान। हस्ताक्षर का डोमेन और चयनकर्ता द्वारा वर्णित सार्वजनिक-कुंजी लुकअप की पहचान करता है RFC 6376.
किसी डिवाइस या व्यावसायिक एप्लिकेशन के लिए, प्रोटॉन कस्टम-डोमेन पते के साथ भुगतान योजनाओं के लिए एक अलग एसएमटीपी-सबमिशन सुविधा का दस्तावेजीकरण करता है। इसका SMTP गाइड पता-विशिष्ट SMTP टोकन का उपयोग करता है, सामान्य मेलबॉक्स पासवर्ड का नहीं, और बताता है कि एसएमटीपी-सबमिट किया गया मेल एंड-टू-एंड एन्क्रिप्टेड नहीं है। किसी एप्लिकेशन को कॉन्फ़िगर करने से पहले सुविधा पात्रता और अधिकृत पते की पुष्टि करें। क्रेडेंशियल निर्माण और लगातार पहुंच के लिए उनकी अपनी सुरक्षा मंजूरी की आवश्यकता होती है; साक्ष्य कार्यपुस्तिका में कोई टोकन प्रदर्शित नहीं होना चाहिए।
प्रत्येक एप्लिकेशन के लिए एक अलग परिणाम रिकॉर्ड करें, भले ही स्टाफ वेबमेल परीक्षण पास हो जाए। सबमिशन सर्वर पर एक सफल लॉगिन न तो अंतिम दृश्यमान प्रेषक और न ही प्राप्तकर्ता के प्रमाणीकरण परिणाम को साबित करता है। यदि कोई प्रिंटर या सीआरएम सबमिशन से पहले विफल हो जाता है, तो DKIM का निदान करने से पहले उस कनेक्शन समस्या का समाधान करें। यदि यह सफलतापूर्वक सबमिट हो जाता है, तो नियंत्रित रिसीवर को परिणामी संदेश का पालन करें।
देखे गए मार्गों से DMARC नीति निर्धारित करें
डोमेन की मौजूदा DMARC नीति और उसके मालिक के साथ रिपोर्टिंग गंतव्य की समीक्षा करें। एक स्थापित नीति को सुरक्षित रखें जब तक कि अलग से अनुमोदित परिवर्तन की आवश्यकता न हो। एक संरेखित पासिंग SPF या DKIM परिणाम DMARC संतुष्ट कर सकता है, जैसा कि इसमें परिभाषित किया गया है RFC 9989. वास्तविक जांचें संरेखण प्रत्येक संबंधित उपडोमेन को योग्य मानने के बजाय मोड।
प्रवर्तन बढ़ाने से पहले, प्रत्यक्ष आवेदनों, अग्रेषण व्यवस्था और मेल-सूची के उपयोग पर ध्यान दें, जिस पर व्यवसाय निर्भर करता है। निगरानी अवधि में एक मालिक और एक समीक्षा परिणाम होना चाहिए, न कि जांच के लिए अनिश्चितकालीन विकल्प बनना चाहिए। समग्र रिपोर्ट खोज का मार्गदर्शन कर सकते हैं, लेकिन वे रूट-विशिष्ट हेडर को प्रतिस्थापित नहीं करते हैं या प्रत्येक प्राप्तकर्ता के लिए इनबॉक्स प्लेसमेंट साबित नहीं करते हैं।
Proton Mail स्वीकृति वर्कशीट
प्रत्येक स्टाफ़-मेल या एप्लिकेशन रूट के लिए एक पंक्ति बनाएँ:
- डोमेन, किरायेदार मालिक और पता सूची संशोधन: ____।
- डोमेन सत्यापन, पता निर्माण और MX कटओवर साक्ष्य: ____।
- मौजूदा प्रेषकों को SPF समीक्षा में बरकरार रखा गया है: ____।
- जारी किए गए DKIM CNAME सेट और सभी तीन प्रकाशित-स्वामी चेक: ____।
- लीगेसी मैनुअल-कुंजी विरोध और अनुमोदित संक्रमण योजना, यदि कोई हो: ____।
- रूट, क्लाइंट या डिवाइस और अधिकृत पते से: ____।
- रहस्यों को छोड़कर, एप्लिकेशन SMTP एक्सेस अनुमोदन संदर्भ: ____।
- संदेश-आईडी, यूटीसी समय, Return-Path और DKIM d=/s=: ____।
- विश्वसनीय प्रमाणीकरण परिणाम, संरेखण और व्यवसाय रसीद जांच: ____।
- पुनर्प्राप्ति स्वामी, अनसुलझे अपवाद और समीक्षा निर्णय: ____।
DNS सफ़ाई के बाद काल्पनिक निदान
केवल काल्पनिक उदाहरण: जुनिपर अकाउंट्स दो प्रोटॉन CNAMEs को हटा देता है क्योंकि इसका नवीनतम संदेश तीसरे चयनकर्ता का उपयोग करता है। बाद में, प्रमाणीकरण असंगत हो जाता है। मेल व्यवस्थापक नई रूट-डोमेन SPF नीति जोड़ने के बजाय ज़ोन की तुलना पूर्ण जारी सेट से करता है। अनुपलब्ध CNAME को स्वीकृत परिवर्तन प्रक्रिया के माध्यम से पुनर्स्थापित किया जाता है, प्रोटॉन की स्थिति की दोबारा जाँच की जाती है, और ताज़ा संदेश यह स्थापित करते हैं कि हस्ताक्षर पुनर्प्राप्त हो गए हैं या नहीं।
यह उदाहरण बताता है कि इन्वेंट्री में रोटेशन निर्भरताएँ क्यों हैं। यह कोई देखी गई प्रोटॉन घटना नहीं है, और कोई जुनिपर मेलबॉक्स या DNS ज़ोन एक्सेस नहीं किया गया था।
अगले परिवर्तन के लिए साक्ष्य अपने पास रखें
जारी किए गए रिकॉर्ड, सार्वजनिक DNS जांच और संशोधित प्राप्त हेडर को एक साथ रखें। DNS-होस्ट परिवर्तन, पता माइग्रेशन, कुंजी-संक्रमण कार्य या नए एप्लिकेशन रूट के बाद पुनः सत्यापित करें। लाइव खाता निरीक्षण, रिकॉर्ड प्रकाशन, नियंत्रित भेजना, दृश्य समीक्षा प्रदान करना, मानव एसएमई अनुमोदन और प्रकाशन इस लेख द्वारा पूरा नहीं किया गया है। दस्तावेजी प्रक्रिया पूरी होने के बाद भी वे गेट लंबित रहते हैं।
भेजने की पहुंच को इनबॉक्स पहुंच से अलग करें
प्रोटॉन SMTP सबमिशन को केवल भेजने के रूप में वर्णित करता है; तृतीय-पक्ष डेस्कटॉप क्लाइंट के माध्यम से प्राप्त करना एक अलग ब्रिज वर्कफ़्लो है। एक सफल एप्लिकेशन सबमिशन परीक्षण इनबॉक्स सिंक्रनाइज़ेशन स्थापित नहीं करता है। प्रति एप्लिकेशन एक अलग स्वीकृत टोकन रखें ताकि निरस्त किया गया डिवाइस अन्य ग्राहकों को अनावश्यक रूप से बाधित न करे। यह एक एक्सेस-डिज़ाइन अनुशंसा है; कोई क्रेडेंशियल बनाया या कॉन्फ़िगर नहीं किया गया था.
संदेश स्वीकृति को नीति रोलआउट से अलग करें
एक उत्तीर्ण संरेखित SPF परिणाम एक संदेश मूल्यांकन को संतुष्ट कर सकता है, लेकिन अकेले पूरे डोमेन को अस्वीकार करने के लिए स्थानांतरित करने को उचित नहीं ठहराता है। RFC 9989 धारा 7.4 को डोमेन प्रकाशन के लिए वैध DKIM आवश्यकता है p=reject और अप्रत्यक्ष-मेल अंतरसंचालनीयता के बारे में चेतावनी देता है। पॉलिसी स्वामी द्वारा प्रवर्तन को मंजूरी देने से पहले सभी वैध प्रेषकों और अप्रत्यक्ष मार्गों की सूची बनाएं। इस आलेख के लिए कोई DNS परिवर्तन, टैनेंट ऑपरेशन या प्राप्त-संदेश परीक्षण निष्पादित नहीं किया गया था।