स्थापित करना DMARC Microsoft 365 कस्टम डोमेन के लिए, डोमेन के भेजने के मार्ग स्थापित करें, उपयुक्त कॉन्फ़िगर करें SPF नीति, कस्टम-डोमेन सक्षम करें DKIM और प्राप्त मेल पर एक संरेखित परिणाम सत्यापित करें। DMARC का प्रकाशन TXT रिकॉर्ड उसी क्रम में एक कदम है.
यह मार्गदर्शिका Microsoft 365 के माध्यम से कस्टम-डोमेन भेजने को कवर करती है। उदाहरणों का उपयोग करने से पहले Microsoft क्लाउड वातावरण और किसी भी हाइब्रिड, रिले या आउटबाउंड गेटवे व्यवस्था की पुष्टि करें। Microsoft 365 बाहर भेजने वाले एप्लिकेशन को अपने स्वयं के समर्थित प्रमाणीकरण कॉन्फ़िगरेशन की आवश्यकता होती है, भले ही वे समान दृश्यमान डोमेन का उपयोग करते हों।
डोमेन, DNS होस्ट और Microsoft वातावरण की पुष्टि करें
कस्टम डोमेन, उसके आधिकारिक DNS होस्ट, Microsoft 365 वातावरण और हस्ताक्षर को प्रबंधित करने के लिए आवश्यक अनुमति की पुष्टि करें। मौजूदा SPF , DKIM और बचाएं DMARC रिकॉर्ड उन्हें बदलने से पहले.
सार्वजनिक DNS प्रशासन को किरायेदार की डोमेन सूची के साथ भ्रमित न करें। रजिस्ट्रार DNS होस्ट भी हो सकता है, लेकिन इसकी आवश्यकता नहीं है। किसी ज़ोन को संपादित करने से पहले प्रत्यायोजित नाम सर्वर की जाँच करें।
डोमेन का उपयोग करने वाले प्रत्येक रूट की सूची बनाएं। विशेष रूप से, सामान्य Exchange Online भेजने को रिले, डायरेक्ट सेंड, किसी अन्य SMTP प्रदाता या आउटबाउंड गेटवे का उपयोग करने वाले एप्लिकेशन से अलग करें। अकेले उत्पाद का नाम अंतिम हस्ताक्षरकर्ता की पहचान नहीं करता है।
कर्मचारी मेल और एप्लिकेशन मेल मैप करें
Microsoft 365 में जाने से इनवॉइसिंग एप्लिकेशन, वेबसाइट संपर्क फ़ॉर्म या भर्ती प्लेटफ़ॉर्म स्वचालित रूप से स्थानांतरित नहीं होता है। वे सेवाएँ किसी भिन्न प्रदाता के माध्यम से भेजते समय भी आपका डोमेन प्रदर्शित कर सकती हैं।
एक सरल सेवा मानचित्र के लिए पूछें: कर्मचारी मेल, एप्लिकेशन मेल और आउटसोर्स संचार, प्रत्येक मार्ग के पास एक मालिक के साथ। पासवर्ड रीसेट और बिलिंग नोटिस जैसे महत्वपूर्ण प्रवाह के लिए प्राप्त-संदेश परीक्षण की आवश्यकता है। डिलिवरेबल काम कर रहा है, जवाबदेह संचार, सक्षम किरायेदार सेटिंग का स्क्रीनशॉट नहीं।
लागू SPF नीति कॉन्फ़िगर करें
**केवल अपनी मानक Microsoft 365 सेवा या GCC** के माध्यम से भेजने वाले डोमेन के लिए Microsoft का प्रलेखित उदाहरण है:
v=spf1 include:spf.protection.outlook.com -all
यह एक स्कोप्ड उदाहरण है, मौजूदा मिश्रित-सेवा नीति का प्रतिस्थापन नहीं। Microsoft दस्तावेज़ों में GCC हाई/DoD और 21Vianet द्वारा संचालित इसकी सेवा के लिए डोमेन शामिल हैं। अपने परिवेश के लिए वर्तमान निर्देशों का पालन करें.
मूल्यांकन किए गए डोमेन पर एक लागू SPF नीति प्रकाशित करें। यदि कोई वैध नीति पहले से मौजूद है, तो दूसरी नीति जोड़ने के बजाय उस नीति की समीक्षा करें और उसे अद्यतन करें SPF रिकॉर्ड. केवल उचित भेजने की अनुमतियाँ शामिल करें और SPF सीमाओं के विरुद्ध पूर्ण निर्भरता पथ की जाँच करें।
किरायेदार-जनित दोनों DKIM CNAME प्रकाशित करें
Microsoft 365 कस्टम-डोमेन DKIM दो का उपयोग करता है CNAME अभिलेख. डिफेंडर पोर्टल के DKIM कॉन्फ़िगरेशन या Exchange Online पावरशेल से उनके सटीक मान प्राप्त करें। पुराने नामकरण टेम्प्लेट से लक्ष्य न बनाएं: Microsoft एक से अधिक लक्ष्य प्रारूप का दस्तावेज़ बनाता है, और जेनरेट किए गए मानों में किरायेदार-विशिष्ट घटक शामिल हो सकते हैं।
अधिकृत Exchange Online पॉवरशेल सत्र में, यह रीड-ओनली चेक कॉन्फ़िगर किए गए लक्ष्यों को पुनः प्राप्त करता है:
Get-DkimSigningConfig -Identity example.com | प्रारूप-सूची सक्षम, स्थिति, चयनकर्ता1CNAME, चयनकर्ता2CNAME
यदि डोमेन में कोई हस्ताक्षर कॉन्फ़िगरेशन नहीं है, तो उन गुणों के अस्तित्व की अपेक्षा करने से पहले Microsoft की दस्तावेज़ीकृत प्रारंभिक-कॉन्फ़िगरेशन प्रक्रिया का उपयोग करें। डिफेंडर पोर्टल में, संबंधित क्षेत्र ईमेल प्रमाणीकरण सेटिंग्स है, फिर DKIM ।
**दोनों** उत्पन्न CNAME रिकॉर्ड प्रकाशित करें, उनके सार्वजनिक उत्तरों को सत्यापित करें और समर्थित किरायेदार प्रक्रिया के माध्यम से कस्टम-डोमेन हस्ताक्षर सक्षम करें। एक CNAME रिकॉर्ड सत्यापन-कुंजी प्रबंधन का प्रतिनिधित्व करता है; यह किसी निजी कुंजी या आविष्कृत TXT कुंजी को चिपकाने का अनुरोध नहीं है।
DNS संपादक व्यवहार की सावधानीपूर्वक जाँच करें। ज़ोन नाम जोड़ने वाला पैनल पूरी तरह से दर्ज किए गए होस्टनाम को डुप्लिकेट नाम में बदल सकता है। परिवर्तन रिकॉर्ड में सटीक प्रकाशित स्वामी और लक्ष्य मान सुरक्षित रखें।
इच्छित DMARC नीति और रिपोर्टिंग गंतव्य जोड़ें
यदि डोमेन एक निगरानी तैनाती शुरू कर रहा है, तो एक उदाहरणात्मक रिकॉर्ड _dmarc.example.com है:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
उदाहरण एक ही डोमेन पर एक कार्यशील रिपोर्ट गंतव्य मानता है। इसे स्वीकृत पते से बदलें और संग्रह सत्यापित करें। बाहरी गंतव्यों को अतिरिक्त रिपोर्टिंग अनुमति की आवश्यकता हो सकती है। केवल इस उदाहरण से मेल खाने के लिए मौजूदा प्रवर्तन नीति को कमजोर न करें।
प्रकाशन और सत्यापन अनुक्रम के लिए रिकॉर्ड निर्माण मार्गदर्शिका का उपयोग करें, और DMARCbis लीगेसी रोलआउट सेटिंग्स की समीक्षा करते समय तत्परता मार्गदर्शिका।
पूर्ण भेजने के मार्ग के बाद संदेशों को सत्यापित करें
एक नियंत्रित संदेश को एक अलग बाहरी प्राप्तकर्ता को भेजें और वहां मूल संदेश का निरीक्षण करें। दृश्यमान प्रेषक, एसपीएफ़-मूल्यांकित पहचान, प्रत्येक प्रासंगिक DKIM डी= डोमेन और विश्वसनीय DMARC परिणाम को रिकॉर्ड करें।
महत्वपूर्ण अनुप्रयोगों और किसी अंतिम आउटबाउंड गेटवे के माध्यम से परीक्षण दोहराएं। यदि दृश्यमान प्रेषक आपका कस्टम डोमेन है, लेकिन एकमात्र पासिंग हस्ताक्षर एक असंबंधित किरायेदार पहचान का उपयोग करता है, तो कस्टम-डोमेन हस्ताक्षर और वास्तविक मार्ग की जांच करें। यदि कोई गेटवे हस्ताक्षरित सामग्री को संशोधित करता है, तो उस गेटवे के बाद परिणाम को सत्यापित करें।
- जांचें: SPF नीति; बनाए रखने के लिए साक्ष्य: आधिकारिक उत्तर और मूल्यांकित प्रेषण मार्ग
- जांचें: DKIM प्रतिनिधिमंडल; बनाए रखने के लिए साक्ष्य: सटीक CNAME और किरायेदार कॉन्फ़िगरेशन स्थिति दोनों
- जांचें: लाइव हस्ताक्षर; बनाए रखने के लिए साक्ष्य: प्राप्त हस्ताक्षर और विश्वसनीय सत्यापन परिणाम
- जांचें: DMARC ; बनाए रखने के लिए साक्ष्य: एक गुजरता हुआ संरेखित पथ और देखा गया नीति संदर्भ
- जांचें: व्यवसाय कवरेज; बनाए रखने के लिए साक्ष्य: संगठन द्वारा वास्तव में उपयोग किए जाने वाले अनुप्रयोगों के लिए परीक्षण
- स्वीकृति और चल रहे स्वामित्व को रिकॉर्ड करें
नामित सेवा सूची के विरुद्ध कार्यान्वयन को मंजूरी दें। परिवर्तन अनुमोदक, DNS स्वामित्व, महत्वपूर्ण-प्रवाह परिणाम और शेष अपवाद रिकॉर्ड करें। एक किरायेदार की वैध हस्ताक्षर स्थिति यह प्रदर्शित नहीं करती है कि प्रत्येक बाहरी एप्लिकेशन कवर किया गया है।
ऑपरेटिंग दस्तावेज़ में क्लाउड परिवेश को स्पष्ट रखें। एक मानक-क्लाउड उदाहरण चुपचाप सरकारी-क्लाउड निर्देश नहीं बनना चाहिए। छोड़ी गई सेवाओं और प्रत्यायोजित चयनकर्ताओं के साथ-साथ वर्तमान ट्रैफ़िक में विफलताओं के लिए समय-समय पर जाँच नियुक्त करें।
घटना के साक्ष्य को संरक्षित करते हुए, परिवर्तन विफल होने पर पूर्व अनुमोदित स्थिति को पुनर्स्थापित करने की क्षमता बनाए रखें। अंतिम समीक्षा में समझौता किए गए खातों और प्रमाणित दुर्भावनापूर्ण मेल के शेष जोखिमों को स्पष्ट किया जाना चाहिए, बजाय इसके कि यह वादा किया जाए कि DMARC पास हर संदेश को सुरक्षित बनाता है।
व्यावहारिक उपाय
सेटअप तब पूरा होता है जब प्रकाशित रिकॉर्ड, किरायेदार के हस्ताक्षर की स्थिति, प्राप्त-संदेश की पहचान और रिपोर्टिंग पथ सहमत होते हैं। परिवर्तन रिकॉर्ड के साथ सेवा सूची और अपवादों को बनाए रखें; वे अगले एप्लिकेशन या गेटवे परिवर्तन के लिए आधार रेखा हैं।
सीआरएम अपवाद से कर्मचारी-मेल साक्ष्य को अलग करें
लिखित मामला M365-01 मानता है कि staff@example.org से कर्मचारी मेल एक विश्वसनीय पासिंग है DKIM हस्ताक्षर d=example.org. बिलिंग सीआरएम billing@example.org का उपयोग करता है, लेकिन इसका एकमात्र रिकॉर्ड किया गया हस्ताक्षर एक असंबंधित प्रदाता डोमेन से है और इसका SPF परिणाम अज्ञात है। कर्मचारी-मेल साक्ष्य सीआरएम परिणाम स्थापित नहीं करता है, और आंशिक सीआरएम साक्ष्य पूर्ण DMARC फैसले को उचित नहीं ठहरा सकता है। डोमेन स्वामी द्वारा प्रवर्तन तत्परता का मूल्यांकन करने से पहले CRM स्वामी को अपनी समर्थित संरेखित पहचान की पहचान करनी होगी और एक नियंत्रित बाहरी संदेश एकत्र करना होगा। ये काल्पनिक पहचान और परिणाम हैं; कोई किरायेदार, DNS परिवर्तन या मेल भेजना नहीं हुआ।