ईमेल-प्रदाता माइग्रेशन के दौरान SPF बदलना

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

प्रवासन सीमा की सूची

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

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

ओवरलैप नीति डिज़ाइन करें

एक लागू रखें SPF रिकॉर्ड प्रत्येक मूल्यांकित स्वामी के नाम पर। पुरानी और नई नीतियों को अलग-अलग प्रतिस्पर्धी SPF रिकॉर्ड के रूप में प्रकाशित न करें। RFC 7208 §3.2 और RFC 7208 §4.5 चयन बाधा को परिभाषित करें।

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

इच्छित अंतिम गैर-मिलान परिणाम को रिकॉर्ड करें और सुनिश्चित करें कि यह गलती से नहीं बदला है। माइग्रेशन सार्वभौमिक प्राधिकरण प्रदान करने का एक कारण नहीं है। रखना DKIM सेटअप और DMARC संरेखण योजना में अलग-अलग कार्यप्रवाह के रूप में सत्यापन।

कटओवर का पूर्वाभ्यास करें

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

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

प्राप्तकर्ता के साक्ष्य की जाँच करें

प्रत्येक प्रासंगिक मार्ग से प्राप्त नमूना एकत्र करें और विश्वसनीय रिसीवर के प्रमाणीकरण परिणाम, मूल्यांकन किए गए लिफाफे की पहचान और डोमेन से दृश्यमान का निरीक्षण करें। RFC 8601 के लिए ट्रस्ट सीमा की व्याख्या करता है Authentication-Results; उस सीमा के बाहर डाला गया हेडर स्वतंत्र प्रमाण नहीं है।

एक कच्चा SPF पास DMARC संरेखण स्थापित नहीं करता है। RFC 9989 अनुभाग 4.4 प्रमाणित पहचान को लेखक डोमेन से संबंधित करता है। सफल DNS लुकअप को पूर्ण मानने के बजाय नए रूट के संरेखित प्रमाणीकरण की पुष्टि करें। डिलीवरी अभी भी अन्य प्राप्तकर्ता नीतियों पर निर्भर हो सकती है।

पुराने अधिकार को जानबूझकर हटाएं

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

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

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

DNS पृष्ठभूमि: RFC 1035 अनुभाग 3.2.1 संसाधन-रिकॉर्ड टीटीएल को परिभाषित करता है; RFC 2308 §5 नकारात्मक कैशिंग को कवर करता है; RFC 8767 §4 टीटीएल शब्दार्थ को अद्यतन करता है और आधिकारिक ताज़ा विफल होने पर पुराने उपयोग की अनुमति देता है। ये DNS व्यवहार का वर्णन करते हैं, परिवर्तन के लिए सार्वभौमिक समापन समय का नहीं।

अगला निर्णय रिकॉर्ड करें

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