Salesforce विभिन्न उत्पादों और मार्गों के माध्यम से मेल भेज सकता है। DNS बदलने से पहले, पहचानें कि किस सिस्टम ने संदेश भेजा है और कौन सा संगठन इसके कॉन्फ़िगरेशन का स्वामी है। सेल्स क्लाउड अधिसूचना, मार्केटिंग क्लाउड अभियान और बाहरी रिले को एक विनिमेय सेटअप के रूप में नहीं माना जाना चाहिए।
यह मार्गदर्शिका Salesforce प्लेटफ़ॉर्म वर्कफ़्लो पर केंद्रित है जो प्रबंधित करता है DKIM सेटअप में कुंजियाँ. अन्य भेजने वाले उत्पादों के लिए उचित उत्पाद दस्तावेज़ीकरण का पालन करें।
संदेश प्रमाणीकरण से भेजने की अलग अनुमति
Salesforce के वर्तमान डोमेन-सत्यापन नियम और DMARC विभिन्न प्रश्नों को हल करें. डोमेन सत्यापन Salesforce भेजने वाले वर्कफ़्लो में एक स्वीकृत डोमेन स्थापित करता है। DMARC पासिंग अलाइन्ड प्रमाणीकरण परिणाम के विरुद्ध डोमेन से प्राप्त संदेश के दृश्यमान का मूल्यांकन करता है।
एक सक्रिय DKIM कुंजी Salesforce की भेजने-डोमेन सत्यापन आवश्यकता को पूरा कर सकती है। Salesforce एक अधिकृत-डोमेन सत्यापन विकल्प का भी दस्तावेजीकरण करता है। उस विकल्प के अस्तित्व का मतलब यह नहीं है कि DNS स्वामित्व जांच एक गठबंधन बनाती है DKIM हस्ताक्षर एक संदेश पर.
किसी भी व्यक्तिगत पते-सत्यापन की आवश्यकता को अलग से जांचें। वास्तविक मार्ग, प्रेषक का पता, डोमेन सत्यापन स्थिति और सक्रिय हस्ताक्षर कॉन्फ़िगरेशन को एक हरे रंग की स्थिति में संक्षिप्त करने के बजाय रिकॉर्ड करें।
इच्छित डोमेन के लिए DKIM कॉन्फ़िगरेशन बनाएं
सही संगठन में प्रलेखित DKIM कुंजी वर्कफ़्लो का उपयोग करें। अलग-अलग चयनकर्ताओं के साथ इच्छित डोमेन और समर्थित कुंजी कॉन्फ़िगरेशन का चयन करें, जो किसी अन्य प्रेषक के रिकॉर्ड को अधिलेखित नहीं करता है।
Salesforce एक प्राथमिक और वैकल्पिक उत्पन्न करता है CNAME डोमेन के लिए व्यवस्था. किसी सार्वजनिक उदाहरण की प्रतिलिपि बनाने के बजाय, खाता-जनित नाम और लक्ष्य प्रकाशित करें। वैकल्पिक प्रदाता के रोटेशन डिज़ाइन में भाग लेता है और इसे डुप्लिकेट के रूप में नहीं छोड़ा जाना चाहिए।
इसके वर्तमान निर्देश स्वामित्व वाले उपडोमेन के लिए अलग DKIM कुंजी की मांग करते हैं और स्वामित्व वाले डोमेन कॉन्फ़िगरेशन के लिए वाइल्डकार्ड मिलान के खिलाफ सलाह देते हैं। यह मानने के बजाय कि एक पैरेंट-डोमेन सेटअप प्रत्येक उपडोमेन को कवर करता है, सटीक भेजने वाली पहचान की जाँच करें।
परिवर्तन अनुरोध में संगठन संदर्भ और उत्पन्न रिकॉर्ड सेट को बनाए रखें। ये विवरण उत्पादन, सैंडबॉक्स और अलग-अलग व्यवसाय-इकाई कॉन्फ़िगरेशन को अलग करने में मदद करते हैं।
प्रकाशन सत्यापित करें, फिर सक्रियण
उत्पन्न आधिकारिक उत्तरों का निरीक्षण करें चयनकर्ता names. जांचें कि DNS संपादक ने डोमेन को दो बार नहीं जोड़ा है या रिकॉर्ड प्रकार नहीं बदला है।
प्रदाता की प्रकाशन प्रक्रिया और सार्वजनिक DNS आवश्यकताओं के संतुष्ट होने तक प्रतीक्षा करें, फिर समर्थित सक्रियण चरण का पालन करें। एक सहेजी गई कुंजी कॉन्फ़िगरेशन और एक सार्वजनिक रूप से दृश्यमान CNAME निर्भरताएँ हैं; न तो अकेले यह साबित होता है कि इच्छित आउटबाउंड संदेश पर हस्ताक्षर किए जा रहे हैं।
अन्य सक्रिय DNS रिकॉर्ड और मौजूदा DMARC नीति को सुरक्षित रखें। Salesforce एक प्रेषक के रूप में जोड़ने से डोमेन-व्यापी रिपोर्टिंग या कमजोर/मजबूत नीति विकल्पों को चुपचाप रीसेट नहीं किया जाना चाहिए।
प्रतिस्थापित पहचानों और वैकल्पिक मार्गों की जाँच करें
Salesforce असत्यापित डोमेन के लिए एक स्थानापन्न प्रेषक विकल्प का दस्तावेजीकरण करता है। यदि सक्षम किया गया है, तो दृश्यमान किसी चयनित सत्यापित संगठन-व्यापी पते का उपयोग कर सकता है; यदि कोई भी चयनित नहीं है, तो दस्तावेज़ित फ़ॉलबैक एक संगठन- या साइट-विशिष्ट sfcustomeremail.com पता है। साइट-विशिष्ट सेटिंग्स संगठन-व्यापी सेटिंग को ओवरराइड कर सकती हैं। प्रदर्शन नाम और उत्तर-प्रति अपरिवर्तित रह सकते हैं। यह मानने के बजाय कि उपयोगकर्ता द्वारा दर्ज किया गया पता अपरिवर्तित बना हुआ है, वास्तव में प्राप्त पते का निदान करें।
ईमेल रिले या उत्पाद-विशिष्ट रूटिंग की भी जांच करें। एक डाउनस्ट्रीम सिस्टम बदल सकता है कि कौन सी पहचान प्रमाणित की जाए और कहाँ एक संदेश संशोधित किया जाए। अंतिम प्राप्त संदेश समीक्षाधीन मार्ग का प्रमाण है।
एक सिंथेटिक उदाहरण में, एक टीम स्वामित्व वर्कफ़्लो के माध्यम से एक डोमेन का सत्यापन करती है और टिकट बंद कर देती है। बाद के अलर्ट में अभी भी कोई संरेखित ब्रांड हस्ताक्षर नहीं है। गायब साक्ष्य उस अलर्ट के वास्तविक पथ के माध्यम से हस्ताक्षर करना और प्राप्त करना था, न कि कोई अन्य प्रमाण कि संगठन DNS नियंत्रित करता है।
उन व्यावसायिक घटनाओं का परीक्षण करें जिन पर लोग निर्भर हैं
किसी महत्वपूर्ण वर्कफ़्लो का नियंत्रित संस्करण आज़माएं, जैसे कि केस अधिसूचना या स्वचालित अलर्ट। मूल प्राप्त संदेश और विश्वसनीय रिसीवर परिणामों का निरीक्षण करें, दृश्यमान फ्रॉम, DKIM डी= और लिफाफा पहचान को एक साथ रखें।
DMARC किसी भी गठबंधन से गुजर सकता है SPF या संरेखित DKIM . रिकॉर्ड करें कि कौन सा पथ काम करता है और यदि कोई रिले संदेश या लिफाफे की पहचान बदल देता है तो क्या होगा। यह न मानें कि सेवा-नियंत्रित रिटर्न पथ के लिए SPF प्राधिकरण ब्रांड के साथ संरेखित है।
रखना संरेखण निदान और प्रेषक सूची हैंडओवर से जुड़ी हुई है। समापन का मतलब है कि विशिष्ट उत्पाद, संगठन और वर्कफ़्लो साक्ष्य के साथ इच्छित पहचान का उपयोग करते हैं जिसे अगला ऑपरेटर दोहरा सकता है।
सत्यापित लेकिन अहस्ताक्षरित मार्ग को ट्रैक करें
लिखित मामला SF-01 मानता है कि example.org पास एक सत्यापित अधिकृत ईमेल डोमेन प्रविष्टि है, लेकिन इसकी DKIM कुंजी निष्क्रिय है क्योंकि वैकल्पिक CNAME गायब है। इच्छित प्रेषक cases@example.org है; कोई प्राप्त संदेश, लिफाफा या हस्ताक्षर परिणाम मौजूद नहीं है। Salesforce मालिक और DNS मालिक को केस-नोटिफिकेशन रूट का परीक्षण करने से पहले दोनों जेनरेट किए गए उपनामों का मिलान करना होगा और सही कुंजी को सक्रिय करना होगा। स्वामित्व सत्यापन हस्ताक्षर संबंधी अंतर को पूरा नहीं करता है. कोई संगठन, कॉन्फ़िगरेशन, DNS रिकॉर्ड या केस संदेश एक्सेस नहीं किया गया था।
प्रवर्तन सीमा को सुरक्षित रखें
RFC 9989 धारा 7.4 में डोमेन प्रकाशन के लिए वैध DKIM की आवश्यकता है, अकेले SPF नहीं p=reject, और अप्रत्यक्ष-मेल और मेलिंग-सूची अंतरसंचालनीयता के बारे में चेतावनी देता है। एक भी सफल प्रत्यक्ष-संदेश परीक्षण इस बात का प्रमाण नहीं है कि हर वैध मार्ग मजबूत नीति के लिए तैयार है। वास्तविक अंतर का निदान करते समय मौजूदा अनुमोदित सुरक्षा बनाए रखें; किसी भी नीति परिवर्तन के लिए अपने स्वयं के निर्णय की आवश्यकता होती है।