अकाउंट एंगेजमेंट को अन्य Salesforce ईमेल उत्पादों से अलग रखें
Salesforce अकाउंट एंगेजमेंट का अपना डोमेन-प्रबंधन वर्कफ़्लो है। यह पुष्टि करके प्रारंभ करें कि संदेश कोर Salesforce ईमेल या मार्केटिंग क्लाउड एंगेजमेंट के बजाय अकाउंट एंगेजमेंट के माध्यम से भेजा गया है, जिसे पहले पार्डोट कहा जाता था। किसी अन्य Salesforce उत्पाद के लिए DNS रेसिपी विभिन्न नियंत्रणों का उपयोग कर सकती है और इसे केवल इसलिए आयात नहीं किया जाना चाहिए क्योंकि संगठन एक ही विक्रेता का उपयोग करता है। यह मार्गदर्शिका अकाउंट एंगेजमेंट भेजने-डोमेन सत्यापन को कवर करती है, DKIM और वैकल्पिक समर्थन-सहायता प्राप्त कस्टम रिटर्न पथ।
खाते द्वारा उपयोग किए जाने वाले डोमेन से प्रत्येक व्यावसायिक इकाई, ब्रांड और इच्छित डोमेन की सूची बनाएं। अभियान और स्वचालन सेटिंग्स द्वारा चयनित वास्तविक प्रेषक को शामिल करें। उपयोगकर्ता के मेलबॉक्स पते में दिखाई देने वाला डोमेन प्रत्येक खाता सहभागिता रूट के लिए स्वचालित रूप से कॉन्फ़िगर नहीं किया जाता है। किसी साझा डोमेन के रिकॉर्ड को बदलने से पहले इन्वेंट्री की एक साथ समीक्षा करने के लिए एक मार्केटिंग स्वामी और DNS व्यवस्थापक को नियुक्त करें।
स्वीकृति लक्ष्य एक संरेखित पासिंग प्रमाणीकरण तंत्र के साथ एक नियंत्रित प्राप्त संदेश है। डोमेन स्वामित्व सत्यापन, DNS प्रकाशन और हरित प्रबंधन स्थिति उपयोगी मध्यवर्ती साक्ष्य हैं। कोई भी अकेले यह साबित नहीं करता है कि किसी विशिष्ट अभियान ने इच्छित पहचान का उपयोग किया है या प्राप्तकर्ता सर्वर ने इसके प्रमाणीकरण को स्वीकार कर लिया है।
रूट DNS संपादित करने से पहले डिफ़ॉल्ट SPF पथ को समझें
Salesforce's खाता सहभागिता DNS मार्गदर्शन बताता है कि अकाउंट एंगेजमेंट मेल पास हो जाता है SPF अपने नियंत्रित भेजने वाले बुनियादी ढांचे के माध्यम से और उस डिफ़ॉल्ट सेटअप के लिए ग्राहक SPF परिवर्तन की आवश्यकता नहीं होती है। संगठन के रूट डोमेन में सामान्य Salesforce SPF शामिल न करें, केवल इसलिए कि उत्पाद का नाम इसमें दिखाई देता है DMARC प्रतिवेदन। पहले वास्तविक मार्ग और मूल्यांकित पहचान की पुष्टि करें।
SPF SMTP को प्रमाणित करता है मेल प्रेषक पहचान, के लिए अलग हैंडलिंग के साथ HELO, अंतर्गत RFC 7208. इसका परिणाम अलग है संरेखण दृश्यमान से. एक सफल प्रदाता-डोमेन SPF जांच असंरेखित SPF के साथ सह-अस्तित्व में रह सकती है। किसी भिन्न डोमेन की नीति बदलने से यह नहीं बदलता कि संदेश किस लिफ़ाफ़ा डोमेन का उपयोग करता है।
संगठन की अन्य सेवाओं के लिए आवश्यक SPF नीति को सुरक्षित रखें। यदि अलग से अधिकृत कस्टम सेटअप के लिए नीति में बदलाव की आवश्यकता है, तो उस मालिक की एक पूरी नीति की समीक्षा करें, जिसमें नेस्टेड डीएनएस-क्वेरी शर्तें और प्रोटोकॉल लुकअप सीमा शामिल है। दूसरा मत बनाओ SPF रिकॉर्ड या किसी असत्यापित आवश्यकता के लिए जगह बनाने के लिए असंबंधित प्रेषकों को हटा दें।
स्वामित्व और DKIM अलग-अलग रिकॉर्ड के रूप में सत्यापित करें
इच्छित ईमेल भेजने वाले डोमेन और उसकी अपेक्षित DNS प्रविष्टियों की पहचान करने के लिए डोमेन प्रबंधन का उपयोग करें। DNS मार्गदर्शन डोमेन की सत्यापन कुंजी को उसके DomainKey से अलग करता है। सत्यापन मूल्य भेजने के लिए स्वामित्व स्थापित करता है; DKIM मान संदेश हस्ताक्षर का समर्थन करता है। किसी भी उद्देश्य को ध्यान में रखने के बजाय कार्यपत्रक में दोनों उद्देश्यों को सुरक्षित रखें TXT रिकॉर्ड विनिमेय साक्ष्य के रूप में Salesforce मान युक्त।
वास्तविक खाते से मान कॉपी करें. DNS परिवर्तन करने से पहले संपूर्ण रिकॉर्ड स्वामी, प्रकार, मान और निर्देश दिनांक सहेजें। जांचें कि क्या कोई अन्य खाता सहभागिता खाता या कोई भिन्न सेवा पहले से ही उसी स्वामी पर निर्भर है। किसी विरोधाभासी रिकॉर्ड को अधिलेखित न करें, किसी अन्य ग्राहक के मूल्य का पुन: उपयोग न करें या उसे न बदलें चयनकर्ता एक आविष्कृत नाम के लिए. जब खाता व्यवस्थाएं टकराती हैं तो समर्थित समाधान के लिए समर्थन मांगें।
ईमेल भेजने वाले डोमेन को ट्रैकर डोमेन से अलग रखें। Salesforce स्पष्ट रूप से उन दो कार्यों के लिए समान डोमेन का उपयोग करने के खिलाफ चेतावनी देता है। एक ब्रांडेड ट्रैकिंग होस्टनाम, फ्रॉम डोमेन के समान नहीं है, भले ही दोनों एक अभिभावक साझा करते हों। इन्वेंट्री ट्रैकिंग निर्भरताएं अलग से ताकि प्रमाणीकरण कार्य अनजाने में संपत्ति यूआरएल या अभियान लिंक को न बदले।
दस्तावेज़ीकृत वर्कफ़्लो के माध्यम से DomainKey प्रकाशित करें
Salesforce's DKIM कार्यान्वयन निर्देश अकाउंट एंगेजमेंट प्रशासक की भूमिका की आवश्यकता है। लाइटनिंग ऐप में, अकाउंट एंगेजमेंट सेटिंग्स खोलें, फिर डोमेन प्रबंधन खोलें। वैकल्पिक अकाउंट एंगेजमेंट इंटरफ़ेस में, दस्तावेज़ीकृत प्रारंभिक बिंदु एडमिन है। ईमेल भेजने वाले डोमेन के अंतर्गत, चुने गए डोमेन के लिए अपेक्षित DNS प्रविष्टियाँ खोलें और TXT के रूप में प्रकाशन के लिए DomainKey मान की प्रतिलिपि बनाएँ।
उस खाते और डोमेन के लिए दिखाए गए स्वामी और मूल्य का उपयोग करें। वर्तमान लेख में कहा गया है कि रिकॉर्ड जोड़े जाने के बाद हस्ताक्षर प्रभावी होने के लिए 24 घंटे तक का समय दिया जाए। इसे प्रदाता समय मार्गदर्शन के रूप में मानें, यह गारंटी नहीं कि प्रत्येक DNS कैश या रिसीवर एक ही पल में अपडेट हो जाएगा। प्रकाशन का समय रिकॉर्ड करें और नए परीक्षण पर निर्णय लेने से पहले अपेक्षित स्थिति की प्रतीक्षा करें।
सटीक पूर्णतः योग्य स्वामी सहित सार्वजनिक DNS उत्तर की पुष्टि करें। DNS संपादक कभी-कभी ज़ोन का नाम होस्ट फ़ील्ड में जोड़ देते हैं, जिससे पूरा नाम दर्ज करने पर एक डुप्लिकेट प्रत्यय बन जाता है। इनपुट फॉर्म पर भरोसा करने के बजाय परिणामी उत्तर की समीक्षा करें। किसी भी डोमेन प्रबंधन त्रुटि और उसके विवरण को सहेजें ताकि समर्थन व्याख्या की गई स्थिति के बजाय वास्तविक विफलता की जांच कर सके।
तय करें कि कस्टम रिटर्न पथ की आवश्यकता है या नहीं
Salesforce's DMARC समर्थन आलेख संरेखित DKIM सामान्य DMARC पथ के रूप में वर्णित करता है और बताता है कि डिफ़ॉल्ट वापसी का पथ डोमेन दृश्यमान प्रेषक के साथ संरेखित नहीं है. यह समर्थन-सहायता प्राप्त कस्टम रिटर्न-पाथ अनुरोध का भी दस्तावेजीकरण करता है। बताई गई सीमा प्रत्येक संदेश के लिए चयनित एक परिवर्तनीय डोमेन के बजाय प्रति व्यवसाय इकाई एक निश्चित कस्टम रिटर्न-पथ डोमेन है।
इस विकल्प का अनुरोध करने से पहले, व्यावसायिक आवश्यकता की पहचान करें। एक संगठन जिसे संरेखित SPF के साथ-साथ DKIM आवश्यकता है, उसे समर्थन के साथ वास्तविक डोमेन व्यवस्था और संरेखण मोड का मूल्यांकन करना चाहिए। असंबद्ध ब्रांडों के लिए भेजने वाली एक व्यावसायिक इकाई को यह नहीं मानना चाहिए कि एक निश्चित रिटर्न पथ प्रत्येक फ्रॉम डोमेन के साथ संरेखित हो सकता है। उस डिज़ाइन प्रश्न को तब तक खुला रखें जब तक कि देखी गई पहचान और समर्थित कॉन्फ़िगरेशन उसका समाधान न कर दें।
समर्थन मामले से सटीक DNS रिकॉर्ड प्राप्त करें और DNS स्वामी से विरोधों और निर्भरताओं की समीक्षा करवाएं। यह आलेख कोई सार्वभौमिक कस्टम-रिटर्न-पथ लक्ष्य या सक्रियण स्विच प्रदान नहीं करता है। अनुमानित रिकॉर्ड प्रकाशित करना या किसी अन्य उत्पाद के बाउंस-डोमेन कॉन्फ़िगरेशन की प्रतिलिपि बनाना आवश्यकता को पूरा किए बिना कार्य मार्ग को तोड़ सकता है।
वास्तविक संदेश प्रवाह के माध्यम से चयनित प्रेषक का परीक्षण करें
प्रत्येक अलग-अलग भेजने वाले डोमेन और व्यवसाय-इकाई मार्ग के माध्यम से हानिरहित नियंत्रित संदेश भेजें। नियोजित अभियान या स्वचालन के समान प्रेषक चयन का उपयोग करें। अभियान संदर्भ, संदेश-आईडी, यूटीसी समय और बाहरी परीक्षण प्राप्तकर्ता को रिकॉर्ड करें। यदि कोई पूर्वावलोकन या परीक्षण सुविधा उत्पादन से भिन्न पथ का उपयोग करती है, तो इसे प्रतिनिधि साक्ष्य के रूप में मानने से पहले उस अंतर को हल करें।
विश्वसनीय प्राप्त प्रणाली पर, फ्रॉम, Return-Path और सभी DKIM हस्ताक्षरित डोमेन और चयनकर्ताओं को कैप्चर करें। RFC 6376 सार्वजनिक सत्यापन कुंजी का पता लगाने के लिए उपयोग किए जाने वाले d= और s= मानों को परिभाषित करता है। देखे गए हस्ताक्षर डोमेन की तुलना कॉन्फ़िगर किए गए प्रेषण डोमेन से करें। एक DNS रिकॉर्ड सही हो सकता है जबकि एक संदेश अभी भी एक अप्रत्याशित प्रेषक या अन्य मार्ग का उपयोग करता है।
आवेदन करना RFC 9989 वास्तविक परिणामों के लिए. DMARC पासिंग एलाइन से गुजर सकता है DKIM हस्ताक्षर या संरेखित SPF पास करना। रिकॉर्ड करें कि किस तंत्र ने परिणाम प्रदान किया और कौन सा संरेखण मोड लागू किया। SPF प्रमाणीकरण, SPF संरेखण, DKIM प्रमाणीकरण और DKIM संरेखण को अलग-अलग फ़ील्ड में रखें। यह एकल हरित स्थिति को किसी अप्रीक्षित आवश्यकता को छिपाने से रोकता है।
प्रत्येक नियंत्रण को बदलने के बजाय विफल सीमा का समस्या निवारण करें
यदि भेजने वाला डोमेन असत्यापित है, तो उसकी सत्यापन कुंजी और सटीक DNS स्वामी की अपेक्षित DNS प्रविष्टियों से तुलना करें। यदि अपेक्षित सक्रियण अवधि के बाद DKIM गायब है, तो चयनित डोमेन और खाते से पुष्टि करें, फिर डोमेन प्रबंधन त्रुटियों की जांच करें। यदि कोई हस्ताक्षर विफल हो जाता है, तो चयनकर्ता और सार्वजनिक मान को सत्यापित करें और किसी भी डाउनस्ट्रीम सिस्टम का निरीक्षण करें जो हस्ताक्षर करने के बाद संदेश को बदलता है।
यदि SPF पास होने के दौरान DMARC विफल हो जाता है, तो संरेखण की जांच करें और देखें कि क्या उस प्रेषक के लिए संरेखित DKIM कॉन्फ़िगर किया गया था। डिफ़ॉल्ट SPF सफलता को DMARC सफलता के वादे के रूप में न मानें। यदि कोई कस्टम रिटर्न पथ शामिल है, तो निश्चित व्यवसाय-इकाई सेटिंग और समर्थन-प्रदत्त निर्देशों के साथ देखी गई लिफाफा पहचान की तुलना करें। निदान के लिए एक प्रतिनिधि विफल संदेश को सुरक्षित रखें।
संगठन की DMARC नीति और रिपोर्टिंग गंतव्यों को उनके मौजूदा स्वामित्व में रखें। Salesforce लेख उन्हें एकत्रित करने के लिए अकाउंट एंगेजमेंट के बजाय बाहरी DMARC निगरानी की आवश्यकता का वर्णन करता है विफलता रिपोर्ट. DNS प्रमाणीकरण कार्य को चुपचाप रिपोर्टिंग गंतव्यों को प्रतिस्थापित नहीं करना चाहिए या असंबंधित प्रेषकों पर कम प्रवर्तन नहीं करना चाहिए। किसी भी प्रस्तावित नीति परिवर्तन की मेल और सुरक्षा स्वामियों के साथ अलग से समीक्षा करें।
अकाउंट एंगेजमेंट डोमेन वर्कशीट
- खाता, व्यवसाय इकाई, ब्रांड और भेजने का वर्कफ़्लो: ____।
- पते से चयनित और कॉन्फ़िगर किया गया ईमेल भेजने वाला डोमेन: ____।
- अलग ट्रैकर डोमेन और उसकी मौजूदा निर्भरताएँ: ____।
- अपेक्षित DNS प्रविष्टियों से सत्यापन कुंजी और DKIM रिकॉर्ड संदर्भ: ____।
- सार्वजनिक DNS उत्तर, प्रकाशन समय और प्रबंधन स्थिति: ____।
- डिफ़ॉल्ट या समर्थन-सहायता प्राप्त कस्टम रिटर्न-पथ डिज़ाइन: ____।
- कस्टम रिटर्न-पथ सीमा और समर्थन पुष्टिकरण जहां प्रासंगिक हो: ____।
- परीक्षण संदेश-आईडी, यूटीसी समय, प्रेषक, Return-Path और DKIM पहचान: ____।
- विश्वसनीय प्रमाणीकरण परिणाम और संरेखित DMARC तंत्र: ____।
- अपवाद, मालिक की निगरानी और अनुमोदित वसूली: ____।
संरेखण के बिना SPF सफलता का काल्पनिक उदाहरण
केवल काल्पनिक लिखित मामला: AE-01 मानता है कि बिजनेस यूनिट नॉर्थ news@example.org के रूप में भेजता है और बिजनेस यूनिट साउथ news@example.net के रूप में भेजता है। bounce.example.org के तहत एक प्रस्तावित निश्चित कस्टम रिटर्न पथ आरामदायक SPF संरेखण के तहत पहले के साथ संरेखित हो सकता है लेकिन इसे असंबंधित दूसरे के साथ संरेखित नहीं माना जा सकता है। DKIM हस्ताक्षर और SPF परिणाम अज्ञात रहते हैं, इसलिए किसी भी मार्ग के पास DMARC कोई निश्चित निर्णय नहीं है। मार्केटिंग और मेल स्वामियों को व्यवसाय-इकाई सेटिंग्स को अलग करना चाहिए और किसी भी रूट SPF संपादन का अनुरोध करने से पहले डोमेन से चयनित संरेखित DKIM मान्य करना चाहिए। सभी पहचानों और व्यवस्थाओं का आविष्कार किया गया है; कोई समर्थन मामला, DNS क्वेरी या संदेश निष्पादित नहीं किया गया था।
पूर्णता को जीवंत साक्ष्य से बांध कर रखें
दस्तावेज़ीकृत वर्कफ़्लो वास्तविक किरायेदार की अनुमतियों, जेनरेट किए गए मानों या कस्टम रिटर्न-पथ क्षमता को सत्यापित नहीं करता है। वे खाता जांच, लाइव DNS और हेडर सत्यापन, दृश्य समीक्षा और मानव एसएमई अनुमोदन लंबित हैं। यह मार्गदर्शिका अप्रकाशित है और इसे इस बात के प्रमाण के रूप में प्रस्तुत नहीं किया जाना चाहिए कि किसी संगठन के अभियान उत्पादन में प्रमाणित हैं।
पारित संदेश को प्रवर्तन तत्परता से अलग करें
RFC 9989 धारा 7.4 को डोमेन प्रकाशन p=reject के लिए वैध DKIM आवश्यकता होती है और अप्रत्यक्ष-मेल इंटरऑपरेबिलिटी के बारे में चेतावनी दी जाती है। एक एकल संरेखित SPF परिणाम अपने आप में अस्वीकार-नीति रोलआउट को उचित नहीं ठहराता है। इस प्रदाता सेटअप से सभी वैध मार्गों और नीति स्वामित्व की अलग से समीक्षा करें।