[ प्रेषण-सेवा मार्गदर्शिकाएँ ]

Microsoft 365 DMARC सेटअप: संपूर्ण भेजने का मार्ग सत्यापित करें

सही SPF नीति और किरायेदार-जनरेटेड DKIM प्रतिनिधिमंडल को कॉन्फ़िगर करें, फिर वास्तविक Microsoft 365 मेल और किरायेदार के बाहर भेजने वाले अनुप्रयोगों पर संरेखण सत्यापित करें।

EmailAuth अनुसंधान टीम द्वारा · 5 मिनट पढ़ें

[ प्रमुख बिंदु ]

  • सही SPF नीति और किरायेदार-जनरेटेड DKIM प्रतिनिधिमंडल को कॉन्फ़िगर करें, फिर वास्तविक Microsoft 365 मेल और किरायेदार के बाहर भेजने वाले अनुप्रयोगों पर संरेखण सत्यापित करें।
  • कर्मचारी-मेल सफलता एक अलग सीआरएम मार्ग को कवर नहीं करती है।
इस पेज पर

स्थापित करना 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 परिवर्तन या मेल भेजना नहीं हुआ।

[ ले लेना ]

कर्मचारी-मेल सफलता एक अलग सीआरएम मार्ग को कवर नहीं करती है।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

आईटी/मेल एडमिन

उत्पन्न मूल्यों का उपयोग करें और अंतिम मार्ग सत्यापित करें।

Microsoft क्लाउड परिवेश की पुष्टि करें, फिर टैनेंट से दोनों DKIM CNAME लक्ष्य प्राप्त करें। सार्वजनिक DNS , हस्ताक्षर सक्षमता और बाहरी प्राप्त-संदेश परिणाम अलग-अलग जांच हैं।

अगले कदम

  1. मौजूदा एकल SPF नीति की समीक्षा करें.
  2. दोनों सटीक DKIM CNAME प्रकाशित और सत्यापित करें।
  3. कर्मचारी मेल के साथ-साथ एप्लिकेशन और आउटबाउंड गेटवे का परीक्षण करें।

सीआईएसओ/सेकऑप्स

घोषित सेवा सूची में साक्ष्य की आवश्यकता है।

एक सक्षम किरायेदार सेटिंग एक सीमित कॉन्फ़िगरेशन स्थिति स्थापित करती है। नामित डोमेन, क्लाउड वातावरण, वास्तविक प्रेषकों और स्वीकृत अपवादों के विरुद्ध कार्यान्वयन की समीक्षा करें।

अगले कदम

  1. स्वीकृतियाँ और पिछली स्वीकृत DNS स्थिति बनाए रखें।
  2. महत्वपूर्ण-प्रवाह साक्ष्य और रिपोर्ट संग्रह की जाँच करें।
  3. पुरानी सेवाओं और प्रत्यायोजित चयनकर्ताओं की समीक्षा सौंपें।

संस्थापक/गैर-तकनीकी

कर्मचारी मेल के बाहर के आवेदन शामिल करें।

आपका Microsoft 365 कार्यान्वयन CRM, वेबसाइट और बिलिंग प्लेटफ़ॉर्म को अलग-अलग बुनियादी ढांचे पर छोड़ सकता है। व्यवसाय स्वीकृति सूची में वे संचार और उनके मालिक शामिल होने चाहिए।

अगले कदम

  1. सेवा के अनुसार महत्वपूर्ण संदेशों की सूची बनाएं.
  2. प्रत्येक महत्वपूर्ण वर्कफ़्लो से परीक्षण के लिए पूछें।
  3. रिपोर्टिंग और भावी प्रेषक परिवर्तनों के लिए एक स्वामी नियुक्त करें।

[ पूछे जाने वाले प्रश्न ]

अक्सर पूछे जाने वाले प्रश्नों

क्या मानक Microsoft 365 SPF प्रत्येक Microsoft क्लाउड के लिए सही है?

नहीं, Microsoft GCC हाई/DoD और 21Vianet सहित विशेष वातावरणों के लिए अलग-अलग मानों का दस्तावेजीकरण करता है। मानक-क्लाउड उदाहरण का उपयोग करने से पहले वास्तविक सेवा की पुष्टि करें।

क्या मैं केवल Microsoft 365 के लिए दूसरा SPF रिकॉर्ड जोड़ सकता हूँ?

एक ही डोमेन पर दूसरी लागू SPF नीति न जोड़ें। मौजूदा अनुमतियों की समीक्षा करें और एक वैध नीति प्रकाशित करें जो अधिकृत मार्गों को दर्शाती हो।

मुझे अपने किरायेदार से DKIM लक्ष्य क्यों प्राप्त करने चाहिए?

जेनरेट किए गए लक्ष्य विभिन्न नामकरण प्रारूपों और किरायेदार-विशिष्ट मानों का उपयोग कर सकते हैं। वर्तमान चयनकर्ता1CNAME और चयनकर्ता2CNAME मानों को सामान्य ट्यूटोरियल से बनाने के बजाय उनकी प्रतिलिपि बनाएँ।

क्या मुझे दोनों Microsoft DKIM CNAME रिकॉर्ड की आवश्यकता है?

हाँ, Microsoft का कस्टम-डोमेन सेटअप रोटेशन के लिए आवश्यक रिकॉर्ड सहित, दोनों चयनकर्ता CNAME का उपयोग करता है। केवल एक सक्रिय हस्ताक्षर चयनकर्ता दूसरे प्रतिनिधिमंडल को अनावश्यक नहीं बनाता है।

क्या CnameMissing स्थिति का मतलब यह है कि मुझे एक और DMARC रिकॉर्ड बनाना चाहिए?

नहीं, यह जांच के लिए हस्ताक्षर-कॉन्फ़िगरेशन निर्भरता की पहचान करता है। किसी असंबद्ध DMARC नीति को बदलने से पहले सटीक जेनरेट किए गए CNAME नामों और लक्ष्यों की तुलना सार्वजनिक DNS से ​​करें।

क्या Microsoft 365 कॉन्फ़िगरेशन एक अलग CRM प्रदाता को कवर करता है?

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

क्या onmicrosoft.com डोमेन द्वारा हस्ताक्षरित संदेश मेरे कस्टम फ्रॉम डोमेन के साथ संरेखण में विफल हो सकता है?

हाँ। किसी असंबद्ध डोमेन पर पासिंग हस्ताक्षर आपके कस्टम फ्रॉम डोमेन के साथ DKIM संरेखण प्रदान नहीं करता है। सभी हस्ताक्षरों और किसी भी अन्य गुजरने वाले संरेखित पथ का निरीक्षण करें।

कार्यान्वयन समीक्षक को किस पर हस्ताक्षर करना चाहिए?

सही क्लाउड-विशिष्ट सेटिंग्स, दोनों DKIM प्रतिनिधिमंडल, प्रभावी DNS , महत्वपूर्ण मार्गों पर वास्तविक संरेखित संदेश, रिपोर्ट संग्रह, स्वामित्व और रिकॉर्ड किए गए अपवाद।

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. RFC 9989

    धारा §4.4 · §5.3.1 · §5.3.5 · §7.4 · §11.7

  2. RFC 7208

    धारा §3.2 · §4.6.4

  3. RFC 6376

    धारा §3.4 · §3.6.1 · §3.7 · §6.1.2 · §8.3

  4. Microsoft: अपने क्लाउड डोमेन से मेल पर हस्ताक्षर करने के लिए DKIM सेट करें

    धारा Microsoft 365 में आउटबाउंड संदेशों के DKIM हस्ताक्षर को कॉन्फ़िगर करें · आउटबाउंड संदेशों के DKIM हस्ताक्षर को कॉन्फ़िगर करने के लिए Exchange Online पावरशेल का उपयोग करें · DNS प्रदाता-विशिष्ट CNAME उदाहरण

  5. माइक्रोसॉफ्ट: कस्टम क्लाउड डोमेन के लिए SPF सेट करें

    धारा परिदृश्य: केवल Microsoft 365 ईमेल · परिदृश्य: Microsoft 365 ईमेल ऑन-प्रिमाइसेस ईमेल और एक गैर-Microsoft ईमेल सेवा के साथ

[ शब्दकोष ]

शब्दकोष

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

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

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

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार