एक बीमाकर्ता का ब्रोकर नेटवर्क एक भेजने वाली प्रणाली नहीं है। एक ब्रोकर अपने स्वयं के डोमेन से लिख सकता है, अनुमोदित बीमाकर्ता-ब्रांडेड सेवा का उपयोग कर सकता है या पॉलिसी नोटिस अग्रेषित कर सकता है। अभियान आपूर्तिकर्ता और नीति प्रशासन प्लेटफ़ॉर्म आगे के मार्ग जोड़ते हैं। प्रमाणीकरण कॉन्फ़िगर करने से पहले तय करें कि प्रत्येक संबंध किस पहचान का उपयोग करने के लिए अधिकृत है।
ब्रोकर संबंध को सटीक रूप से वर्गीकृत करें
रिकॉर्ड करें कि क्या ब्रोकर अपने डोमेन के तहत संचार करता है या बीमाकर्ता-नियंत्रित फ्रॉम डोमेन के तहत। एक ब्रोकर को अपनी पहचान का उपयोग करके उस डोमेन के लिए प्रमाणीकरण का प्रबंधन करना चाहिए; इसका संदेश केवल बीमाकर्ता-डोमेन संदेश नहीं बन जाता क्योंकि इसमें बीमाकर्ता का उल्लेख है। यदि कोई बीमाकर्ता डोमेन अधिकृत है, तो विशिष्ट आवेदन, किरायेदार, उद्देश्य और जवाबदेह बीमाकर्ता मालिक को रिकॉर्ड करें।
संपूर्ण ब्रोकर नेटवर्क के लिए व्यापक प्रेषक अनुमतियाँ केवल इसलिए न जोड़ें क्योंकि कुछ संदेशों में सुधार की आवश्यकता है। प्रत्येक प्राधिकरण में एक व्यावसायिक औचित्य और एक ज्ञात तकनीकी कार्यान्वयन होना चाहिए। अग्रेषित करना भी बीमाकर्ता के रूप में भेजने से भिन्न होता है: कौन सा नियंत्रण विफल हुआ, यह तय करने से पहले वास्तविक संदेश पहचान और विश्वसनीय रिसीवर परिणामों का निरीक्षण करें।
अभियानों को नीति सेवा धारणाओं से दूर रखें
एक आउटसोर्स अभियान नीति अधिसूचना से विभिन्न अनुप्रयोगों, ऑप्ट-आउट प्रक्रियाओं, टेम्पलेट्स और प्राप्तकर्ताओं का उपयोग कर सकता है। अभियान स्वामी और पॉलिसी-सेवा स्वामी को अलग-अलग रिकॉर्ड करें। प्रमाणीकरण बाज़ार की अनुमति, नीति भाषा की वैधता या प्रकटीकरण कर्तव्य की संतुष्टि स्थापित नहीं करता है। लागू व्यवसाय और कानूनी समीक्षा के माध्यम से उन मुद्दों को सत्यापित करें।
अभियान आपूर्तिकर्ताओं के लिए, ग्राहक-विशिष्ट डोमेन कॉन्फ़िगरेशन, चयनकर्ता, क्रेडेंशियल स्वामी और निकास प्रक्रिया की पहचान करें। नीति प्रशासन, परीक्षण नवीनीकरण, अनुमोदन और ग्राहक के लिए महत्वपूर्ण अन्य दुर्लभ सूचनाओं के लिए। न्यूज़लेटर परीक्षण नवीनीकरण प्रोसेसर को सत्यापित नहीं करता है। एक बयान कि एक आपूर्तिकर्ता कस्टम ऑफ़र करता है DKIM यह प्रमाण नहीं है कि यह बीमाकर्ता के किरायेदार के लिए सक्षम है।
प्राधिकरण समाप्ति की स्थापना करें
रिकॉर्ड करें कि ब्रोकर या आपूर्तिकर्ता संबंध कब शुरू और समाप्त होता है, कौन दायरे में बदलाव को मंजूरी दे सकता है और बाहर निकलने पर किस हस्ताक्षर प्राधिकारी को हटाया जाना चाहिए। अनुक्रम की योजना बनाएं ताकि एक सेवानिवृत्त आपूर्तिकर्ता पुराने प्राधिकरण के तहत भेजना जारी न रख सके, जबकि वैध कतारबद्ध नोटिस गलती से फंसे न हों। DNS रिकॉर्ड्स को केवल इसलिए न हटाएं क्योंकि सक्रिय माइग्रेशन और स्वीकृत रोलबैक आवश्यकताओं को पूरा किए बिना अनुबंध की समाप्ति तिथि बीत चुकी है।
परीक्षण के लिए अनुमोदित सिंथेटिक नीति रिकॉर्ड का उपयोग करें। दृश्यमान प्रेषक पते, वास्तविक हस्ताक्षर डोमेन और उत्तर गंतव्य का निरीक्षण करें। यदि उत्तरों में पॉलिसीधारक डेटा शामिल है, तो उन्हें आपूर्तिकर्ता के आकस्मिक परीक्षण मेलबॉक्स के बजाय अनुमोदित परिचालन प्रणाली पर ले जाएं। संग्रहीत नमूनों को कम करें और संगठन की नीतियों के अनुसार पहुंच प्रतिबंधित करें।
अपवाद रिकॉर्ड में सीमा स्पष्ट करें
काल्पनिक मानचित्र एक बीमाकर्ता-ब्रांडेड ब्रोकर पहचान, एक अभियान पहचान और एक नीति अधिसूचना पहचान का उपयोग करता है। इसका मतलब यह नहीं है कि प्रत्येक ब्रोकर को बीमाकर्ता के डोमेन का उपयोग करना चाहिए। मान लें कि पॉलिसी नोटिस में policy.insurer.example से और एक वैध है DKIM हस्ताक्षर d=provider.example.net. वह हस्ताक्षर सख्त DKIM विफल रहता है संरेखण; वैधता मान ली गई है, यहां सत्यापित नहीं किया गया है।
अपवाद में प्रभावित अधिसूचना प्रकार, स्वामी, कारण, क्षतिपूर्ति प्रक्रिया और अगली समीक्षा तिथि का नाम होना चाहिए। ब्रोकर ऑनबोर्डिंग, आपूर्तिकर्ता प्रतिस्थापन और नीति-प्रणाली जारी होने के बाद अपवादों की समीक्षा करें। इन्वेंट्री को नियामक अनुपालन के मूल्यांकन या नीति अनुबंध की सामग्री से अलग रखें; इन काल्पनिक पहचानों द्वारा ऐसा कोई निर्धारण नहीं किया जाता है।
लंबित नवीनीकरण के साथ ब्रोकर निकास का समाधान करें
मान लीजिए कि किसी ब्रोकर का प्रतिनिधिमंडल समाप्त होने वाला है, जबकि स्वीकृत नवीनीकरण नोटिस पॉलिसी प्रणाली में कतारबद्ध है। निर्धारित करें कि कौन सी सेवा उस नोटिस का मालिक है और क्या उसका अधिकार सेवानिवृत्त ब्रोकर से स्वतंत्र है। सभी ब्रोकर अनुमतियों को अनिश्चित काल तक सक्रिय न रखें या केवल चेकलिस्ट को पूरा करने के लिए प्रत्येक संबंधित DNS रिकॉर्ड को न हटाएं। जवाबदेह स्वामियों से दायरे वाले परिवर्तन को मंजूरी देने और शेष नीति वर्कफ़्लो को सत्यापित करने को कहें। ये काल्पनिक स्थितियाँ हैं, वास्तविक बीमाकर्ता या अनुबंध निर्णय नहीं।
रूट इन्वेंट्री अनुमोदित बीमाकर्ता-ब्रांडेड ब्रोकर मेल के लिए brokers.insurer.example , मार्केटिंग के लिए campaign.insurer.example और पॉलिसी सर्विसिंग के लिए policy.insurer.example को अलग से रिकॉर्ड कर सकती है। ये उदाहरणात्मक पहचान और भूमिकाएँ हैं, हस्ताक्षरित नमूने या वास्तविक अनुदान नहीं दिए गए हैं। अपने स्वयं के डोमेन के तहत बोलने वाला ब्रोकर एक अलग पहचान मॉडल बना रहता है। कोई क्रिप्टोग्राफ़िक परीक्षण, नोटिस वितरण या निरस्तीकरण निष्पादित नहीं किया गया था।
प्रमाणीकरण की व्याख्या उसकी सीमा के भीतर करें
RFC 9989 धारा 4.4 और 5.3.5 हस्ताक्षर की वैधता, संरेखण और पूर्ण में अंतर करें DMARC निर्णय। एक एकल कल्पित असंरेखित हस्ताक्षर अन्य संरेखित DKIM या पासिंग एलाइन की अनुपस्थिति को स्थापित नहीं करता है SPF पथ. के लिए p=reject परिनियोजन, धारा 7.4 और 8 के लिए केवल SPF पर निर्भर रहने के बजाय वैध DKIM आवश्यकता होती है। धारा 5.4 हैंडलिंग को प्राप्तकर्ता नीति पर छोड़ देता है और संदेश की व्यावसायिक सामग्री को मान्य नहीं करता है। ये प्रोटोकॉल सीमाएँ अधिकृत वर्कफ़्लो, पहुँच, समय या प्राप्तकर्ता जाँच को प्रतिस्थापित नहीं करती हैं।