किसी अन्य प्रेषक को ओवरराइट किए बिना ड्रिप प्रमाणीकरण सेट करें

कस्टम भेजने को पहचान परिवर्तन के रूप में मानें

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

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

खाता-विशिष्ट रिकॉर्ड सेट प्राप्त करें

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

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

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

इच्छित सार्वजनिक नाम से होस्ट-नाम फ़ॉर्मेटिंग को अलग करें

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

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

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

समझें कि DNS प्रकाशन क्या साबित नहीं कर सकता

मुख्य सामग्री प्रकाशित करने से यह स्थापित नहीं होता कि उसके साथ एक संदेश पर हस्ताक्षर किया गया था। RFC 6376 अनुभाग 3.1 और 3.5 हस्ताक्षर के चयनकर्ता और हस्ताक्षर डोमेन को कुंजी लुकअप के साथ कनेक्ट करें। प्राप्तकर्ता का परिणाम वास्तव में संदेश पर मौजूद हस्ताक्षर से जुड़ा होना चाहिए, न कि नियोजन पत्रक से कॉपी किए गए चयनकर्ता के नाम से।

SPF इसी तरह एक SMTP पहचान का मूल्यांकन करता है, जिसका वर्णन किया गया है RFC 7208 अनुभाग 2.4. एक डोमेन पर एक प्राधिकरण स्वचालित रूप से एक अलग दृश्यमान पते को प्रमाणित नहीं करता है। अभिभावक को संशोधित करने से बचें SPF रिकॉर्ड केवल इसलिए कि एक नया मार्केटिंग टूल एप्लिकेशन सूची में दिखाई देता है। देखे गए मार्ग और वर्तमान प्रदाता निर्देशों को आवश्यक परिवर्तन निर्धारित करना चाहिए।

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

एक सीमित स्वीकृति रिकॉर्ड बनाएँ

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

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

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

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

काल्पनिक टकराव की समीक्षा और खुली आवश्यकताएँ

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

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