Google Workspace DMARC सेटअप में चार जुड़े हुए चरण हैं: पुष्टि करें कि डोमेन के लिए कौन भेजता है, लागू को प्रकाशित करें SPF और DKIM रिकॉर्ड, चयनित डोमेन के लिए DKIM हस्ताक्षर प्रारंभ करें, और DMARC नीति पर भरोसा करने से पहले परिणामी संदेशों को सत्यापित करें।
DNS प्रकाशन और हस्ताक्षर अलग-अलग अवलोकन हैं। जब सेवा अभी तक हस्ताक्षर नहीं कर रही है तो DKIM कुंजी दिखाई दे सकती है, और जब कोई वेबसाइट या बिलिंग एप्लिकेशन किसी भिन्न प्रदाता का उपयोग करता है तो कर्मचारी मेल सही ढंग से प्रमाणित कर सकता है। प्रत्येक महत्वपूर्ण सेवा के लिए पूर्ण मार्ग का पालन करें।
चयनित डोमेन और मौजूदा कॉन्फ़िगरेशन की जाँच करें
चयनित डोमेन, उसके आधिकारिक DNS होस्ट, वर्तमान रिकॉर्ड और कार्य के लिए आवश्यक Google प्रशासन अनुमतियों की पुष्टि करें। मौजूदा कॉन्फ़िगरेशन सहेजें.
जांचें कि क्या वैध SPF नीति और कार्यशील कस्टम-डोमेन DKIM हस्ताक्षर पहले से मौजूद हैं। केवल पहले चरण से नई मार्गदर्शिका का पालन करने के लिए किसी कार्यशील कुंजी को पुन: उत्पन्न न करें या किसी स्थापित नीति को प्रतिस्थापित न करें।
कर्मचारी मेल, उपनाम या द्वितीयक डोमेन, गेटवे और बाहरी अनुप्रयोगों के लिए एक रूट सूची बनाएं। प्रत्येक महत्वपूर्ण पहचान के लिए, एक अलग प्राप्त-संदेश परीक्षण की योजना बनाएं।
वे सेवाएँ शामिल करें जो कार्यक्षेत्र से बाहर भेजती हैं
Google Workspace कर्मचारी मेल को संभाल सकता है जबकि वेबसाइट, अकाउंटिंग सिस्टम और सपोर्ट प्लेटफ़ॉर्म अन्य प्रदाताओं का उपयोग करते हैं। वर्कस्पेस सेटअप स्वचालित रूप से स्वामित्व स्थापित नहीं कर सकता है या संरेखण उन सेवाओं के लिए.
टीम से प्रत्येक ग्राहक-सामना करने वाले प्रेषक और उसके व्यवसाय स्वामी का नाम बताने को कहें। कम मात्रा वाले लेकिन महत्वपूर्ण मेल जैसे लॉगिन लिंक और भुगतान रसीदें शामिल करें। फिर यह मानने के बजाय कि एक सफल Gmail परीक्षण इसे कवर करता है, वास्तविक एप्लिकेशन से सत्यापन परिणाम मांगें।
सुनिश्चित करें कि डोमेन के DNS खाते और रिपोर्ट गंतव्य का स्वामी कोई है। प्रमाणीकरण को बनाए रखना मुश्किल हो जाता है जब कोई पूर्व ठेकेदार रिकॉर्ड को नियंत्रित करता है या रिपोर्ट ऐसे मेलबॉक्स में आती है जिसे कोई नहीं पढ़ता है।
उचित SPF नीति प्रकाशित करें
**केवल Google Workspace ** के माध्यम से भेजने वाले डोमेन के लिए Google का वर्तमान प्रलेखित उदाहरण है:
v=spf1 include:_spf.google.com ~allइसका उपयोग तभी करें जब धारणा फिट बैठे। मिश्रित-सेवा डोमेन के लिए, इसकी एकल SPF नीति को बदलने से पहले मौजूदा अनुमतियों और वास्तविक लिफ़ाफ़ा पहचान की समीक्षा करें। अपने प्रदाता के स्वयं के लिफाफा डोमेन का उपयोग करने वाले एक अलग एप्लिकेशन को एक अलग समर्थित संरेखण दृष्टिकोण की आवश्यकता हो सकती है।
The ~all क्वालीफायर अन्यथा बेजोड़ स्रोत के लिए SPF softfail उत्पन्न करता है। सॉफ्टफ़ेल DMARC के लिए पासिंग SPF परिणाम नहीं है, और यह प्रत्येक रिसीवर को संदेश को स्पैम में डालने के लिए बाध्य नहीं करता है। रिसीवर हैंडलिंग और अलग DMARC निर्णय प्रासंगिक बने रहेंगे।
नेस्टेड निर्भरताओं सहित SPF मूल्यांकन पथ की जाँच करें। शीर्ष-स्तरीय रिकॉर्ड में दिखाई देने वाले समावेशन की गिनती अपर्याप्त है।
चयनित डोमेन की DKIM कुंजी बनाएं और प्रकाशित करें
Google एडमिन कंसोल में, ऐप्स, Google Workspace , Gmail पर नेविगेट करें, फिर ईमेल प्रमाणित करें। सही डोमेन चुनें. यदि यह एक नया हस्ताक्षर सेटअप है, तो नया रिकॉर्ड जेनरेट करें और समर्थित कुंजी सेटिंग्स का उपयोग करें।
Google एक ऑफर करता है 2048-बिट कुंजी जहां DNS प्रदाता इसका समर्थन करता है। डिफ़ॉल्ट चयनकर्ता है गूगल; मौजूदा चयनकर्ता टकराव को ओवरराइट के बजाय एक समर्थित भिन्न चयनकर्ता की आवश्यकता होती है।
कंसोल से जेनरेट किए गए DNS होस्ट नाम और सार्वजनिक-कुंजी मान की प्रतिलिपि बनाएँ। उस ** TXT ** रिकॉर्ड को आधिकारिक DNS ज़ोन में प्रकाशित करें। एक सामान्य रिश्तेदार स्वामी का नाम है गूगल। _domainkey, लेकिन चयनित डोमेन के जेनरेट किए गए मानों और DNS संपादक के नामकरण मॉडल का उपयोग करें।
निजी कुंजी DNS में प्रकाशित नहीं है. किसी लेख से संक्षिप्त नमूना कुंजी चिपकाएँ नहीं, किसी अन्य डोमेन की कुंजी का पुन: उपयोग न करें या किसी अन्य सेवा के चयनकर्ता को चुपचाप न बदलें।
परिणामी पूर्ण नाम पर सार्वजनिक उत्तर की जाँच करें:
dig TXT google._domainkey.example.com +shortयह आदेश उदाहरणात्मक है: डोमेन और, जहां लागू हो, चयनकर्ता को बदलें। एक सार्वजनिक TXT उत्तर प्रमुख प्रकाशन को दर्शाता है, न कि यह कि वर्कस्पेस ने हस्ताक्षर करना शुरू कर दिया है।
हस्ताक्षर करना प्रारंभ करें और प्राप्त संदेश का निरीक्षण करें
कुंजी को प्रकाशित करने और जांचने के बाद, चयनित डोमेन की प्रमाणीकरण ईमेल सेटिंग्स पर वापस लौटें और प्रमाणीकरण प्रारंभ करें। परिणामी स्थिति की समीक्षा करें.
Google के निर्देश स्वयं को संदेश भेजने के बजाय किसी अन्य Gmail या Google Workspace प्राप्तकर्ता के साथ परीक्षण का वर्णन करते हैं। प्राप्तकर्ता के पास मूल संदेश खोलें और विश्वसनीय प्रमाणीकरण परिणामों का निरीक्षण करें DKIM-Signature.
दृश्यमान डोमेन से हस्ताक्षरित डोमेन, चयनकर्ता और संरेखण को सत्यापित करें। किसी भिन्न डोमेन के लिए पास आपके डोमेन का संरेखित पथ स्थापित नहीं करता है। प्रासंगिक उपनामों, द्वितीयक डोमेन, गेटवे और एप्लिकेशन मार्गों के लिए परीक्षण दोहराएं।
- परत: DNS ; उत्तर के लिए प्रश्न: क्या उत्पन्न सार्वजनिक कुंजी इच्छित नाम पर प्रकाशित की गई है?
- परत: कार्यक्षेत्र; उत्तर देने योग्य प्रश्न: क्या चयनित डोमेन के लिए हस्ताक्षर सक्षम है?
- परत: प्राप्त मेल; उत्तर देने योग्य प्रश्न: क्या प्रासंगिक हस्ताक्षर पूरे मार्ग के बाद सत्यापित और संरेखित होता है?
- परत: व्यवसाय वर्कफ़्लो; उत्तर के लिए प्रश्न: क्या उपयोगकर्ताओं द्वारा भेजा गया संदेश वास्तव में उस सेवा पर निर्भर था?
- ओवाइडर सेटअप और DNS कैशिंग में समय लग सकता है। Google नई सक्षम Gmail सेवाओं के लिए कुंजी निर्माण से पहले तैयारी में देरी का भी दस्तावेजीकरण करता है। वास्तविक स्थिति और वर्तमान मार्गदर्शन का उपयोग करें; एक सार्वभौमिक समापन समय का वादा न करें।
DMARC नीति प्रकाशित और सत्यापित करें
नए मॉनिटर किए गए डोमेन के लिए, समान-डोमेन रिपोर्टिंग उदाहरण है:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comइसे लागू पर प्रकाशित करें _dmarc नाम, कार्यशील अनुमोदित संग्रह पते का उपयोग करें और रिपोर्ट आगमन और प्रसंस्करण की पुष्टि करें। Google वर्तमान में अपने DMARC सेटअप चरण से पहले कम से कम 48 घंटे SPF / DKIM संचालन की अनुमति देने की सलाह देता है। वह तैयारी अवधि, अपने आप में, एक मजबूत नीति लागू करने के लिए तत्परता स्थापित नहीं करती है।
यदि डोमेन में पहले से ही कोई नीति है, तो उसे स्वचालित रूप से निगरानी के साथ बदलने के बजाय उसका मूल्यांकन करें। DMARC रिकॉर्ड वर्कफ़्लो बताता है कि DNS सत्यापन को वास्तविक-संदेश साक्ष्य से कैसे जोड़ा जाए।
सेवाओं में परिवर्तन होने पर कवरेज बनाए रखें
प्रेषक सूची और उसके महत्वपूर्ण-प्रवाह परीक्षणों के विरुद्ध कार्यान्वयन की समीक्षा करें। एक डोमेन के लिए एक सेटिंग प्रत्येक द्वितीयक डोमेन या बाहरी अधिसूचना सेवा की स्थिति को साबित नहीं करती है।
कार्यक्षेत्र और DNS प्रशासन खातों तक स्पष्ट पहुंच की आवश्यकता है, एक अभिलिखित स्वीकृत परिवर्तनों की, चयनकर्ताओं की एक संधारित सूची और एक जवाबदेह रिपोर्ट-समीक्षा प्रक्रिया। परिभाषित करें कि टीम किसी नए शुरू किए गए एप्लिकेशन या छोड़ी गई सेवा को कैसे संभालती है।
डोमेन प्रमाणीकरण और खाता सुरक्षा के बीच अंतर बनाए रखें। एक समझौताकृत अधिकृत खाता एक प्रमाणित संदेश भेज सकता है। DMARC पास भी इनबॉक्स प्लेसमेंट की गारंटी नहीं देता है या यह स्थापित नहीं करता है कि कोई व्यावसायिक अनुरोध वैध है।
व्यावहारिक उपाय
DNS साक्ष्य, हस्ताक्षर स्थिति और प्राप्त-संदेश परिणाम को एक ही स्वीकृति रिकॉर्ड में रखें। इससे एक प्रकाशन समस्या को एक हस्ताक्षर समस्या या एक अलग एप्लिकेशन से अलग करना संभव हो जाता है जिसे अभी भी कॉन्फ़िगरेशन की आवश्यकता होती है।
प्रोजेक्ट को बंद करने से आंशिक सफलता प्राप्त करें
लिखित मामले में GW-01, मान लें कि user@example.com पास s=google. के साथ एक पासिंग हस्ताक्षर d=example.com है। उस निर्धारित संदेश में एक संरेखित DKIM पथ है। समान डोमेन का उपयोग करने वाले इनवॉइस एप्लिकेशन के पास अभी तक कोई विश्वसनीय प्राप्त-संदेश साक्ष्य नहीं है। इसके DKIM और SPF परिणाम अज्ञात हैं। कर्मचारी मेल को केवल अनुमानित मामले में सशर्त रूप से साक्ष्य के रूप में चिह्नित करें, और चालान मार्ग को उसके आवेदन स्वामी के साथ अनसुलझा छोड़ दें। इस गाइड के लिए किसी Google किरायेदार, संदेश, DNS रिकॉर्ड या हस्ताक्षर संचालन का परीक्षण नहीं किया गया था।
प्रवर्तन सीमा को सुरक्षित रखें
RFC 9989 धारा 7.4 में डोमेन प्रकाशन के लिए वैध DKIM की आवश्यकता है, अकेले SPF नहीं p=reject, और अप्रत्यक्ष-मेल और मेलिंग-सूची अंतरसंचालनीयता के बारे में चेतावनी देता है। एक भी सफल प्रत्यक्ष-संदेश परीक्षण इस बात का प्रमाण नहीं है कि हर वैध मार्ग मजबूत नीति के लिए तैयार है। वास्तविक अंतर का निदान करते समय मौजूदा अनुमोदित सुरक्षा बनाए रखें; किसी भी नीति परिवर्तन के लिए अपने स्वयं के निर्णय की आवश्यकता होती है।